5 ms·

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 dec

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.

tracker1 11y ago
While I tend to agree in some respects, mainly in application memory inside the browser in mobile (RAM is still relatively small 2-4GB on many phones), the actual compute power is pretty capable on even modest smart phones for the past year+ (given a roughly 2 year turnover on phones for most), it's less an issue. I also agree that jQuery isn't the end of what gets added... once you add a few additional libraries it gets very big, very quickly... I'm working on a project now that is loading about 19 jQuery plugins in addition to jQuery, as well as a handful of both bootstrap and jQuery-UI extensions, and the payload of a relatively simple page is coming in over 2MB (even if most of that caches, it's really big for a first hit). People tend to start with a kitchen sink, then add not only the rest of the kitchen, but the barn as well without a thought or consideration to the final result, and the payload that goes with it.
copsarebastards 11y ago
It sounds like you've done the work to validate the fact that 30Kb is too much for your use case. However, let's be clear here: most people who complain about the size of jQuery are doing so without any basis whatsoever. And even if people are measuring, they may not be measuring the right things. If not using jQuery causes you to reduce your Ajax usage, and reload entire pages as a result instead of only reloading the content, the end result is a slower site.
- bad_user 11y ago
  I totally agree and I exposed my use-case - really simple interfaces augmented by Javascript and served to mobile phones, so JQuery was basically unneeded, taking it out improved latency and thus it improved conversions. But of course, most people don't measure and most people need the features in JQuery to work reliably and to behave well cross-browser, in which case 30 Kb cached by a CDN is a steal.

tracker1 11y ago

While I tend to agree in some respects, mainly in application memory inside the browser in mobile (RAM is still relatively small 2-4GB on many phones), the actual compute power is pretty capable on even modest smart phones for the past year+ (given a roughly 2 year turnover on phones for most), it's less an issue. I also agree that jQuery isn't the end of what gets added... once you add a few additional libraries it gets very big, very quickly... I'm working on a project now that is loading about 19 jQuery plugins in addition to jQuery, as well as a handful of both bootstrap and jQuery-UI extensions, and the payload of a relatively simple page is coming in over 2MB (even if most of that caches, it's really big for a first hit). People tend to start with a kitchen sink, then add not only the rest of the kitchen, but the barn as well without a thought or consideration to the final result, and the payload that goes with it.

copsarebastards 11y ago

It sounds like you've done the work to validate the fact that 30Kb is too much for your use case. However, let's be clear here: most people who complain about the size of jQuery are doing so without any basis whatsoever. And even if people are measuring, they may not be measuring the right things. If not using jQuery causes you to reduce your Ajax usage, and reload entire pages as a result instead of only reloading the content, the end result is a slower site.

bad_user 11y ago
I totally agree and I exposed my use-case - really simple interfaces augmented by Javascript and served to mobile phones, so JQuery was basically unneeded, taking it out improved latency and thus it improved conversions. But of course, most people don't measure and most people need the features in JQuery to work reliably and to behave well cross-browser, in which case 30 Kb cached by a CDN is a steal.