I think using Svelte was a mistake. That being said, I'm pretty impressed with the effort here. Looking forward to seeing how this framework evolves. Cheers.
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.
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.
I hope is that Go <=> JS/Svelte won't be too much of a context switch for folks.
I'm not planning on innovating as hard in the frontend space as Next.js. I'll probably just stick with SSR, add support for pre-rendering and build up the client-side runtime with features like prefetching and client-side routing. If something really cool comes along, we'll see.
I'll instead focus on the area where Next.js neglects: backends. DB workflows, mailers, queues, scheduling, pubsub are all coming to Bud.
As @drewry mentioned, we're aiming to be frontend-agnostic. Changing the renderer should be as simple as creating files with different extensions:
- index.svelte for Svelte
- index.jsx for React
- index.html for HTML
- index.gohtml for go/template
There's more information in this discussion: https://github.com/livebud/bud/discussions/8
Why do you think that?