4 ms·

The full, concatenated and uglified source of one-page JS web apps can easily run to >600kB. Whether my DOM manipulation library consumes 4kB of that or 35kB is

The full, concatenated and uglified source of one-page JS web apps can easily run to >600kB. Whether my DOM manipulation library consumes 4kB of that or 35kB isn't especially important to me. I'm more concerned about features, cross browser support and familiarity other developers may, or may not have, with the API. I'll be happy to check this lib out though, the API and docs look nicely put together.

sehrope 13y ago
This is even more so if your site is served over HTTPS given the latency for the initial SSL handshake[1]. Even better not to load anything and have it properly cached on the client side. If you do it right you don't even have the client send/receive an HTTP 304. For our app we have a lot of modular dependencies but we serve all of them from a unique prefix per build (eg. 'assets-SHA(build)/js/foo.js'). The second page load and beyond has zero requests for the same static asset. Whenever we have a new build of the app the unique prefix gets auto updated to force clients to use the latest versions. For HTTPS make sure to mark your assets as public or they won't be cached: Cache-Control:max-age=31557600, public [1]: http://www.semicomplete.com/blog/geekery/ssl-latency.html http://www.semicomplete.com/blog/geekery/ssl-latency.html
corresation 13y ago
Whether my DOM manipulation library consumes 4kB of that or 35kB isn't especially important to me. Now that jQuery 2.x drops IE 8- support, a credible question is whether such libraries (which are more in the 95KB range, minified) are even necessary at all. Quite outside of the time to download, there is a measurable cost to parse all of that boilerplate code as well. This has more of an impact on mobile, obviously.
- dmethvin 13y ago
  > Now that jQuery 2.x drops IE 8- support, a credible question is whether such libraries (which are more in the 95KB range, minified) are even necessary at all. Well my answer to the credible question is that jQuery has to normalize and fix bugs for just about all the browsers it supports, it's not just an oldIE problem. Plus, jQuery provides abstractions above the basic DOM operations which are pretty low level. So if you don't want to use jQuery you'd probably want some other library to provide equal or greater abstraction. > Quite outside of the time to download, there is a measurable cost to parse all of that boilerplate code as well. This has more of an impact on mobile, obviously. Measurable of course. Significant as a portion of the page load time for most pages? Well that's a different thing. And of course if you want it, jQuery 1.8+ provides the ability to create custom builds if you know you don't need parts of it.
  - corresation 13y ago
    jQuery would never have come into popularity if not for oldIE and its often dramatic variances from competitors: If you are willing to forsake that old browser, there is little added but a layer of inefficiency between you and web standards. We have become so accustomed to jQuery that it becomes the default, many unaware of the dramatic improvements in all major browsers since. As to the cost, assuming that everyone is pulling it from the same CDN (and there aren't the often considerable times simply to check an etag, which is the case with the overwhelming majority of jQuery hosts), an iPhone 4S takes about 80-100ms to simply parse the jQuery file (and given the plateauing of the integer core on on the An chips since, it is a reasonable assumption that every Apple variant since is similar). On each and every page render. A tenth of a second is a long time (and a lot of battery) for what is often of minimal value.

sehrope 13y ago

This is even more so if your site is served over HTTPS given the latency for the initial SSL handshake[1]. Even better not to load anything and have it properly cached on the client side. If you do it right you don't even have the client send/receive an HTTP 304. For our app we have a lot of modular dependencies but we serve all of them from a unique prefix per build (eg. 'assets-SHA(build)/js/foo.js'). The second page load and beyond has zero requests for the same static asset. Whenever we have a new build of the app the unique prefix gets auto updated to force clients to use the latest versions. For HTTPS make sure to mark your assets as public or they won't be cached: Cache-Control:max-age=31557600, public [1]: http://www.semicomplete.com/blog/geekery/ssl-latency.html http://www.semicomplete.com/blog/geekery/ssl-latency.html

corresation 13y ago

Whether my DOM manipulation library consumes 4kB of that or 35kB isn't especially important to me. Now that jQuery 2.x drops IE 8- support, a credible question is whether such libraries (which are more in the 95KB range, minified) are even necessary at all. Quite outside of the time to download, there is a measurable cost to parse all of that boilerplate code as well. This has more of an impact on mobile, obviously.

dmethvin 13y ago
> Now that jQuery 2.x drops IE 8- support, a credible question is whether such libraries (which are more in the 95KB range, minified) are even necessary at all. Well my answer to the credible question is that jQuery has to normalize and fix bugs for just about all the browsers it supports, it's not just an oldIE problem. Plus, jQuery provides abstractions above the basic DOM operations which are pretty low level. So if you don't want to use jQuery you'd probably want some other library to provide equal or greater abstraction. > Quite outside of the time to download, there is a measurable cost to parse all of that boilerplate code as well. This has more of an impact on mobile, obviously. Measurable of course. Significant as a portion of the page load time for most pages? Well that's a different thing. And of course if you want it, jQuery 1.8+ provides the ability to create custom builds if you know you don't need parts of it.
- corresation 13y ago
  jQuery would never have come into popularity if not for oldIE and its often dramatic variances from competitors: If you are willing to forsake that old browser, there is little added but a layer of inefficiency between you and web standards. We have become so accustomed to jQuery that it becomes the default, many unaware of the dramatic improvements in all major browsers since. As to the cost, assuming that everyone is pulling it from the same CDN (and there aren't the often considerable times simply to check an etag, which is the case with the overwhelming majority of jQuery hosts), an iPhone 4S takes about 80-100ms to simply parse the jQuery file (and given the plateauing of the integer core on on the An chips since, it is a reasonable assumption that every Apple variant since is similar). On each and every page render. A tenth of a second is a long time (and a lot of battery) for what is often of minimal value.