To me I think the approach of Hotwire, LiveView, Django-HTMX etc. is more interesting for a Go framework, since websockets/async are baked into the Go language.
In other words, render the HTML in Go and ship the diffs to a small blob of JS running in the client over a websocket, instead of baking a whole React build into your server-side app. Much simpler toolchain this way, much easier to reason about.
I appreciate that this is a fairly different solution; one of the author’s explicit goals is that it should “Feel like using a modern JS framework”. Personally I’d rather have it “feel like I’m using Django / Rails”, except with most of the superpowers that were historically FE-framework-only.
Where nextjs kicks ass is that coding front end interaction (sans back end interaction) and doing interaction in response to server feels almost identical.
There is no “ugh ok … better set up react now” feeling to make say an interactive chart because it was always there.
Similarly there is no “ugh ok … better set up a backend now” feeling you get using create-react-app as it was always there.
There is almost no mental gear switch as you switch from front to back to front.
The only small negative is you need to be careful what that first “server side” render produces and what it can access. But that is also part of the magic, as you can fine grain control the initial flash of content. For example include the layout/menus. Or include a cached view of a list that then updates on final render.
It just feels so well integrated more than any other framework I have tried (like aspnet mvc or RoR for example).
It will be hard to beat: If you want to beat it in Go you need at least a good Go->JS transpiler so you can use the same language. But even then anything other than JS/Typscript means I need a mental modal of what the transpiler is doing. I don’t get a free pass
on understanding JS or the DOM.
theptip|3 years ago
In other words, render the HTML in Go and ship the diffs to a small blob of JS running in the client over a websocket, instead of baking a whole React build into your server-side app. Much simpler toolchain this way, much easier to reason about.
I appreciate that this is a fairly different solution; one of the author’s explicit goals is that it should “Feel like using a modern JS framework”. Personally I’d rather have it “feel like I’m using Django / Rails”, except with most of the superpowers that were historically FE-framework-only.
quickthrower2|3 years ago
There is no “ugh ok … better set up react now” feeling to make say an interactive chart because it was always there.
Similarly there is no “ugh ok … better set up a backend now” feeling you get using create-react-app as it was always there.
There is almost no mental gear switch as you switch from front to back to front.
The only small negative is you need to be careful what that first “server side” render produces and what it can access. But that is also part of the magic, as you can fine grain control the initial flash of content. For example include the layout/menus. Or include a cached view of a list that then updates on final render.
It just feels so well integrated more than any other framework I have tried (like aspnet mvc or RoR for example).
It will be hard to beat: If you want to beat it in Go you need at least a good Go->JS transpiler so you can use the same language. But even then anything other than JS/Typscript means I need a mental modal of what the transpiler is doing. I don’t get a free pass on understanding JS or the DOM.