It's still ridiculously complicated in so many other ways, ignoring backwards compat completely.
I wish I could describe my most recent attempt at migrating our app to the new Next 13 app router for an audience, on camera, on stage. The levels of confusion and dead ends, and configuration, and error screens, and the need for truly expert-level knowledge just to get things working as one would expect made me realize there's just no way this can survive as it currently stands. It's all an abomination. React is dead. FE is dead.
Please just give me back a simple React.renderToString mounted into an express wildcard route, hooked into react router. All of these perf concerns are for the .0001% of people who even notice this shit, or need things to run so ideologically fast that they're willing to throw out every bid of common sense in service to an abstraction that is DOA as soon as you use it to do anything complicated at all, or apply it to an existing codebase.
As an interesting contrast, I work on a WPF app professionally that has been around for sure since .NET 3.5 (with references to .NET 2.0 DLL's at times) - at least 12 years - and as much as we give MS crap for abandoning WPF, I can still crank the project open in the latest Visual Studio, probably transparently upgrade to .NET 6 - and everything just works. There are a lot of advantages to web-based frontends but sometimes I think desktop apps are underrated from a stability perspective.
Windows native desktop apps are OK in some controlled (or mandated) environments. For example, 20 years ago I was working for a large company that handed only Windows XP laptops to every single employee.
But what if the customer has a mix of Macs, Windows, Linux laptops? Or if before even getting there, they think that they want a web app so they engage only companies that build web apps? A native desktop app will never happen.
By the way, that company I was working on 20 years ago, despite being Windows only had a number of web apps, including timetracking and everything else. I didn't investigate the reasons but I could guess one: distribution of updates.
Yes update speed, iteration speed and general ease of deployment is a huge part of it. Also the ability to develop on Mac/Linux but deploy to Windows.
One of the popular features of the desktop deployment tool I like to shill here sometimes is web-style "aggressive updates", which basically means synchronous update checks on every launch. If the user starts the app and there's an update available a delta is downloaded, applied and the app then launches all without any prompts or user interactions required. As long as users restart the app from time to time it means they stay fully up to date and so bugfixes can be deployed very quickly. This isn't quite as fast a deployment cycle as a multi-page web app, but is comparable to a SPA as users can leave tabs open for quite long periods.
Weirdly, AFAIK no other deployment tool has a feature like that. It's unique to Conveyor. Desktop update tech is pretty stagnant and is optimized for a world where updates are assumed to be rare and optional, so support for fast delta updates or synchronous updates are often rough/missing. When your frontend has a complex relationship with a rapidly changing backend / protocol though, that isn't good enough.
Also we made it from the start be able to build packages for every OS from your dev laptop whatever you choose to run, no native tooling required. So you've got a deployment process very similar to an HTML static site generator. Hopefully this closes the gap between web and desktop deployment enough for more people to explore non-web dev.
If memory serves correctly, I think that's close to how ClickOnce worked/works? - but Windows only. One of the apps I worked on does it, but it was a homegrown framework. Definitely the sort of thing it's nice to delegate to a specialized system where possible.
Well Java Web Start could do it also I think, but none of these systems are active anymore and of course none of them were a "native" desktop experience.
Too bad Microsoft refuse to work on proper cross platform WPF support. I've tried Avalonia UI[0], but it's just not the same. For instance the lack of a proper out-of-the-box virtualized list.
The app router is definitely not a valid alternative for my current projects on page router. I'm glad I'm old enough not to jump on shiny new things and burn myself in the process. I would actually like to take a step back from Next.js and move to something more simple. Ideally still server side rendered .TSX but with some jQuery like interactivity sprinkled on top on the client.
I wish I could describe my most recent attempt at migrating our app to the new Next 13 app router for an audience, on camera, on stage. The levels of confusion and dead ends, and configuration, and error screens, and the need for truly expert-level knowledge just to get things working as one would expect made me realize there's just no way this can survive as it currently stands. It's all an abomination. React is dead. FE is dead.
Please just give me back a simple React.renderToString mounted into an express wildcard route, hooked into react router. All of these perf concerns are for the .0001% of people who even notice this shit, or need things to run so ideologically fast that they're willing to throw out every bid of common sense in service to an abstraction that is DOA as soon as you use it to do anything complicated at all, or apply it to an existing codebase.