6 ms·

> it's likely either a small project, or one with excessive tech debt, or one with no desire to modernize. I disagree. JQuery and React are just tools. Using

> it's likely either a small project, or one with excessive tech debt, or one with no desire to modernize. I disagree. JQuery and React are just tools. Using one or the other doesn't mean one has more tech debt or its a small project. You should use the one that gets the job done. By saying JQuery is 'bad' and React is 'good', the programmer fails to understand the purpose of the tool. The question the programmer should ask is whether choosing one over the other has any advantage in that particular project. I program frontend reluctantly when needed because I am a backend programmer. But I would choose either tool depending on what is needed.

noirbot 8y ago
I would argue my assumptions (and I recognize that they're not always going to be true) are based specifically off of the nature of the tools in question. If you're a React shop, and you've recently and competently decided that it's the best tool for you, that's likely because you're building a large and modular app that includes data handling of the type that React is good at. Unless jQuery has added a lot of features I'm not familiar with, it's not comparatively well-suited to larger and more modular projects like that. These days, it would mostly be used in projects that are small enough to not need the extra features from React, are bound to an architecture that makes implementing it hard, or has management/senior developers who prefer to stay with older tech. It's not that one is bad and one is good. It's that they're specifically good at different things that tend to point to different styles of development and project scope.
- acdha 8y ago
  I agree with your last point but have seen so much fad chasing that I wouldn’t be so sure about the assertion that people using React have done that nuanced analysis. An awful lot of these comparisons come down to what whoever is leading the project wants on their resume, and I’ve seen a ton of small sites using huge frameworks because that person didn’t want to learn a few bits of standard JS or CSS.
  - meesterdude 8y ago
    Salient comment; it's maybe 80% fad chasing and resume building over actual need and nuanced analysis. Jquery is great. it's fast, it's powerful, easy to learn. But It's not "new" and that's why people raise their noses at it.
    - acdha 8y ago
      We also have a weird hangover from the old IE era where people assume you need a framework for everything because the web platform isn’t worth taking seriously. Modern JS has a ton of things which are supported by all mainstream browsers and combined with CSS, HTML5 form validation, etc. there’s a lot of simple work which can be done with no external dependencies and using skills which last far longer.
  - noirbot 8y ago
    I'm not trying to say that most places do that analysis. I was just trying to frame it in the sense of "it's already been decided, and if you're wanting to work there, you have to hope it was done competently." It's far from that case that every project using React is all fad-chasing. Sometimes the new thing is actually good. I agree with the lack of analysis portion being a common thing, but that's something you have to work out for yourself as a part of the process. It's not as if React is the only faddish tool over the years - I'm sure there are plenty of older projects that are only using jQuery because it was the new hotness. And even more that were initially done with jQuery, but would probably work better with React if it weren't for the Lead's disinclination to learn a new framework. There's plenty of fad chasing, but there's also plenty of bull-headed resistance to new tech. The question of if React or jQuery or Vue or whatever is the best framework to use for a specific company or product is tangential to the question of if someone with only jQuery experience can be effective on a team with React as its core tech. The decisions have been made at that point.
    - acdha 8y ago
      Agreed on both directions: my position is that actually doing the analysis rather than going by gut instincts is less common than it should be for a field with pretenses of being a type of engineering. Cost analysis is especially big on that since most JS hype tends to be “3ns faster on this benchmark!” or “look at how easy this trivial task was!” rather than, say, development velocity on overhead on a non-trivial project over a year+ timeframe.

noirbot 8y ago

I would argue my assumptions (and I recognize that they're not always going to be true) are based specifically off of the nature of the tools in question. If you're a React shop, and you've recently and competently decided that it's the best tool for you, that's likely because you're building a large and modular app that includes data handling of the type that React is good at. Unless jQuery has added a lot of features I'm not familiar with, it's not comparatively well-suited to larger and more modular projects like that. These days, it would mostly be used in projects that are small enough to not need the extra features from React, are bound to an architecture that makes implementing it hard, or has management/senior developers who prefer to stay with older tech. It's not that one is bad and one is good. It's that they're specifically good at different things that tend to point to different styles of development and project scope.

acdha 8y ago
I agree with your last point but have seen so much fad chasing that I wouldn’t be so sure about the assertion that people using React have done that nuanced analysis. An awful lot of these comparisons come down to what whoever is leading the project wants on their resume, and I’ve seen a ton of small sites using huge frameworks because that person didn’t want to learn a few bits of standard JS or CSS.
- meesterdude 8y ago
  Salient comment; it's maybe 80% fad chasing and resume building over actual need and nuanced analysis. Jquery is great. it's fast, it's powerful, easy to learn. But It's not "new" and that's why people raise their noses at it.
  - acdha 8y ago
    We also have a weird hangover from the old IE era where people assume you need a framework for everything because the web platform isn’t worth taking seriously. Modern JS has a ton of things which are supported by all mainstream browsers and combined with CSS, HTML5 form validation, etc. there’s a lot of simple work which can be done with no external dependencies and using skills which last far longer.
- noirbot 8y ago
  I'm not trying to say that most places do that analysis. I was just trying to frame it in the sense of "it's already been decided, and if you're wanting to work there, you have to hope it was done competently." It's far from that case that every project using React is all fad-chasing. Sometimes the new thing is actually good. I agree with the lack of analysis portion being a common thing, but that's something you have to work out for yourself as a part of the process. It's not as if React is the only faddish tool over the years - I'm sure there are plenty of older projects that are only using jQuery because it was the new hotness. And even more that were initially done with jQuery, but would probably work better with React if it weren't for the Lead's disinclination to learn a new framework. There's plenty of fad chasing, but there's also plenty of bull-headed resistance to new tech. The question of if React or jQuery or Vue or whatever is the best framework to use for a specific company or product is tangential to the question of if someone with only jQuery experience can be effective on a team with React as its core tech. The decisions have been made at that point.
  - acdha 8y ago
    Agreed on both directions: my position is that actually doing the analysis rather than going by gut instincts is less common than it should be for a field with pretenses of being a type of engineering. Cost analysis is especially big on that since most JS hype tends to be “3ns faster on this benchmark!” or “look at how easy this trivial task was!” rather than, say, development velocity on overhead on a non-trivial project over a year+ timeframe.