It isn't faster than not re-requesting the resource at all because it was previously downloaded from the CDN which is what the discussion is about.

Yea you can still not bundle the actual library and grab it from a CDN, using webpack externals[1]. Using webpack doesn't really change anything.

[1]: https://webpack.js.org/configuration/externals/

> Now that everybody's hot new SPA has a few hundred thousand NPM dependencies, you roll it all up using Webpack and can just as easily `npm install jquery` as `<script src="cdn.jquery.com"></script>`.

Just because you can doesn't mean you should. You usually don't want some huge javascript bundle to load it's bad for page load performance. Also Webpack allows you to chose whether you want to bundle a dependency locally or grab it at runtime from a CDN or another sever.

Most of the dependencies are for the Node dev tooling and never gets deployed. You can easily build a lightweight Vue/React site with Webpack.

Sorry, but the entirety of GOV.UK is built using progressive enhancement. I’m assuming you don’t believe that a site with 300k+ public documents, multiple hundreds of user critical services (including some built with React and other modern frameworks), and serving 100m+ pages a month is a toy site. To honest answer is that we couldn’t afford to go down in the case of missing or broken JS, regardless of how it was broken (be it CDN failure, deliberate user choice, or some other reason like proxy failures, users on mobile connections that drop out half way through page load, etc etc).

No. It's just a problem of laziness, and possibly ego, of developers.

There are apps using browser as execution environment and there are websites. You wouldn't expect a client-side drawing tool, WebVR game or real time visualization of blockchain transactions to work without JS enabled.

However, you can easily expect a social network, mail client, news page, task app, and to some extent even things like IM to work with no JavaScript. "That's core" is just an excuse for poor architecture - it's only core because you chose to make it so.

There are apps and there are websites, with only some small part of grey area in between. If you're a web developer wanting to use newest, greatest trendy tools, you see everything as apps, despite of common sense suggesting otherwise, and you end up with no progressive enhancement for no good reason. When you take it to extremes, you end up creating such abominations like the old SPA Twitter frontend, spinning the fans of your laptop for 15 seconds just to display 140 characters of text, because "the core" is implemented as AJAX calls and fully rendered client-side.

I didn't know the term was progressive enhancement, but if it is what I think it is, it's a great thing to aim for. Sometimes users (probably more on HN) like to browse without js enabled, and some people also need websites that are accessible in a more basic environment, whether it be for screen reader, console web browser, archive.org, or simply older browser. Worse case scenario if the JS breaks and throws and error on older browsers, essential content should still be available, especially the content. There's nothing more irritating than "you need JS to view this page" when not appropriate or just an empty page when some dependency breaks due to human error. Instead, if the search button's popup box with suggestions won't work, fall back to just linking to the search page. Use <noscript> to redirect people to a basic version of some interactive content if you need to. Yes, the latest greatest is cool, but I still think it's in style. It also restrains how dependent I am on the perfect javascript, preventing too much JS Lag from building up in my libraries. Of course this is just my opinion

You in Australia? We built 9now.com.au using a degree of ‘progressive enhancement’ thanks to server-side react. I left a while ago, but Normally, users get a single-page-app-like complete with prefetching to instantly display subsequent pages. Turn JS off and it ‘degrades’ into a typical server-rendered experience. Sure, get far enough in and some things will break (videos won’t play), but we were pretty happy about this degrading nicely.

We built Qantas’s in flight wifi portal using this same technique, a necessity to deal with providing users with an instant ‘web’ experience over a high-latency connection.

Toy sites or for academics? Hardly.

> So yes, by choosing a JS-only environment you’re prioritising developer needs over user needs.

Even according to your own statistics, we're prioritizing 98.9% of user's needs over 1.1% of user's needs (or more accurately 99.2% of users against the broken 0.8%, since we won't do anything for the 0.3% who decided to break it on purpose).

Resources allocated to 0.8% of the userbase aren't free, they come from time that could be better spent improving the experience for everyone else.

> That’s potentially fine if the cost balance equation works out that way for you, but it’s a specific choice you’ve made to not support people who through no fault of their own don’t meet the requirements of the environment you’ve decided to create.

That's fine. The same 0.8% with a broken browser or proxy won't find elsewhere on the internet any more friendly to them. The best they can hope for is a small slither of sites with fallback, but the user experience will be so terrible they're better off just fixing the issue than continuing.

I find it funny that people spent years making these same arguments, but used assistive technologies as their cornerstone, now that assistive technologies (and the aria standards) fully support rich JavaScript sites, the argument has shifted to some hand waving minority that cannot even be quantified. We both know this is really about the NoScript crowd (and similar, like RequestPolicy), the other people with a broken web experience have far more significant issues that no one site can hope to mitigate.