Would have been amazing 10 years ago. Client side js is what would make this messy to use in big projects imho.
The developer experience is ridiculously nice in that ecosystem if you’re accustomed to it. So many QOL things have been dealt with and polished.
But I do love the idea of something like that dev experience with Go instead of JavaScript powering it.
Maybe this would be totally sufficient if you don’t want any SPA/interactivity features?
Some sort of live pipe to component state like LiveView or similar could make it so a lot of JS would work implicitly, which might give a lot of the dev experience and user experience ease that people want. I’m not sure. But I do think something would often be missing with this library.
Regardless, I love the idea and I’d be stoked to see it grow and improve the developer experience.
If you're going to shoehorn everything into "this is an app" or "this is a document" then you're going to have problems no matter what you choose.
My JavaScript modifies the DOM rather than creating it.
> My JavaScript modifies the DOM rather than creating it.
So (as usual) the key is to find the balance that works for you instead of pursuing one way (only server-side rendering or only SPA Javascript framework).
For the time being this approach works very well for me.
With every project that grew the need for UI state I either wished I went with client side rendering or did so from the start for the parts that needed it.
The issue is: manipulating the DOM can become hard to reason about. You either somehow manage to use the DOM as your source of truth, or you manually sync your state into and out of the DOM, and other things like the URL etc.
The “immediate mode” style GUI model is much easier to reason about, because you can think of each render as a fresh start.
You don’t need React for this, in fact other libraries do this faster and without additional complexity such as Lit. Plus if you use something with web components, it is easier to mix and match client side and server side templating.
While "it must be usable with JS off" was true decades ago for accessability and compatibility reasons, this isn't the case anymore.
In my case, the reason for changing and not creating the DOM with JS is pure simplicity. I'll just as gladly make something that won't work, because it cannot be changed this way. Because everyone except for a very few "mormons of the internet" have JS. Modern JS even.
Though, the simple idea of server-side rendered HTML that is enhanced with JS goes a very long way.
> or you manually sync your state into and out of the DOM, and other things like the URL etc.
The thing is: with server-side-rendered HTML, the issue of "State" is solved! Hypermedia is a state-machine (REST, HATEOAS etc). What is left, is "state" needed for rendering some variations.
You don't need to store state of routers, or the state of JSON objects being pushed through immutable-redux-saga-whatevers. All you need is some state to determine "the accordeon is closed" or "the dropdown is open".
I've applied my strategy to a client-side search system once. And while it worked, it quickly showed that actual state-management was needed. I used the URL/history-api to store all state - so that links where sharable, but there's only so much you can put into paths, query strings and anchors. I used HTML5 template tags for templates and components and some simple JS to fetch JSON from a search-backend and pull that through the template to insert into the DOM.
What I'm saying is: yes! I agree. You'll need proper and nice design patters or architectures to build a UI of any scale. But I'm also saying: if you move state-management to REST (the backend, server-side-rendered) what you are left with is simple enough that it needs no framework most of the time.
For example a multi-step form, where you can browse for options, have a lot of filters such as logic that displays different options based on previously selected ones and so on.
It's not that you can't do it via HTTP. But it's also wasteful. For this kind of stuff you don't need to pay for the round-trips. The server doesn't need to know anything about the UI state here. The only transactional parts are the entry point and the final result.
Things like these are a great place for "interactive islands". You can architect the skeleton and all the actually transactional parts as a normal HTTP/REST site, that exchanges HTML and so on. But for the parts that are really _just_ UI related state like the above, it's unnecessary work (compute/complexity/networking) to do so. Other examples include: interactive visualizations via SVG/WebGL, rich text editing and so on. All of those things are relatively common things.
What I was getting at above, is that it will get messy if you have JS state like that and but you don't write it in a way where the JS "owns" the DOM, from start to finish, for that component or island. It doesn't have to be react/redux or w/e. There are simpler, more performant solutions that lean on web standards and are much lighter weight like Lit etc.
As always: "it depends". I've built many use-cases where the server did really need to know about this. When we needed the intermediate state to be stored so that a user could pick up where she left. Or when we needed the telemetry/events of intermediate states being sent (e.g. "your ticket is now reserved for 45 minutes please proceed to payment") and so on.
What's more, and more important though, is that no:
> But it's also wasteful.
It is hardly wasteful. Hell, your "ga.js" HTTP call is probably heavier than doing a simple call to proceed the state-machine over HTTP. HTTP certainly isn't the problem: most likely the choice of a bulky and sluggish backend language/framework is, though.