Strongest possible disagree. I’ve been doing web dev for a long time, and the last 10 years has seen a massive, ridiculous increase in complexity across the board.
I personally took my company back to good old server rendered apps with a turbolinks overlay because I was sick of dealing with the full stack frameworks, and we saw a huge increase in productivity and developer happiness.
I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (needlessly) complex and so can be other libraries, but that doesn't mean the paradigm of JavaScript front-to-back is fundamentally flawed.
edit: Something else I should've added to my comment is that the HTMX approach is terrible if you ever need more than just the web-client (i.e. a mobile app, native or otherwise) since you will now have to implement an API anyway, which you could've done in the first place by taking the usual approach to development.
I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor.
They’re all cool until you have to actually maintain them. My favorite part is having to build my data models twice, one for the producer and one for the consumer. That’s totally never caused any headaches or slowed anyone down at all.
> I’ve used Angular, Dart, Backbone, Ember, Elm, React, Vue, Svelte, and a few others I can’t remember anymore. All in production systems, not demo projects. Also some of the “build it once” platforms like Meteor.
I must admit I've used Hotwire much less than I should've, but I still feel comfortable with full-stack JavaScript (or rather, TypeScript).
You said you migrated back to Turbo, what backend framework do you use? RoR with Hotwire is so nice, but I personally avoid it because of Ruby (not personally a fan), to be fair the same is true for most full-stack frameworks I avoid (such as Django/Python).
I really like the idea of systems like Phoenix’s LiveView as well, but I ask a lot of questions before I implement something like that. The majority of projects I’ve ever worked on didn’t really need that much interactivity and I strongly prefer the “sprinkle on JS when you actually need it” approach to web apps.
Unless your new client is a hybrid/webview/electron application, it's a trap. APIs for web, for native and public API have different sets of constraints in terms of authentication, versioning, even features are probably gonna be different.
And it's not like building an API after you built web would be complicated. Unless you put your business logic right into controllers/handlers, making an API would be just making a new endpoint that calls to existing application services. It's not free, it may not be trivial, but like other comment said, if you can afford a new client, you probably can afford an API for it