I’d like to have only view-related logic and state in the client. I do not want to bring parts of the business knowledge and logic to the client. But out of the perspective of the library developer that does not matter - all the use cases have to be implemented anyways (if you would not need an API we wouldn’t be here).
You seem to have a completely different app in mind than me. (More of a classical web-page). I’m am very biased because I have the refactor of a specific app in mind (its a graphical planning tool for an electrical installation that lets you put devices and their logical connections on a floorplan. Close to everything has to be put in a database and there are many business decisions to be made, so : server-heavy).
I do not get the point of the next-js demo. Why is it better than having a reactive store?
I understood the premise of your original post like: you want to get a developer experience like LV for apps where you need so much JS that LV becomes awkward. Did I understand that wrong? (At least that is what I am looking for.) To get the LV-DX an important part for me is not to have to learn thousands of JS-tools and frameworks. I’m OK with replacing heex with a JS-UI-lib like react or solid, but thats it.
Also: all the issues you list here are either
- not avoidable if you rely on an API
- are in the StateChannel-approach not as bad as in LV, as you can keep as much of the state on the client as you like - LV cant do that. Reconnects I imagine can also be handled better.
right and very interesting experiments that is. Looking forward to a more involved next-js example.
I’ll try to write a more involved example with StateChannel and Solid.
