I've built some feature-rich FE apps that read and write to dbs & object stores with no servers needed! Very portable, the only install step is to upload a few files. They can be run right from a simple CDN. And they are super fast.
Most FE devs I know are actually familiar with Hotwire and friends but to them those stacks would add DX complexity. I think sometimes people say "complexity" when they just mean "unfamiliar". Both FE and BE can be way overly complex, but neither needs to be.
I do mean actual complexity.
With something like Hotwire/Livewire you don't need APIs anymore. You also can scrap client-side fetch() code and state management. There are some features that will still need some client JS but these will be a minority of use cases (if at all).
If you manage to consolidate nearly all state to the server, complexity reduces by an entire dimension. There is nothing to synchronize anymore. You don't need these universes of delta-detection tools, frameworks, protocols, etc.
In most of our modern SSR apps, the only state the client needs to hold onto is a session token. If we find the client has a wrong session token, correcting this is quite simple. Everything else happens on the server.
Certainly there are holes with SSR (latency), but we haven't run into a real-world scenario where this actually matters enough to introduce entire new universes of hell into our lives.
What is the complexity you are talking about here, is this the human (programmers) understanding of the system or the design of a complex system itself ?
But wouldn't a solution that makes you more productive allow you to deliver faster?
That's what Livewire/Hotwire/etc are trying to achieve. Make developers more productive.
When going full on SPA there's so much complexity you need to solve. Crossing the client/server barrier with APIs, managing state in the client, etc.
Yes, ultimately you need JS to interact with the DOM but if you look at eg Livewire the orchestration is in the server. I'd be happy to use a similar fullstack solution in JS/TS but afaik it doesn't exist. And it doesn't exist because the JS world is still hung up on full on fat reactive clients which are overkill for the immense majority of use cases.
If you mean, a fully TypeScript full stack solution then you might be correct. I wouldn't know because I tried Deno earlier this year and it wasn't great.
If you mean, a full stack solution that utilizes TS to for both the API and for the frontend then that is a much easier find. Vercel's Next.js provides this out-of-the-box and various other full stack starters and boilderplates exist.
I recently built one using PgTyped and typescript-rest.
It's exactly the same latency that a request to an API will have.
Obviously Livewire is not a good option for interactivity that happens exclusively in the client.
Every interaction in a livewire type system requires a round trip - that's not true for SPAs. Let's say I'm developing a node based editing UI with drag and drop that lets me connect things. How on earth are you going to make that work with livewire?
You’re wrong on this. You’d use Alpine and do the interactivity client side. If you don’t miss use the tool, Livewire is supposed to reach to the server in the same situations an SPA would reach to the server (updating or refreshing server state)
I'm still keen to learn more on the Inertia side of Laravel, but Livewire (and especially with Filament in the mix) just feels insanely productive as a Laravel dev.
It's funny how webcomponents alone are touted as an "alternative" to a framework, despite only being one component (no pun intended) of something that solves the problem of UI state-synchronization on the browser. A better comparison would be comparing a combination of custom elements, server-side rendered HTML, and proxy objects to some SSR framework like NextJS, Remix, etc.
The tide is slowly turning though with Next, SvelteKit, Remix, etc. But still these frameworks are basically just rendering HTML and going full on fat client which is overkill for 80% of interactivity in web app but adds a lot of unnecessary complexity.