4 ms·

The experience with js-heavy sites even on a very capable desktop is still negative. Too much js introduces bugs, latency, and lack of stability. A page like th

The experience with js-heavy sites even on a very capable desktop is still negative. Too much js introduces bugs, latency, and lack of stability. A page like that will sometimes jump around and resize for no apparent reason. Making wikipedia noticeably js-heavy would definitely ruin the experience.

tgsovlerkhgsel 6y ago
The size and amount of JS doesn't really matter. Whether it's well written and integrated matters. How many round-trips it introduces matters. The stuff that gives JS a bad reputation is sites that slap together nested widgets that each load their resources sequentially. If you serve a 1 MB blob of all_the_things.min.js on the first page load, then gzip reduces that to ~300 KB, which will take ~2.5 seconds to load on a 1 Mbps connection, and then it will likely be cached. If you serve a widget that loads another widget that adds a third widget, on the other hand, elements will keep popping in and your user experience will suck.
- capableweb 6y ago
  On a US-normal laptop 1MB of JS might not matter too much. But for a world-normal laptop + smartphone, the size of the bundle does matter, not just for bandwidth but for performance as well. Larger JS scripts takes longer time to parse so if you have a lower power device, it still gonna suck. Everything around your program matters, but for different audiences. Wikipedias reach is huge, and getting it to work and work well, for the lowest common denominators (think ~10-40 USD smartphones) is a pretty big job which includes thinking about sizes of all kinds. Edit: Ignore me, seems you're not actually replying to anything specific in the comment before you, so this all seems off-topic now.
  - tgsovlerkhgsel 6y ago
    This is a valid argument, and you do need to benchmark on underpowered hardware. My gut feeling that a 1 MB blob of JS is not a huge problem even for a cheap smartphone nowadays, and if it is, the HTML/CSS can become the bigger problem. I remember doing really silly-sounding things (like shipping a web app + the entire database) with excellent results. Even if the initial load takes a while, you can't beat the instant responsiveness of already having the data when the user clicks on another piece of content. Hundreds of KB of JSON on a 2013 smartphone (probably Nexus 4 or 5) was still a pretty good experience IIRC, at least on par with a modern web site on a modern smartphone. On a PC, I've mercilessly thrown hundreds of MB of binary data at JavaScript. In my experience, aside from long network request chains, the biggest performance killer is e.g. having nested Angular elements that all refresh every time you touch anything on the page, not code size. If you know what you're doing and care (e.g. diligently mark immutable stuff as such), you get excellent performance. It's just that most don't care.
    - velosol 6y ago
      In addition to underpowered hardware there's underpowered connections (e.g. bad satellite connections and rural cellular) where things like being able to turn off images in a browser can come in handy. While wikipedia might not be the typical site there, there is something to be said that a site that deals in information (like a generator's manufacturers page) should at least have a low-bandwidth option so you can access the textual information you need without pulling in a presentation layer that isn't critical.
  - rocho 6y ago
    True, but for apps which are meant to be interactive you also need to take into account SPAs that might make very small requests for a good while once the main bundle has been downloaded. So, for a world-normal device which one is better? A site that downloads 1MB of Javascript and then makes data requests of a few KBs or a site that makes a 300KB request with a page reload every time you interact with it? My general rule is that if the application is interactive, meant to be used for long periods of time and SEO is not an issue, well-written SPAs result in better UX. That's not the case of Reddit for example. Most users spend the most time reading comments, and that requires very little interactivity. So old Reddit is miles ahead of the new slow and bloated one.
    - capableweb 6y ago
      I agree fully with you! My point was not that the bundle size matters the most, but rather than everything matters. What matters most depends on your user-base of course. Expensive, professional tools that only works on Mac: fine with high requirements and bandwidth requirements. Free service whos goal is to spread knowledge everywhere in the world: need to think about cheapest devices on the worst networks.
- earthboundkid 6y ago
  1MB of JS is bad, and you should feel bad for delivering it. A content focused website should fully render without caching in under one second on a normal desktop. That is not possible with a meg of JS.

tgsovlerkhgsel 6y ago

The size and amount of JS doesn't really matter. Whether it's well written and integrated matters. How many round-trips it introduces matters. The stuff that gives JS a bad reputation is sites that slap together nested widgets that each load their resources sequentially. If you serve a 1 MB blob of all_the_things.min.js on the first page load, then gzip reduces that to ~300 KB, which will take ~2.5 seconds to load on a 1 Mbps connection, and then it will likely be cached. If you serve a widget that loads another widget that adds a third widget, on the other hand, elements will keep popping in and your user experience will suck.

capableweb 6y ago
On a US-normal laptop 1MB of JS might not matter too much. But for a world-normal laptop + smartphone, the size of the bundle does matter, not just for bandwidth but for performance as well. Larger JS scripts takes longer time to parse so if you have a lower power device, it still gonna suck. Everything around your program matters, but for different audiences. Wikipedias reach is huge, and getting it to work and work well, for the lowest common denominators (think ~10-40 USD smartphones) is a pretty big job which includes thinking about sizes of all kinds. Edit: Ignore me, seems you're not actually replying to anything specific in the comment before you, so this all seems off-topic now.
- tgsovlerkhgsel 6y ago
  This is a valid argument, and you do need to benchmark on underpowered hardware. My gut feeling that a 1 MB blob of JS is not a huge problem even for a cheap smartphone nowadays, and if it is, the HTML/CSS can become the bigger problem. I remember doing really silly-sounding things (like shipping a web app + the entire database) with excellent results. Even if the initial load takes a while, you can't beat the instant responsiveness of already having the data when the user clicks on another piece of content. Hundreds of KB of JSON on a 2013 smartphone (probably Nexus 4 or 5) was still a pretty good experience IIRC, at least on par with a modern web site on a modern smartphone. On a PC, I've mercilessly thrown hundreds of MB of binary data at JavaScript. In my experience, aside from long network request chains, the biggest performance killer is e.g. having nested Angular elements that all refresh every time you touch anything on the page, not code size. If you know what you're doing and care (e.g. diligently mark immutable stuff as such), you get excellent performance. It's just that most don't care.
  - velosol 6y ago
    In addition to underpowered hardware there's underpowered connections (e.g. bad satellite connections and rural cellular) where things like being able to turn off images in a browser can come in handy. While wikipedia might not be the typical site there, there is something to be said that a site that deals in information (like a generator's manufacturers page) should at least have a low-bandwidth option so you can access the textual information you need without pulling in a presentation layer that isn't critical.
- rocho 6y ago
  True, but for apps which are meant to be interactive you also need to take into account SPAs that might make very small requests for a good while once the main bundle has been downloaded. So, for a world-normal device which one is better? A site that downloads 1MB of Javascript and then makes data requests of a few KBs or a site that makes a 300KB request with a page reload every time you interact with it? My general rule is that if the application is interactive, meant to be used for long periods of time and SEO is not an issue, well-written SPAs result in better UX. That's not the case of Reddit for example. Most users spend the most time reading comments, and that requires very little interactivity. So old Reddit is miles ahead of the new slow and bloated one.
  - capableweb 6y ago
    I agree fully with you! My point was not that the bundle size matters the most, but rather than everything matters. What matters most depends on your user-base of course. Expensive, professional tools that only works on Mac: fine with high requirements and bandwidth requirements. Free service whos goal is to spread knowledge everywhere in the world: need to think about cheapest devices on the worst networks.
earthboundkid 6y ago
1MB of JS is bad, and you should feel bad for delivering it. A content focused website should fully render without caching in under one second on a normal desktop. That is not possible with a meg of JS.