Live data from Hacker News

Show HN: A Full-Stack Web Framework for Go

github.com

21–30 of 103 posts

Re: Show HN: A Full-Stack Web Framework for Go

#23
post #12

Glad to see progress in this space. I couldn't find anything describing the paradigm used for the JavaScript frontend. From the video, it looks like things are fully server side rendered, i.e. no client side routing as-in SvelteKit or Next.js? Are the Svelte components hydrated+interactive after page load? In my experience so far with SvelteKit and other SSR+SPA frameworks, there are too many tradeoffs with hydrating…

I only browsed for a wee bit, so take this with some salt, but it _looks_ like the framework is running a JS VM isolate alongside the Go server struct[1], which gets called with whatever script file is being rendered. Since it looks like the render files are, at least in the case of Svelte, individually compiled JS files that are SSR rendered via the V8 isolate, I _believe_ you're correct that there is no CSR (though…

Browsing the runtime/view/ssr source code it appears to use esbuild (over the VM?) for rendering the svelte views while injecting the relevant code etc.

Re: Show HN: A Full-Stack Web Framework for Go

#24
Nice, with generics, some things that were hard are easier to do when it comes to polymorphism thus code re-use.

Go community has been pretty "anti-framework" (AKA "just use net/http" when it clearly doesn't solve every problems..., "don't put request scoped variables in context" when it's the very purpose of that interface...) and there was a lot of drama around some framework creators, unlike any other web language community I have seen by the way (remember Martini and the insane backlash? Iris and the constant drama, was that Iris, I don't even remember the name...) so it will be pretty interesting to see the reception for that framework.

One advice to the author, congrats but don't call your framework "framework", it's like the go community hate that word, just say "a set of useful libraries to help web development", it seems like euphemisms are easier to swallow for some...

Re: Show HN: A Full-Stack Web Framework for Go

#25
post #22

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 the video it says they are frontend agnostic and will be adding multiple frameworks soon. React was mentioned specifically as coming soon.

Re: Show HN: A Full-Stack Web Framework for Go

#27

Any plans to implement something like Phonenix LiveView? I've never used Go, but from what I've read I suppose it should work really well given Go's concurrency model. (The name "Livebud" gave some hope as well.)

There is https://github.com/jfyne/live which is probably what you're looking for.

Re: Show HN: A Full-Stack Web Framework for Go

#28
post #25
post #22

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 the video it says they are frontend agnostic and will be adding multiple frameworks soon. React was mentioned specifically as coming soon.

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.

Re: Show HN: A Full-Stack Web Framework for Go

#29
post #28
post #25

Earlier quoted context omitted.

In the video it says they are frontend agnostic and will be adding multiple frameworks soon. React was mentioned specifically as coming soon.

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…

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.

Post reply on HN