My experience has been different – and increasingly so over the past 30 years. Crashing or leaking desktop apps are a rare experience nowadays. When it happens, it’s always an "oh, really?" moment. On the web… I often can’t even write a Facebook comment without refreshing the page.

Good defaults definitely matter. But not overloading an app with functionality matters as well. Matching feature sets to actual user needs also matters.

The problem with state restoration is that it’s one of those features that looks simple, yet can be extremely tricky to implement correctly – the point you already made. And there’s no single solution that will fit all cases, or even 80% of them. Restoring scroll position is one thing, but restoring an unfinished video editor timeline is another. Both look deceptively simple ("I just reopened the crashed app and it opened at the exact same state"), but the internal mechanics require wildly different mechanisms and trade-offs.

I do agree, however, that frameworks and SDKs should provide properly designed mechanisms for state restoration – and they often do (like the State Restoration API on iOS/macOS).

But the argument that "state restoration should be default and provided by the environment" feels like post-rationalization of the existing mechanics.

> It’s like the Erlang approach to errors, but on steroids

The Erlang approach was intentionally designed that way. Web apps’ normalization of "restarting" is just a testament to how normal buggy software has become in the web ecosystem. Anyone who has ever tried to buy tickets online or register through a simple form on a government website knows that even for such common use cases, it’s extremely hard to create a good user experience. There are some fantastic web apps nowadays, and government-backed design systems and frameworks that sometimes match native apps’ experience – but that only proves the point. It takes an enormous amount of effort to make even simple things work reliably on the web stack.

The core reason, of course, is that the "web stack" is a typesetting engine from the ’80s that was never designed for modern UI apps’ needs in the first place. Why we still use a markup language to build sophisticated UIs and think it’s fine is beyond me. I recently saw an experiment where someone played a video in Excel, using spreadsheet cells as pixels and a lot of harness code to make it work as an output device. It’s doable, but Excel was never designed for that. No matter how many layers of abstraction we put on top – or how many ExcelReact frameworks we create – the foundation is simply not right for the task.

And yet people continue to justify the “defaults” of the web stack as if they were deliberate design choices rather than byproducts. Like, "it’s so good that everything is zoomable," or "I like that everything is selectable". Which sounds fine – until it doesn’t. Why on earth would I need to select half my widget tree with a 3-pixel mouse shift? And when I really do need to select something, it often doesn’t work properly because developers take it for granted and never verify or test it.

Or zooming – whenever I zoom a Facebook page to write a comment, the view keeps jumping around because some amazing piece of JS crapcode decides to realign the interface on a timer (to show ads?). Nobody on Facebook’s QA team probably even tests how the comment section works when zoomed in Safari. The web app experience is simply one of the worst, due to this messy feature set people call "good defaults". And as someone who also has to write web apps from time to time, I can’t stress enough how disproportionately more effort it takes to make an app with sane, good default behavior.

(P.S. There are some good things in the current state of the web stack – but they’re mostly the product of the industry’s sheer size, not the stack itself.)