Yeah. The JS world is still so hung up about fat clients having all the control that it's missing all the interesting stuff happening in the server world. Rails Hotwire, Phoenix Liveviews, Laravel Livewire, etc. These solutions can solve 80% of your front end with minimal JS and almost no DX complexity.
Isn't it possible that both the frontend and backend are maturing & more capable? Isn't that what we want?
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 think sometimes people say "complexity" when they just mean "unfamiliar".
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).
Complexity has to exist somewhere, either in the engineer's hands, or swept under the rug for the framework to perform its magic on (really thinking about the Rails ecosystem here). When things go wrong, it's nicer, in my opinion, to have more control, especially in this fast paced clients-want-it-now environment.
In my experience, the complexity with most frontend development is accidental by way of splitting state between client & server.
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 ?
You either write HTML in JavaScript or write JavaScript in HTML. Personally, I would rather write everything in JavaScript/TypeScript than sprinkle syntactic sugar over HTML.
No offense, but you're thinking from the JS bubble.
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.
I agree. These solution are not meant to solve all the front end needs. But they can solve the majority of it (forms, modals with dynamic content, filtered lists, etc).
> I'd be happy to use a similar fullstack solution in JS/TS but afaik it doesn't exist.
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.
Is it not just the same tradeoff space we've been exploring since the beginning of UIs about how thin the UI is? It's not like putting stuff on the server side via livewire doesn't have strong disadvantages around latency etc.
> It's exactly the same latency that a request to an API will have.
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?
> Every interaction in a livewire type system requires a round trip
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.
Because front end specialists only think about the front end.
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.
As a primarily frontend-developer, I can attest to this sentiment. I should add that most backend devs I know understand the basics of HTML, CSS and Javascript, but they're less interested in learning new framework/library/template system constantly. I have to admit, I share that attitude.
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.
