Point of failure
Consultant frontend architect Harry Roberts got straight to the point: “In a word: No. In many words: Full JS apps are fine provided that a) They have their first render on the server, and b) They give me some content if that JS fails to load. It’s less about availability of JS, and more about not entrusting flaky network connections with delivering our entire app in one render-blocking package. That’s the problem. Don’t make JS your app’s single point of failure.”
“As long as you’re fine with the site completely failing because the browser is too old, or too new, or the user’s bandwidth is too constrained, or the server hiccups, or a firewall’s security policy blocks it, or a dependency goes sideways, or you accidentally drop a semicolon somewhere, then sure,” says consultant and author Eric Meyer, “it’s OK. What you build won’t be a part of the web continuum, and it will be needlessly fragile, but that’s a choice you can make.”
It’s all a matter of priorities, says the man who kicked off the debate in the first place, Nolan Lawson. “The question we should be asking ourselves is not how well our sites work without JS, but how well they work under poor or nonexistent network conditions,” he suggests. “These concerns are often conflated, but they’re not the same. Every year smartphones represent an increasing share of web traffic, but mobile networks have not caught up.
“So offline-first – treating the network as an enhancement with JS tools like Service Worker and IndexedDB – has become the new standard for building fast, resilient websites. It is possible to do both traditional progressive enhancement and offline-first, but it’s not easy. We should prioritise offline-first over works-without-JS.”
As long as it’s done well
Functionality before features
Power and responsibility