8 ms·

> React is the new jQuery Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more

> React is the new jQuery Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target. The reason jQuery got so popular is that it made common tasks so much easier than anything else at the time. Anyone who was doing web development before jQuery knows what a godsend it was at the time. JQuery was a fantastic leap forward for development at the time it was released. JQuery didn't become bad, the rest of the development world caught up and made it unnecessary.

danShumway 8y ago
I don't think JQuery ever got bad. It just got unnecessary, like you said. But it took a lot of work to convince people that it was unnecessary. A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project. The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did. This is kind of the same concern I have with Vue to be honest. I use Vue for prototyping and will probably use it in some final apps as well. But I'm probably not ever going to use a component that someone else has written if it relies on Vue. IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc... I kind of wonder if the problems Vue solves for me could be solved better by a smaller, lodash-style library instead of a framework.
- jimmaswell 8y ago
  Being used to jQuery, I really see no reason not to use it in new projects. I could learn all the new native equivalents, and even then still ending up doing more work than if I'd been using jQuery, just to save a little bit of page load time and filesize, but it would almost certainly not be worth it.
  - 3131s 8y ago
    It irks me that Javascript didn't just adopt the best parts of JQuery.
    - vinceguidry 8y ago
      There are still things you can only do with jQuery, I can't think of a better Swiss Army knife for small tasks.
  - mxschumacher 8y ago
    it irks me to use common functions such as selectors and Ajax in jQuery that are much, much slower than their native counterparts
  - tracker1 8y ago
    Take a look at zepto (or another jquery-like library), add some feature detection for IE polyfills, and switch to using fetch for ajax calls. Unless you're using a lot of jQuery dependencies, you'll cut your download size by more than half for most browsers/users. I'd never say don't use jQuery, and it does support some options for a minimal footprint, still there's smaller options that probably have all you need.
  - isostatic 8y ago
    Indeed. I occasionally write a webbased tool to deal with a specific task (say formatting some form of codec data, or a simple dashboard for a specific event, or a small config generator, or whatever), userbase is in the <10 users (not concurrent) range, I don't give a stuff about scaling. I care that the code is in a repo (git, svn, whatever), is versioned (deb, rpm, whatever), and deploys cleanly. I could learn and use $latest_thing, and maybe it would be great. That will triple the time taken to develop, but whatever. However in a couple of years time when I come to need to write something else, $latest_thing will be old hat, and replaced by $shiny_and_new. Rather than having 10 years of nice simple code based on jquery, I get some based on Angular, some on React, some on Vue, some on Meteor, or whatever. I'm not a programmer, I'm not a wireman, and I'm not a carpenter. I program in the same way I'll run a network cable or get a screwdriver out, it's a tool I can use to solve a specific task. I like tools that are the same, year in, year out. That's not to say the latest frameworks aren't all great, if you're building something for a million users and want to take advantage of shiny new features that's great, but for those that aren't, there's still a place for boring old things in a large part of the computer industry.
- superfrank 8y ago
  > A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project. That's fair. > The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did. I totally agree with that, but I don't think you can use that as a knock against jQuery, react, or vue. I think developers, especially js developers with our love of pulling in external packages, have yet to find a great solution for dependency management. > IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc... I think lodash can work that way because most of its functions are small and self-contained. It's easy to just bundle in a few select functions when they functions are 100 lines max and don't need the rest of the library, but I don't think React or Vue could use a similar approach. Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it?
  - williamxd3 8y ago
    > Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it? And who would want a dropdown component that has its own little rendering framework inside when you are using React for that?
    - tracker1 8y ago
      Maybe not for a dropdown component, but I built a calendar component that stood alone using preact and redux, and the final size was still smaller than most calendar components of similar complexity.
      - williamxd3 8y ago
        Yeah, Preact is great for standalone widgets
- scotty79 8y ago
  > But it took a lot of work to convince people that it [JQuery] was unnecessary. First it took about a decade of browser and ECMA very intensive development to actually make it unnecessary. > it is becoming difficult to convince new developers that React may not be necessary for their next project. Give it a decade for the web "components" to actually become composable and for inventive and useful native language built-in solutions to state management to happen before you start advocating people out of React. Until then telling people they might not need React is not a step forward but backward. Imagine people saying "you might not need jQuery" in times where IE reigned and browsers were wildly incompatible.
- Waterluvian 8y ago
  Yes that's really a great way of seeing it. Jquery kind of graduated to obsolescence as many of its useful features made it into core JS. When querySelector and ES6 came about, I found myself not needing jquery by default.
BlackjackCF 8y ago
Agreed. I LOVED jQuery and I could do some serious damage with it before Angular/React came along.
jaydenseric 8y ago
Unless you were doing custom jQuery builds per project (which no-one was), it was always bad. People would routinely drop in the 35kb lib and only use 3-4 functions.
- superfrank 8y ago
  That's not really a problem with jQuery, that's a problem with the way people were using it. Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Web pages were simpler and more information based back then and it was usually a requirement that they be useable without javascript. Since you are (should be) loading jQuery at the end of the page (or asynchronously) the page should render just fine without jQuery and probably would have been loaded by the time any user interaction would have happened. Also, since users were on computers (mobile wasn't really a thing) and data usage wasn't a limiting factor (most plans were unlimited), loading extra data didn't really matter that much. Yeah, jQuery had extra functions that you didn't need, but it didn't really hurt much at the time and there wasn't really a better option.
  - jimmaswell 8y ago
    It still doesn't hurt. Less than 300k of a cachable library isn't a big deal for mobile data, and jQuery has never (in any example I know pf at least) been the reason a mobile page is slow. Sites like the default mobile reddit manage to be absolutely atrocious without it (10+ seconds to load anything even on wifi), yet lots of sites with it are completely fine on any smartphone in current use (such as the same phone mobile reddit takes 10 seconds to load on because it's using some awful ajax setup - seriously, they had perfection with .compact and just abandoned it for this crime against humanity).
  - Izkata 8y ago
    > Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Not to mention it was recommended to point your "src=" to one of the common cdns, so it would likely already be in the user's cache from some other website that used the same jquery version.
ksec 8y ago
Well kids these days. They said webkit is the new IE, and said the IE era was IE7. Sigh I cant even name a similar piece of software in web development history that is as important as jQuery. Despite Web development as a whole, back end or front end is still no where near being good enough, it is still many times better then the old days.
- vezycash 8y ago
  >cant even name a similar piece of software in web development history that is as important as jQuery. Php?
  - spc476 8y ago
    Netscape navigator?
  - irrational 8y ago
    Nah, there were always tons of alternatives to PHP. What real alternatives were there to jQuery? There were none.
    - molf 8y ago
      I know this is a rhetorical question, but Prototype.js was pretty similar to jQuery; although jQuery won the popularity contest.
      - jexah 8y ago
        I don't presume to be an expert on history (only entered the webdev domain in 2010), but didn't prototype come out at least a couple of years after jQuery?
        FroshKiller 8y ago
        Prototype was released like a year before jQuery.
jiggliemon 8y ago
jQuery was never bad. As a tool it was fantastic at what it did. But jQuery wasn’t just a tool, it was also community. What that community did/perpetuated was some pretty bad and ill advised practices. Plugins for everything - the old $.sum(2,2) joke applies here. DOM for state. Even sanctioned projects like jQuery UI were guilty of some terrible, awful practices. That said, React isn’t the new jQuery, it’s the new Backbone. Backbone lacked so much - and did so little - that it’s deficiencies needed to be made up for by “other” tooling. As a result, there was O(n) ways to “Backbone” – making backbone apps very difficult to study/build/maintain. React is fine. The community just needs to coalesce. Edit: typing on my phone; and am lazy
- tracker1 8y ago
  I think a lot of that does happen with React. Before Redux there were so many Flux-like libraries. material-ui and react-bootstrap are very widely used for UI/UX baseline. There are a ton of options for everything, for me it comes down to the following. react, redux, thunks (with async functions), fetch, material-ui ... those will get you a LONG way to where you need to be with react.
oliyoung 8y ago
> probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target. Yet, Sara is neither of those, she's a well respected developer, who's work with CSS and SVG is world-class. If she's using jQuery as a comparison she's doing it from a place of experience and knowledge
- freyir 8y ago
  Who is? CSS and SVG are great, but how is her javascript? Neglecting the role that jQuery played is foolish, and even respected developers can say foolish things now and then.
- jhanschoo 8y ago
  Unfortunately the shortness of the tweet leaves much to interpretation. Perhaps the analogy she was getting at is simply that it's being used in solutions that do not benefit from it.
alfredxing 8y ago
I agree jQuery was very useful early on, especially since it abstracted cross-browser differences and APIs. However in my experience, a couple of things were key to creating a negative view of jQuery: 1. Security and unsafe defaults, for example: evaluating remote JavaScript by default [1]; and unsafe DOM parsing by default [2] 2. Not really to blame on jQuery, but its ease of use for DOM manipulation led to programming patterns that aren't easily scalable, for both code and performance [1] https://nvd.nist.gov/vuln/detail/CVE-2015-9251 https://nvd.nist.gov/vuln/detail/CVE-2015-9251 [2] http://api.jquery.com/jQuery.parseHTML/ http://api.jquery.com/jQuery.parseHTML/
- hrktb 8y ago
  To be fair, when jQuery was growing up PHP with magic auto global variables was the fury. Times were different
  - natecavanaugh 8y ago
    I think by 2006 magic auto globals was already off by default (4.2, which was released in 2002, was the one that turned it off, and though 4.2 was still widely used by the time jQuery came about, register_globals was considered bad practice in general by at least 2004, if not even earlier).
    - hrktb 8y ago
      good point. Your timeline is accurate, and while PHP installs tend to be out of date and people following tutorials would just turn off security features, by 2006 the trend should have been in decline, yes. More than anything, the crazy thing for me is that jQuery seemed to have been there from the wake of the web, when it came out only one year before the iPhone.
cup-of-tea 8y ago
Is jQuery unnecessary because the functionality is built into js now? Or browsers? Or other libraries? If it's libraries, are those libraries providing a superset of jQuery or are they just better?
- yread 8y ago
  jQuery is not that necessary anymore because difference between browsers' js implementations are not that big. You still have small differences in events but nothing like it used to be
- Vinnl 8y ago
  Yes, the DOM API's have greatly improved and are well-supported among browsers now, so jQuery is no longer needed for that. React doesn't solve the problem of inconsistent and unwieldy browser API's (which isn't a problem any more), but of a clean architecture for web applications.
TomK32 8y ago
Hey, those young kids just don't know how frontend development was before jQuery.
shams93 8y ago
Back when browsers were wildly incompatible jquery was a life saver. Sure you could do painful dom code and then have all kinds of libraries that have to be loaded in the right order to support all browsers or you could just include jquery. Now in the era of the progressive web app SPA jquery is outdated. Even for low level dom its still outdated because modern browsers follow standards really tightly especially compared to the bad old days. Frameworks are starting to get outdated in the face of tools like Svelte as well as Polymer 3. You can pull off a SPA with Polymer 3 on modern browsers with no shims at this point, except maybe shadow dom, but Polymer 3 has selective shimming so you don't have to download one huge shim file.
- Vinnl 8y ago
  jQuery also predates standards such as querySelectorAll and fetch, so no, it wasn't just compensating for browser incompatibilities; it also provided a far more pleasant API. React is in a similar boat - it provides a far more pleasant experience keeping the DOM in sync with your application state, in a way that Web Components don't (although they have other advantages that make them great when used together with React).
sametmax 8y ago
Insulting is really what i felt too. Simplicity, size, ubiquity, plug and play are the opposite of react. I would understand if comparing VueJS with jquey. Even if they are very different, the philosophy is the same: a small elegant easy to use versatil tool.
tracker1 8y ago
I know what a pain Prototype.js and others got to be... jQuery was a lot cleaner, though in retrospect, I wish they'd passed the context in as a property, instead of relying on "this", also wish they'd passed it as an already jQuery wrapped representation.
lr4444lr 8y ago
Agreed. Furthermore, a lot of those tasks were downright unnecessarily painful and tedious time sinks, e.g. browser agnostic control when the ecosystem was much more fragmented and HTML5 more nascent. Also, jQuery's documentation was solid, and it was very easily extensible.
kyle-rb 8y ago
As someone who learned web dev in the era after jQuery was marked by many as deprecated, I started to resent it mainly because of all the StackOverflow posters that give jQuery answers to JavaScript questions. (Plus the cases where CSS would suffice.)

danShumway 8y ago

I don't think JQuery ever got bad. It just got unnecessary, like you said. But it took a lot of work to convince people that it was unnecessary. A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project. The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did. This is kind of the same concern I have with Vue to be honest. I use Vue for prototyping and will probably use it in some final apps as well. But I'm probably not ever going to use a component that someone else has written if it relies on Vue. IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc... I kind of wonder if the problems Vue solves for me could be solved better by a smaller, lodash-style library instead of a framework.

jimmaswell 8y ago
Being used to jQuery, I really see no reason not to use it in new projects. I could learn all the new native equivalents, and even then still ending up doing more work than if I'd been using jQuery, just to save a little bit of page load time and filesize, but it would almost certainly not be worth it.
- 3131s 8y ago
  It irks me that Javascript didn't just adopt the best parts of JQuery.
  - vinceguidry 8y ago
    There are still things you can only do with jQuery, I can't think of a better Swiss Army knife for small tasks.
- mxschumacher 8y ago
  it irks me to use common functions such as selectors and Ajax in jQuery that are much, much slower than their native counterparts
- tracker1 8y ago
  Take a look at zepto (or another jquery-like library), add some feature detection for IE polyfills, and switch to using fetch for ajax calls. Unless you're using a lot of jQuery dependencies, you'll cut your download size by more than half for most browsers/users. I'd never say don't use jQuery, and it does support some options for a minimal footprint, still there's smaller options that probably have all you need.
- isostatic 8y ago
  Indeed. I occasionally write a webbased tool to deal with a specific task (say formatting some form of codec data, or a simple dashboard for a specific event, or a small config generator, or whatever), userbase is in the <10 users (not concurrent) range, I don't give a stuff about scaling. I care that the code is in a repo (git, svn, whatever), is versioned (deb, rpm, whatever), and deploys cleanly. I could learn and use $latest_thing, and maybe it would be great. That will triple the time taken to develop, but whatever. However in a couple of years time when I come to need to write something else, $latest_thing will be old hat, and replaced by $shiny_and_new. Rather than having 10 years of nice simple code based on jquery, I get some based on Angular, some on React, some on Vue, some on Meteor, or whatever. I'm not a programmer, I'm not a wireman, and I'm not a carpenter. I program in the same way I'll run a network cable or get a screwdriver out, it's a tool I can use to solve a specific task. I like tools that are the same, year in, year out. That's not to say the latest frameworks aren't all great, if you're building something for a million users and want to take advantage of shiny new features that's great, but for those that aren't, there's still a place for boring old things in a large part of the computer industry.
superfrank 8y ago
> A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project. That's fair. > The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did. I totally agree with that, but I don't think you can use that as a knock against jQuery, react, or vue. I think developers, especially js developers with our love of pulling in external packages, have yet to find a great solution for dependency management. > IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc... I think lodash can work that way because most of its functions are small and self-contained. It's easy to just bundle in a few select functions when they functions are 100 lines max and don't need the rest of the library, but I don't think React or Vue could use a similar approach. Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it?
- williamxd3 8y ago
  > Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it? And who would want a dropdown component that has its own little rendering framework inside when you are using React for that?
  - tracker1 8y ago
    Maybe not for a dropdown component, but I built a calendar component that stood alone using preact and redux, and the final size was still smaller than most calendar components of similar complexity.
    - williamxd3 8y ago
      Yeah, Preact is great for standalone widgets
scotty79 8y ago
> But it took a lot of work to convince people that it [JQuery] was unnecessary. First it took about a decade of browser and ECMA very intensive development to actually make it unnecessary. > it is becoming difficult to convince new developers that React may not be necessary for their next project. Give it a decade for the web "components" to actually become composable and for inventive and useful native language built-in solutions to state management to happen before you start advocating people out of React. Until then telling people they might not need React is not a step forward but backward. Imagine people saying "you might not need jQuery" in times where IE reigned and browsers were wildly incompatible.
Waterluvian 8y ago
Yes that's really a great way of seeing it. Jquery kind of graduated to obsolescence as many of its useful features made it into core JS. When querySelector and ES6 came about, I found myself not needing jquery by default.

BlackjackCF 8y ago

Agreed. I LOVED jQuery and I could do some serious damage with it before Angular/React came along.

jaydenseric 8y ago

Unless you were doing custom jQuery builds per project (which no-one was), it was always bad. People would routinely drop in the 35kb lib and only use 3-4 functions.

superfrank 8y ago
That's not really a problem with jQuery, that's a problem with the way people were using it. Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Web pages were simpler and more information based back then and it was usually a requirement that they be useable without javascript. Since you are (should be) loading jQuery at the end of the page (or asynchronously) the page should render just fine without jQuery and probably would have been loaded by the time any user interaction would have happened. Also, since users were on computers (mobile wasn't really a thing) and data usage wasn't a limiting factor (most plans were unlimited), loading extra data didn't really matter that much. Yeah, jQuery had extra functions that you didn't need, but it didn't really hurt much at the time and there wasn't really a better option.
- jimmaswell 8y ago
  It still doesn't hurt. Less than 300k of a cachable library isn't a big deal for mobile data, and jQuery has never (in any example I know pf at least) been the reason a mobile page is slow. Sites like the default mobile reddit manage to be absolutely atrocious without it (10+ seconds to load anything even on wifi), yet lots of sites with it are completely fine on any smartphone in current use (such as the same phone mobile reddit takes 10 seconds to load on because it's using some awful ajax setup - seriously, they had perfection with .compact and just abandoned it for this crime against humanity).
- Izkata 8y ago
  > Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Not to mention it was recommended to point your "src=" to one of the common cdns, so it would likely already be in the user's cache from some other website that used the same jquery version.

ksec 8y ago

Well kids these days. They said webkit is the new IE, and said the IE era was IE7. Sigh I cant even name a similar piece of software in web development history that is as important as jQuery. Despite Web development as a whole, back end or front end is still no where near being good enough, it is still many times better then the old days.

vezycash 8y ago
>cant even name a similar piece of software in web development history that is as important as jQuery. Php?
- spc476 8y ago
  Netscape navigator?
- irrational 8y ago
  Nah, there were always tons of alternatives to PHP. What real alternatives were there to jQuery? There were none.
  - molf 8y ago
    I know this is a rhetorical question, but Prototype.js was pretty similar to jQuery; although jQuery won the popularity contest.
    - jexah 8y ago
      I don't presume to be an expert on history (only entered the webdev domain in 2010), but didn't prototype come out at least a couple of years after jQuery?
      - FroshKiller 8y ago
        Prototype was released like a year before jQuery.

jiggliemon 8y ago

jQuery was never bad. As a tool it was fantastic at what it did. But jQuery wasn’t just a tool, it was also community. What that community did/perpetuated was some pretty bad and ill advised practices. Plugins for everything - the old $.sum(2,2) joke applies here. DOM for state. Even sanctioned projects like jQuery UI were guilty of some terrible, awful practices. That said, React isn’t the new jQuery, it’s the new Backbone. Backbone lacked so much - and did so little - that it’s deficiencies needed to be made up for by “other” tooling. As a result, there was O(n) ways to “Backbone” – making backbone apps very difficult to study/build/maintain. React is fine. The community just needs to coalesce. Edit: typing on my phone; and am lazy

tracker1 8y ago
I think a lot of that does happen with React. Before Redux there were so many Flux-like libraries. material-ui and react-bootstrap are very widely used for UI/UX baseline. There are a ton of options for everything, for me it comes down to the following. react, redux, thunks (with async functions), fetch, material-ui ... those will get you a LONG way to where you need to be with react.

oliyoung 8y ago

> probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target. Yet, Sara is neither of those, she's a well respected developer, who's work with CSS and SVG is world-class. If she's using jQuery as a comparison she's doing it from a place of experience and knowledge

freyir 8y ago
Who is? CSS and SVG are great, but how is her javascript? Neglecting the role that jQuery played is foolish, and even respected developers can say foolish things now and then.
jhanschoo 8y ago
Unfortunately the shortness of the tweet leaves much to interpretation. Perhaps the analogy she was getting at is simply that it's being used in solutions that do not benefit from it.

alfredxing 8y ago

I agree jQuery was very useful early on, especially since it abstracted cross-browser differences and APIs. However in my experience, a couple of things were key to creating a negative view of jQuery: 1. Security and unsafe defaults, for example: evaluating remote JavaScript by default [1]; and unsafe DOM parsing by default [2] 2. Not really to blame on jQuery, but its ease of use for DOM manipulation led to programming patterns that aren't easily scalable, for both code and performance [1] https://nvd.nist.gov/vuln/detail/CVE-2015-9251 https://nvd.nist.gov/vuln/detail/CVE-2015-9251 [2] http://api.jquery.com/jQuery.parseHTML/ http://api.jquery.com/jQuery.parseHTML/

hrktb 8y ago
To be fair, when jQuery was growing up PHP with magic auto global variables was the fury. Times were different
- natecavanaugh 8y ago
  I think by 2006 magic auto globals was already off by default (4.2, which was released in 2002, was the one that turned it off, and though 4.2 was still widely used by the time jQuery came about, register_globals was considered bad practice in general by at least 2004, if not even earlier).
  - hrktb 8y ago
    good point. Your timeline is accurate, and while PHP installs tend to be out of date and people following tutorials would just turn off security features, by 2006 the trend should have been in decline, yes. More than anything, the crazy thing for me is that jQuery seemed to have been there from the wake of the web, when it came out only one year before the iPhone.

cup-of-tea 8y ago

Is jQuery unnecessary because the functionality is built into js now? Or browsers? Or other libraries? If it's libraries, are those libraries providing a superset of jQuery or are they just better?

yread 8y ago
jQuery is not that necessary anymore because difference between browsers' js implementations are not that big. You still have small differences in events but nothing like it used to be
Vinnl 8y ago
Yes, the DOM API's have greatly improved and are well-supported among browsers now, so jQuery is no longer needed for that. React doesn't solve the problem of inconsistent and unwieldy browser API's (which isn't a problem any more), but of a clean architecture for web applications.

TomK32 8y ago

Hey, those young kids just don't know how frontend development was before jQuery.

shams93 8y ago

Back when browsers were wildly incompatible jquery was a life saver. Sure you could do painful dom code and then have all kinds of libraries that have to be loaded in the right order to support all browsers or you could just include jquery. Now in the era of the progressive web app SPA jquery is outdated. Even for low level dom its still outdated because modern browsers follow standards really tightly especially compared to the bad old days. Frameworks are starting to get outdated in the face of tools like Svelte as well as Polymer 3. You can pull off a SPA with Polymer 3 on modern browsers with no shims at this point, except maybe shadow dom, but Polymer 3 has selective shimming so you don't have to download one huge shim file.

Vinnl 8y ago
jQuery also predates standards such as querySelectorAll and fetch, so no, it wasn't just compensating for browser incompatibilities; it also provided a far more pleasant API. React is in a similar boat - it provides a far more pleasant experience keeping the DOM in sync with your application state, in a way that Web Components don't (although they have other advantages that make them great when used together with React).

sametmax 8y ago

Insulting is really what i felt too. Simplicity, size, ubiquity, plug and play are the opposite of react. I would understand if comparing VueJS with jquey. Even if they are very different, the philosophy is the same: a small elegant easy to use versatil tool.

tracker1 8y ago

I know what a pain Prototype.js and others got to be... jQuery was a lot cleaner, though in retrospect, I wish they'd passed the context in as a property, instead of relying on "this", also wish they'd passed it as an already jQuery wrapped representation.

lr4444lr 8y ago

Agreed. Furthermore, a lot of those tasks were downright unnecessarily painful and tedious time sinks, e.g. browser agnostic control when the ecosystem was much more fragmented and HTML5 more nascent. Also, jQuery's documentation was solid, and it was very easily extensible.

kyle-rb 8y ago

As someone who learned web dev in the era after jQuery was marked by many as deprecated, I started to resent it mainly because of all the StackOverflow posters that give jQuery answers to JavaScript questions. (Plus the cases where CSS would suffice.)