People are evaluating this from a cold perspective to see if the system is working as designed or not.

He had a pretty reliable exploit on the most used browser, pretty sure it he could have gotten more tax free on the black market.

Now, with EDR widely deployed it's likely that the exploit usage ends up being caught sooner than later, but pretty sure some dictatorship intelligence agency would have found all those journalists deep compromise worthwhile...

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.

Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolutely, if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.

But SPAs came about in the days of jQuery, not React. You'd have a complex app, and load up a giant pile of jQuery spaghetti, which would then treat each div of your app is its own little mini-app, with lots of small network requests keeping everything in sync. It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. jQuery made it feasible to do SPAs instead.

Later, React and other frameworks made it less spaghetti-like. And it really took off. Often, for sketchy reasons. But the strongest argument for SPAs remains using them as a solution to provide a single-load of a large code bundle, that can be cached, to provide minimal network traffic subsequent to the load when the expected session time of a user is long enough to be worth the trouble of the complexity of an SPA.

> The way you make code last a long time is you minimize dependencies that are likely to change and, to the extent you must take such dependencies, you minimize the contact surface between your program and those dependencies.

A lot of value is driven from those dependencies though. Zapier as a pointed example: Zapier sans dependencies is ... well I don't even know. So sure, you could avoid dependencies at all cost, but at some point you might end up deleting the reason someone else wants to use your code in the first place.

Of course, if you're writing code only for yourself that will totally work, but most professional software engineers are not -- it's a balance and it's not fair to say all they have to do is stop writing glue code.

This seems like another case where jblow's opinions are guided by his experience as a game dev. Games can be "finished" and never touched again. I think I mostly agree with him that software could be made to be timeless to some degree. But, in the world of web apps and saas, the culture is to offload much of the work to third party libraries/APIs which locks you into a never-ending cycle of dependency management. I don't know if this culture is totally necessary (maybe to ship fast and keep up with security updates?), but in a world where users expect software to be constantly improving you can't expect anything to be "done". Maybe you could get close if you built everything in-house, but even still you have to keep up with security flaws.