4 ms·

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 o

by 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.
arenaninja 11y ago
This explains it pretty well. I always have to argue with other developers to not break IE8. The comeback is always that it represents less than 1% of our sales, I argue that the 1% of sales is still more than their salaries. As much as I'd love to stop keeping track of IE8 bugs, for a lot of sites this isn't possible. And, IMHO, this cavalier attitude is what causes many websites now to work "best" (read: only) in Chrome. It's true that a lot of sites (I'm thinking Webapps) don't need jQuery at all, and a lot of sites can get away with just using Sizzle, but 28kB is a small price to pay for the utility functions, cleaner AJAX API, event binding registry, etc. If you don't need them, by all means don't use it.

by aethr 11y ago

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.

arenaninja 11y ago

This explains it pretty well. I always have to argue with other developers to not break IE8. The comeback is always that it represents less than 1% of our sales, I argue that the 1% of sales is still more than their salaries. As much as I'd love to stop keeping track of IE8 bugs, for a lot of sites this isn't possible. And, IMHO, this cavalier attitude is what causes many websites now to work "best" (read: only) in Chrome. It's true that a lot of sites (I'm thinking Webapps) don't need jQuery at all, and a lot of sites can get away with just using Sizzle, but 28kB is a small price to pay for the utility functions, cleaner AJAX API, event binding registry, etc. If you don't need them, by all means don't use it.