I had an example of how a fallback might work in the deleted JS thread, but it got really messy, fast.
The problem is, there’s no real substitute for the JS API in the absence of JS. Let’s say an onClick
handler is attached to a (non-submitted) button that should send a GraphQL request via a WebSocket, get some data, and update the local state which in turn refreshes the DOM without a full page reload. How do you simulate that in plain HTML? Form handlers won’t work - you’d need to explicitly submit a form by either hitting inside <input>
tags, or click a button with type=submit
. Even then, you’re limited to POST data, which would mean preserving some kind of state. This was the domain of ASP.NET view state, years back, and even that (IIRC) required some level of JS buy-in.
Unless you’re doing the absolute most basics - submitting forms, and clicking <a>
links - there’s really no ‘graceful degradation’ these days for even rudimentary parity with basic app expectations.
JS is 99%+ supported, by default. No plugins, no workarounds - it works in 995 out of 1,000+ visits. For those other 5 out of 1,000 edge cases, you need to make a business decision as to a) why those users have JS disabled and b) whether there’s a ROI working around it.
I’d argue that for the majority of cases, in all but very few exceptions, a simple message asking users to enable JS would be sufficient.
As I said elsewhere, not once in the last 10 years of building anything for online (across many verticals, covering many demographies and geographies) have I ever encountered a scenario where it was necessary to design for a non-JS environment. This has nothing to do with designing Javascript properly, btw. There are plenty of examples of where it’s done badly. But done right - with good asset loading strategies, minification, and efficient code that won’t kill resource-constrained devices, there has been zero occasions where a customer/user has ever written in to complain that the site/app required JS support.
If there’s a need to consume parts of your site/app outside of JS, that’s what REST endpoints are for.
It’s just not a design consideration today. Back in 1998 when I started, absolutely it was a concern. Even in the mid-2000s, when JS support was patchy and non-standard, there was an argument for it. But in 2019, when virtually every mainstream web browser released in the last decade has it enabled by default? This is an old problem that really doesn’t warrant workarounds, for all but the slimmest of use-cases.
(Apologies @AstonJ if this risks repeating the previous JS thread… this is intended to conclude the point rather than branch off into a separate discussion!)