There are some interesting things in here, like, in my view, correct assessment that SPAs are distributed applications that run on more then on computer at once.

And that there are many benefits towards making that code base the same.

But reading about LiveView I do not think its the future, or at best it's not feature complete to be the future.

Honestly, I think that partially it kinda goes against that distributed system as it forces to move rendering to server, kinda. And state as well.

I did bit of checking and it seems it will not be able to do something like a 3D game.

Or anything else that requires client side state and rendering.

Closest I ever got to what you describe here was using TypeScript both on client and on server using Node.js

And writing it in a way that there was no rest, or graphql.

It was one code base that was using same classes and code on client side and server side and communication layer was hidden.

You were calling asynchronous methods on objects and waiting for responses on client side.

And under the bonnet it was sending HTTP requests to server where same object was receiving same call.

Kinda like a remote procedure call thing https://en.wikipedia.org/wiki/Remote_procedure_call

In the end it starts to feel that there is no separation between client and server, calls are type checked, API always in sync, you are just writing single application with objects that call commands on each other in async way and do not care where they are, on client or server.

This also made me realise how to think about state.

That state has persistence. Some of it is not persistent at all. Like a form data in a popup that gets lost when you close and open it.

Some is persisted for a session.

And some is persisted in a database.

But what LiveView also fails to account for is true PWA. That work offline. Does LiveView work offline? No it does not support this case.

Along with ability to work offline and then sync your state with distributed system when you are going online.

I think future is more along the lines of conflict free replicated data types, like new Microsoft fluid framework. Distributed, collaborative conflict free applications designed for online and offline work so that you do not care about this. It should come out of the box. Whether its collaborative or not, whether it's offline or not, whether its server or client. Whether its mobile, desktop, watch, browser or some fridge...

So far I am curious to see what is gonna take off on top of web-assembly. And at this moment it seems that its Rust. But it's too early to say.

I do wish it was something more functional, I like many things you speak about here.

But I think that future is behind a tech that provides choice and freedom to do what you need to do for niche cases.

Kinda like TypeScript that allows to start writing proof of concept in JS style messy way to secure funding and then when you know what you are building and what is stable and what will be changing, only then start to cementing critical parts of application with strict types, abstractions etc.

Do I think that TypeScript is future? No, but it does have lot of good things in it.

I do want it to be more functional but pushing all state and rendering to server is not the future.

It is as backwards as pushing it all to the client.

There should not be server or client, there should be distributed application that syncs state between its computer parts and does work where it makes sense instead of forcing it to where it does not.