4 ms·

I really don't get this vendetta some small number of people seem to have against jQuery. It seems like it gets looked down upon in the same way that PHP gets l

by dageshi 10y ago

I really don't get this vendetta some small number of people seem to have against jQuery. It seems like it gets looked down upon in the same way that PHP gets looked down upon. But while PHP has legitimate problems most arguments against jQuery seem to boil down to "You can save a 100k download!". Big deal.

forestjc 10y ago
what kind of problems has PHP?
- tudorw 10y ago
  too old, like me :) Seriously, https://symfony.com/ https://symfony.com/ is awesome.
- amiga-workbench 10y ago
  Not hip or edgy enough.
mkawia 10y ago
On mobile that's a big deal. But on the other hand jQuery unlike MVC/virtualdom frameworks loads asynchronously and adds behaviour to static html ie it's non blocking.
- iSnow 10y ago
  jQuery adds something like 20Kb to the whole site, that is nothing I see as a problem on mobile.
  - BinaryIdiot 10y ago
    So even with today's browser and JavaScript improvements that 20kb should still be avoided if possible. Why? - Each file downloaded adds latency. This especially hurts if you're on a satellite or similar, highly latent connection. The more files you have to download the worse start-up and various loading timing can get. - Okay, so let's say you minified and combined everything to help avoid the first issue, now you have a new issue: all JavaScript needs to get executed when included. So adding 20kb worth of JavaScript, while not all of it is executed immediately, a chunk of it is. This adds to start-up time. - Don't forget JavaScript execution, when compared to a desktop, is absolutely abysmal. For mobile web browsers you need to shave as much time off of start-up and ready states as possible.
    - whostolemyhat 10y ago
      I agree with your overall point, but bringing up satellite connections is a bit silly - you shouldn't be optimising for edge cases.
      - BinaryIdiot 10y ago
        A satellite connection is an example of a highly latent connection. I've seen issues which have caused all sorts of other types of connections to spike with high latency. It's important, in my opinion, for your site to be able to handle that (and honestly it's not that hard). Satellite in a bit of a red herring in terms of the point I wanted to convey. I also spent about 3 years working on systems that had to work across satellite connections so I have a little bias as well :)
    - iSnow 10y ago
      I don't know, man. The average web page size is now around 2.5MB [1], jQuery is <1% of that. I am not going to be less productive to shave off 1% of total page size. If that means that some random satellite user has to wait 101s instead of 100, so be it. To me, that's much ado about nothing. jQuery is also not doing a whole lot on startup, its functions get called when needed. Lodash is the same. [1] http://httparchive.org/compare.php?&r1=Nov%2015%202010&s1=All&r2=Jan%201%202016&s2=All http://httparchive.org/compare.php?&r1=Nov%2015%202010&s1=Al...
      - BinaryIdiot 10y ago
        > The average web page size is now around 2.5MB [1], jQuery is <1% of that. I am not going to be less productive to shave off 1% of total page size. 2.5MB is absolutely ridiculous. Regardless, you just created a straw-man. jQuery is, what, 26kb minified + gzipped? So you could also say that if website is 100kb then jQuery is 25% the size of your website. Now 26kb is not much at all but small things add up very quickly. If you're not using it, don't include it. If you can write a tiny bit of extra code to avoid a dependency that isn't highly specialized (e.g. moment.js) it's usually a good idea on the web. > If that means that some random satellite user has to wait 101s instead of 100 FYI satellite connection issues are more about latency than bandwidth. Adding an extra connection (if it's not concatenated) to fetch jQuery can easily add more than 1 second even though it's only 26kb. Also, I sure hope your app doesn't take 100 seconds to start-up :)
jwarren 10y ago
I mean, 100kb is a big deal when it stops the page rendering, especially on mobile. But jQuery is not 100kb, it's 32kb when gzipped and minified. I think a better sentiment is that you probably don't need jQuery. jQuery is a great library, but with the modern state of JS, you can probably get by without it and spend that 32kb on something else more useful. You can get Preact, RxJS-lite and Immutable in total for about 40kb - is that going to be a better use of your performance budget?
- consto 10y ago
  And if you're doing it right, it's not even 32kb because chances are your visitor already has it cached in their browser even before visiting your site.
  - pluma 10y ago
    Chances aren't. 1. Your visitor must have visited other sites using jQuery from a CDN. 2. One of those sites must have used the same CDN you're using. 3. The site must have used the exact same version you're using. 4. Depending on the CDN, the version must have been served from the same URL (e.g. a problem when CDNs allow specifying partial version numbers and sites differ between referencing the full version number or just a part of it, 1.8 vs 1.8.2). And you're already doing things right, using HTTP/2 and everything, but your client hasn't visited a site before that uses your CDN and your version via your URL, now what? Your visitor's browser has to make another DNS lookup, open another connection to a different server, possible block your own scripts from executing because they depend on jQuery, and so forth. But if you're doing it right and using HTTP/2 and everything and hosting jQuery yourself (or possibly even use a vendor bundle) there won't be any visitors who have already got your jQuery version cached but the browser can avoid the overhead of another DNS lookup and another connection and just tell the server to send jQuery along with everything else over the same socket. Public CDNs have been of questionable value from the start[0] but with HTTP/2 this "if you're doing it right, you're loading your dependencies from a public CDN" meme needs to finally die. [0]: AFAIK the argument that public CDNs are a performance gain for third-party dependencies (vs bundling and/or hosting them yourself) was never substantiated with any real-world data. I guess for jQuery things have improved a bit with jQuery providing an official CDN as the default option but this doesn't help with jQuery plugins or anything other than jQuery itself.

by dageshi 10y ago

forestjc 10y ago

what kind of problems has PHP?

tudorw 10y ago
too old, like me :) Seriously, https://symfony.com/ https://symfony.com/ is awesome.
amiga-workbench 10y ago
Not hip or edgy enough.

mkawia 10y ago

On mobile that's a big deal. But on the other hand jQuery unlike MVC/virtualdom frameworks loads asynchronously and adds behaviour to static html ie it's non blocking.

iSnow 10y ago
jQuery adds something like 20Kb to the whole site, that is nothing I see as a problem on mobile.
- BinaryIdiot 10y ago
  So even with today's browser and JavaScript improvements that 20kb should still be avoided if possible. Why? - Each file downloaded adds latency. This especially hurts if you're on a satellite or similar, highly latent connection. The more files you have to download the worse start-up and various loading timing can get. - Okay, so let's say you minified and combined everything to help avoid the first issue, now you have a new issue: all JavaScript needs to get executed when included. So adding 20kb worth of JavaScript, while not all of it is executed immediately, a chunk of it is. This adds to start-up time. - Don't forget JavaScript execution, when compared to a desktop, is absolutely abysmal. For mobile web browsers you need to shave as much time off of start-up and ready states as possible.
  - whostolemyhat 10y ago
    I agree with your overall point, but bringing up satellite connections is a bit silly - you shouldn't be optimising for edge cases.
    - BinaryIdiot 10y ago
      A satellite connection is an example of a highly latent connection. I've seen issues which have caused all sorts of other types of connections to spike with high latency. It's important, in my opinion, for your site to be able to handle that (and honestly it's not that hard). Satellite in a bit of a red herring in terms of the point I wanted to convey. I also spent about 3 years working on systems that had to work across satellite connections so I have a little bias as well :)
  - iSnow 10y ago
    I don't know, man. The average web page size is now around 2.5MB [1], jQuery is <1% of that. I am not going to be less productive to shave off 1% of total page size. If that means that some random satellite user has to wait 101s instead of 100, so be it. To me, that's much ado about nothing. jQuery is also not doing a whole lot on startup, its functions get called when needed. Lodash is the same. [1] http://httparchive.org/compare.php?&r1=Nov%2015%202010&s1=All&r2=Jan%201%202016&s2=All http://httparchive.org/compare.php?&r1=Nov%2015%202010&s1=Al...
    - BinaryIdiot 10y ago
      > The average web page size is now around 2.5MB [1], jQuery is <1% of that. I am not going to be less productive to shave off 1% of total page size. 2.5MB is absolutely ridiculous. Regardless, you just created a straw-man. jQuery is, what, 26kb minified + gzipped? So you could also say that if website is 100kb then jQuery is 25% the size of your website. Now 26kb is not much at all but small things add up very quickly. If you're not using it, don't include it. If you can write a tiny bit of extra code to avoid a dependency that isn't highly specialized (e.g. moment.js) it's usually a good idea on the web. > If that means that some random satellite user has to wait 101s instead of 100 FYI satellite connection issues are more about latency than bandwidth. Adding an extra connection (if it's not concatenated) to fetch jQuery can easily add more than 1 second even though it's only 26kb. Also, I sure hope your app doesn't take 100 seconds to start-up :)

jwarren 10y ago

I mean, 100kb is a big deal when it stops the page rendering, especially on mobile. But jQuery is not 100kb, it's 32kb when gzipped and minified. I think a better sentiment is that you probably don't need jQuery. jQuery is a great library, but with the modern state of JS, you can probably get by without it and spend that 32kb on something else more useful. You can get Preact, RxJS-lite and Immutable in total for about 40kb - is that going to be a better use of your performance budget?

consto 10y ago
And if you're doing it right, it's not even 32kb because chances are your visitor already has it cached in their browser even before visiting your site.
- pluma 10y ago
  Chances aren't. 1. Your visitor must have visited other sites using jQuery from a CDN. 2. One of those sites must have used the same CDN you're using. 3. The site must have used the exact same version you're using. 4. Depending on the CDN, the version must have been served from the same URL (e.g. a problem when CDNs allow specifying partial version numbers and sites differ between referencing the full version number or just a part of it, 1.8 vs 1.8.2). And you're already doing things right, using HTTP/2 and everything, but your client hasn't visited a site before that uses your CDN and your version via your URL, now what? Your visitor's browser has to make another DNS lookup, open another connection to a different server, possible block your own scripts from executing because they depend on jQuery, and so forth. But if you're doing it right and using HTTP/2 and everything and hosting jQuery yourself (or possibly even use a vendor bundle) there won't be any visitors who have already got your jQuery version cached but the browser can avoid the overhead of another DNS lookup and another connection and just tell the server to send jQuery along with everything else over the same socket. Public CDNs have been of questionable value from the start[0] but with HTTP/2 this "if you're doing it right, you're loading your dependencies from a public CDN" meme needs to finally die. [0]: AFAIK the argument that public CDNs are a performance gain for third-party dependencies (vs bundling and/or hosting them yourself) was never substantiated with any real-world data. I guess for jQuery things have improved a bit with jQuery providing an official CDN as the default option but this doesn't help with jQuery plugins or anything other than jQuery itself.