‘JS is more fragile’ is a stance common among Progressive Enhancement advocates (and I’m certainly guilty of this myself).
Getify is right to push back on the statement so I’ve been thinking about how I would rephrase it.
(This is also a followup of sorts to the blog post I wrote a couple of days ago.)
The best I could come up with is, instead of ‘JS is more fragile’, to say ‘complex apps are more fragile and JS is a powerful enabler of complexity’. Less catchy, sure, but sometimes less catchy is what you need.
The ultimate cause of JS’s perceived fragility isn’t some inherent flaw in the tool but that it’s often used to create fragile products. It’s a cognitive lever that lets you build products whose complexity (and maintenance overhead) is out of proportion with the effort involved in making them. That lever comes with a downside which are substantial additional difficulties in error handling, state management, and dealing with changes in the execution environment.
Progressive enhancement, conversely, tends to be a more complex development process (juggling HTML, CSS, and JS can sometimes border on being a nightmare) that results in a simpler implementation. It’s a different tradeoff. The economic rationale for progressive enhancement is generally that simpler—more robust—products have greater reach and lower long term maintenance costs, which leads to a larger customer base, which in turn results in a higher return on investment. So: more complex process, simpler product, and the product is the thing that makes money.
One of the downsides of progressive enhancement is also an inevitable consequence of its core tradeoff: simpler, more reliable implementations have an upper limit on their capabilities. Sometimes you really do have to build a complex product.
Sometimes that simpler solution isn’t no-JS but simpler JS. For example, if you can figure out a way to avoid having to do client-side state management, you should do so—state management being a frequent source of bugs in modern web applications.
There’s no reason why a set of simple forms on a government website should be implemented in Angular when they could be implemented more reliably and with greater reach using built-in features of HTML and CSS (with some JS for Ajax and for filling in the validation gaps).
This philosophy doesn’t apply to every website out there, but it sure as hell applies to a lot of them.