Making wikipedia noticeably js-heavy would definitely ruin the experience.
Making wikipedia noticeably js-heavy would definitely ruin the experience.
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.
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.
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.
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.
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.