6 ms·

Can someone explain the new trend to not use jQuery?

by goyote8 11y ago

rogem002 11y ago
IMO jQuery is one more thing the end user has to download and process, the more stuff we can strip out while keeping the same user experience is a good thing. Though I think most the people moving away from jQuery are doing it because the browsers have become more consistent in how they run JS.
anton-107 11y ago
I've always seen jQuery as an additional layer to handle browsers' API inconsistencies. If browsers you need to support have consistent APIs now - there is no reason left for adding this layer to new projects anymore.
VeejayRampay 11y ago
It's a general trend in programming that we've seen forever. Once a successful monolith/monopoly is established and once it becomes all-encompassing (and maybe too far-reaching), people tend to want to be able to cherry-pick the different bits without having to rely on the whole. It's not a mark of disrespect to the fantastic work of the people who created jQuery in the first place, but merely a sign that jQuery is not godly anymore, people want to appropriate it and make it their own, have it cater to their needs and use cases. I think that's a good thing.
aethr 11y ago
A lot of developers originally used jQuery as a cross-browser compatibility library when that was still a major concern. Along the way, jQuery has added tons of extra helper functions and wrappers (ie, .ajax(), .post(), event binding helpers, etc). This has been amazing for web development, but it's also been such a major pillar of web development that a lot of front end developers don't actually know what's happening under the hood when they use jQuery. jQuery as a library has now become huge, and a lot of projects probably don't use the full feature set. With modern browser support converging and older browsers being edged out of the usage stats, there's not as much need for the cross-browser portions of the library anymore. Enough so that newer versions of jQuery have dropped support for those browsers as well. So if you can cut down your cold cache loading times by not including the full jQuery library, that's probably a win (especially on mobile). You can do this by using a custom build of jQuery, but I guess some developers are taking this opportunity to go "back to their roots" and see how Javascript has changed since jQuery became a de-facto include in every project. I think there's a lot more maturity in the language these days, and by using native JS methods there's probably opportunities there for browser optimisations that aren't available using helper methods written in JS that accomplish the same functional goals. But I'm not a browser devevloper or a JavaScript expert, just a long time web developer who remembers the times before jQuery was in every project. If it's a crutch, it's one I will remember fondly.
- themartorana 11y ago
  I would add that a lot of the time, your browser-set is very small. For mobile apps, many of which use web views for at least some functionality, you're writing to one or two versions of WebKit only.
- mattdlondon 11y ago
  The "back to their roots" thing inspired this useful reference website: http://standardjavascript.info http://standardjavascript.info
- gabemart 11y ago
  > jQuery as a library has now become huge > So if you can cut down your cold cache loading times by not > including the full jQuery library, that's probably a win jQuery 1.11.3 is 38.4 KB when minified and gzipped. jQuery 2.1.4 is 34.1 KB when minified and gzipped. I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most front-end JS frameworks are the same size or bigger and don't receive as much attention for being bloated. If you can get by without jQuery, or if you have a very large number of mobile users and first-load performance is mission-critical for your application, or if you have a large percentage of users from countries with slow or intermittent internet connections, then sure, avoiding jQuery makes sense as a priority. But for most applications, jQuery is a smaller download than a single medium-resolution highly optimized image, and it can be cached forever.
  - bad_user 11y ago
    Loading over 30 Kb of minified/gzipped Javascript over a 3G connection on a mobile phone is very problematic, as the bandwidth is poor, the CPU capacity for decompressing and parsing is poorer than on the desktop, so the latency can many times be measured in seconds, therefore loading over 30 Kb of stuff that you don't need gets to be a tough pill to swallow. Also the argument of caching is often brought up, but in my tests this can be very non-deterministic, as mobile phones are pretty aggressive in their used storage. JQuery is supposed to be cached, yet in our A/B testing the load times and consequently the conversion rates improved greatly after we dropped JQuery. Your comparison with "a single medium-resolution highly optimized image" doesn't hold for mobile phones. On mobile phones users expect latency when loading images, but not when loading the UI. Another problem is that JQuery is not the only commonly used library. You add Underscore, you add Angular, or whatever libraries du-jour we have and pretty soon we are talking about 100 Kb of stuff or even more that is rarely used as a whole. Of course, my use-case is about having really simple interfaces augmented by Javascript and meant for mobile phones. Well, for complex interfaces I think bringing in JQuery as a dependency may be worth it, but then again, I then start thinking that JQuery is not enough. It's because I want more, I want a virtual DOM that's saner by design, I want to work with immutability, I want much better performance without unpredictable behavior (like what you get with Angular) and I want to only pay for the features I use. JQuery is incompatible with React and is incompatible with Google Closure in advanced mode.
jwarren 11y ago
In very basic terms - one of the biggest boons of jQuery were patching over browser incompatibilities. The tradeoff was an extra library being downloaded and a small performance trade-off (in certain scenarios). In 2015 most browsers are in much better shape than they were in, say, 2007. A lot of people are mostly targeting users who use up-to-date, standards compliant browsers. They are also often targeting people who use mobiles, which are (for a couple of reasons) much more sensitive to poor JS performance than desktops, and also see a more tangible benefit from small page sizes. Another advantage to jQuery was making complex JS operations very simple. Modern JavaScript has actually made life much easier[1], meaning that it's often only a little more work to use vanilla Javascript. [1]: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
frik 11y ago
New trend? It was a new trend in 2011. Jquery isn't needed anymore with HTML5 browsers, all the useful API have been added with native speed advantage. If you still have to support IE8 than Jquery is great.

Can someone explain the new trend to not use jQuery?

by goyote8 11y ago

Can someone explain the new trend to not use jQuery?

IMO jQuery is one more thing the end user has to download and process, the more stuff we can strip out while keeping the same user experience is a good thing. Though I think most the people moving away from jQuery are doing it because the browsers have become more consistent in how they run JS.

anton-107 11y ago

I've always seen jQuery as an additional layer to handle browsers' API inconsistencies. If browsers you need to support have consistent APIs now - there is no reason left for adding this layer to new projects anymore.

VeejayRampay 11y ago

It's a general trend in programming that we've seen forever. Once a successful monolith/monopoly is established and once it becomes all-encompassing (and maybe too far-reaching), people tend to want to be able to cherry-pick the different bits without having to rely on the whole. It's not a mark of disrespect to the fantastic work of the people who created jQuery in the first place, but merely a sign that jQuery is not godly anymore, people want to appropriate it and make it their own, have it cater to their needs and use cases. I think that's a good thing.

aethr 11y ago

A lot of developers originally used jQuery as a cross-browser compatibility library when that was still a major concern. Along the way, jQuery has added tons of extra helper functions and wrappers (ie, .ajax(), .post(), event binding helpers, etc). This has been amazing for web development, but it's also been such a major pillar of web development that a lot of front end developers don't actually know what's happening under the hood when they use jQuery. jQuery as a library has now become huge, and a lot of projects probably don't use the full feature set. With modern browser support converging and older browsers being edged out of the usage stats, there's not as much need for the cross-browser portions of the library anymore. Enough so that newer versions of jQuery have dropped support for those browsers as well. So if you can cut down your cold cache loading times by not including the full jQuery library, that's probably a win (especially on mobile). You can do this by using a custom build of jQuery, but I guess some developers are taking this opportunity to go "back to their roots" and see how Javascript has changed since jQuery became a de-facto include in every project. I think there's a lot more maturity in the language these days, and by using native JS methods there's probably opportunities there for browser optimisations that aren't available using helper methods written in JS that accomplish the same functional goals. But I'm not a browser devevloper or a JavaScript expert, just a long time web developer who remembers the times before jQuery was in every project. If it's a crutch, it's one I will remember fondly.

themartorana 11y ago
I would add that a lot of the time, your browser-set is very small. For mobile apps, many of which use web views for at least some functionality, you're writing to one or two versions of WebKit only.
mattdlondon 11y ago
The "back to their roots" thing inspired this useful reference website: http://standardjavascript.info http://standardjavascript.info
gabemart 11y ago
> jQuery as a library has now become huge > So if you can cut down your cold cache loading times by not > including the full jQuery library, that's probably a win jQuery 1.11.3 is 38.4 KB when minified and gzipped. jQuery 2.1.4 is 34.1 KB when minified and gzipped. I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most front-end JS frameworks are the same size or bigger and don't receive as much attention for being bloated. If you can get by without jQuery, or if you have a very large number of mobile users and first-load performance is mission-critical for your application, or if you have a large percentage of users from countries with slow or intermittent internet connections, then sure, avoiding jQuery makes sense as a priority. But for most applications, jQuery is a smaller download than a single medium-resolution highly optimized image, and it can be cached forever.
- bad_user 11y ago
  Loading over 30 Kb of minified/gzipped Javascript over a 3G connection on a mobile phone is very problematic, as the bandwidth is poor, the CPU capacity for decompressing and parsing is poorer than on the desktop, so the latency can many times be measured in seconds, therefore loading over 30 Kb of stuff that you don't need gets to be a tough pill to swallow. Also the argument of caching is often brought up, but in my tests this can be very non-deterministic, as mobile phones are pretty aggressive in their used storage. JQuery is supposed to be cached, yet in our A/B testing the load times and consequently the conversion rates improved greatly after we dropped JQuery. Your comparison with "a single medium-resolution highly optimized image" doesn't hold for mobile phones. On mobile phones users expect latency when loading images, but not when loading the UI. Another problem is that JQuery is not the only commonly used library. You add Underscore, you add Angular, or whatever libraries du-jour we have and pretty soon we are talking about 100 Kb of stuff or even more that is rarely used as a whole. Of course, my use-case is about having really simple interfaces augmented by Javascript and meant for mobile phones. Well, for complex interfaces I think bringing in JQuery as a dependency may be worth it, but then again, I then start thinking that JQuery is not enough. It's because I want more, I want a virtual DOM that's saner by design, I want to work with immutability, I want much better performance without unpredictable behavior (like what you get with Angular) and I want to only pay for the features I use. JQuery is incompatible with React and is incompatible with Google Closure in advanced mode.

jwarren 11y ago

In very basic terms - one of the biggest boons of jQuery were patching over browser incompatibilities. The tradeoff was an extra library being downloaded and a small performance trade-off (in certain scenarios). In 2015 most browsers are in much better shape than they were in, say, 2007. A lot of people are mostly targeting users who use up-to-date, standards compliant browsers. They are also often targeting people who use mobiles, which are (for a couple of reasons) much more sensitive to poor JS performance than desktops, and also see a more tangible benefit from small page sizes. Another advantage to jQuery was making complex JS operations very simple. Modern JavaScript has actually made life much easier[1], meaning that it's often only a little more work to use vanilla Javascript. [1]: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/

frik 11y ago

New trend? It was a new trend in 2011. Jquery isn't needed anymore with HTML5 browsers, all the useful API have been added with native speed advantage. If you still have to support IE8 than Jquery is great.