But the person you're replying to specifically cited SPAs, single page applications, as the use case for "download a big JS library first and then minimize future loads." If the SPA presents more than five 5kb chunks of what you define as "actual pages of content" to the user in a single session -- which doesn't sound at all unreasonable -- then using your own numbers, the SPA is now slightly beating your web site (2600ms to 2700ms). By ten "pages," the SPA has substantially pulled ahead (3400ms to 4500ms), and has still only sent 50kb of data past the initial huge hit. If the JS library is closer to the 2mb side than the 4mb side, it may well have already sent less data.

At any rate, the NYT page that Drew DeVault is complaining about isn't an SPA, and its problems don't stem from loading a JS library whose point is to make future requests faster. Its excessive JavaScript use is driven almost entirely by including advertising/marketing-driven code, and I would argue that JS is being a bit scapegoated here: it's a symptom, not the problem. I bet we could deliver a lean, mean, highly-optimized version of that web site that duplicated the exact same ads, down to the same obtrusive banner behavior. Would we like the site more then? Would any of us really respond, "Wow, it's so much better now that I can be frustrated by this terrible design in a tenth the load time!"?

I agree that there is a point where SPA's make sense. Like Gmail. If a user logs in, they're probably going to stay a while and use quite a few features. But I'd be willing to bet that the vast majority of NYT visitors will load just one page and then navigate away. If someone is browsing their search results and EVERY website developer assumes that their visitor is in-it for the long haul, that one user is going to consume 12mb of data to load 3 pages off of 3 different domains.

I believe the point of the post wasn't to demonize Javascript, but to point out that there are a lot of low-hanging fruit in the world of web design and that it takes very little effort for developers to simply look at their design in terms of respecting users bandwidth and only using what you need to get your message across.

NYT sent this guy 2.8mb of data from 5 different domains to communicate 9037 bytes of requested content. That should resonate with anyone using multiple Javascript libraries, especially the ones who are offended.

User expectations are very different for when they are starting work vs when they are in the middle of something. If it's really a SPA you can also disguise the load times with optimistic updates and such

Don't people still have data caps?

You can also stream in most of the assets while the user is trying to remember their username/password.

Shouldn't your static assets be cached in the browser for pages 2 and 3, making your subsequent pages load a bit faster than the first?

Also don't forget that frameworks like Phoenix, or alternatively aggressive optimization in other ways, can be significantly faster at that 'first load' than you describe.

Where do you see 26 megabit/s speeds? I live in US/Mountain time zone, have only ever seen such speed via my wired, local ISP land-line.