Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Full-Stack Web Framework for Go

github.com

Post reply on HN
Print view View original

41–50 of 103 posts

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

#41

Post by matthewmueller »

ammanley wrote: post #16
mavbo wrote: 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…

Nice sleuthing! Bud heavily relies on https://github.com/rogchap/v8go

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

#42

Post by matthewmueller »

throwamon wrote: post #7

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.)

I haven't looked too closely at LiveView yet. I did flip back and forth between going with the Hotwire approach (I guess inspired by LiveView?).

It was a tough call, but I ultimately decided to server-render JS. This thought-experiment helped:

• If Ruby could natively render Javascript, would they still choose the Hotwire approach? I concluded no. I don't see the reason to have multiple approaches (HTML over wire, Stimulus), when one solution would suffice. The one solution also happens to be way more familiar to today's frontend developers. I definitely didn't want to make another templating language.

Bud will eventually ship with it's own JS evaluator. Either through https://github.com/dop251/goja or through porting https://github.com/bellard/quickjs to Go (~25kloc of C)

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

#44

Post by matthewmueller »

rnewton wrote: post #9

Your site's DNS is currently not resolving. Should provide alternate install instructions for cases like this. https://www.whatsmydns.net/#A/livebud.com

Truth. Website coming soon! This post exploded way more than I expected. Can't complain!

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

#45

Post by matthewmueller »

DoctorOW wrote: post #30

See also: Buffalo https://gobuffalo.io

Yep, Buffalo and Bud share a similar ethos, with completely different approaches.

Bud uses modern FE frameworks and leans heavily into making code generation work well to give you type-safety and higher-level APIs.

Buffalo is farther along in the journey with database migrations, mailers, etc.

Unfortunately, I think Buffalo is no longer in active development. The main author left his own #buffalo Slack channel in gophers.slack.com.

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

#47

Post by minism »

pphysch wrote: post #37

Cool project but I think building a full stack web framework in a language without features like operator overloading is a fool's errand. Yes, Go has nice standard templating and HTTP serving libraries, and nice dependency management. These are all important features for a web framework. No, it will never be productive as its competitors in the web framework space, because you simply cannot write expressions like `or…

I see where you're coming from, but tbh the more I work on web backend code the more I disagree with this. I really think database interactions should be made explicit, even early on, rather than hidden by ORMs (or overriding a dot operator).

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

#48

Post by matthewmueller »

mstef9 wrote: post #6

People interested in this might also find my project Pagoda [0] interesting. It's a full-stack web dev starter kit for Go, rather than a framework with any strict patterns or lock-in. It leverages Echo (web) and Ent (ORM) but they can be easily swapped out, if desired. It also has HTMX [1] integration to create slick/modern UI behavior without writing any JS. [0] https://github.com/mikestefanello/pagoda [1] https://h…

Thanks for sharing @mstef9! I somehow missed this one in my research. I'm a huge fan of all efforts to make Go a serious contender for building full-stack web applications.

Ent is a nice choice for the ORM. For models, I'm planning to go with a combo of sqlc + xo. I want to tie the DB schema to your application.

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

#49

Post by matthewmueller »

sunfmin wrote: post #46

People interested in this might also find my project interesting: https://docs.goplaid.dev , https://github.com/goplaid/

Thanks for sharing @sunfmin!

I perused the documentation and I can tell a lot of thought went into this. I appreciate the simplicity and applaud all efforts to make Go a serious contender in the full-stack web framework space!

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

#50

Post by matthewmueller »

ehaughee wrote: post #8

This looks cool. I know effectively nothing about Svelte so some of these questions may be coming from that ignorance....but can you talk more about the embedded V8 instance (what's it doing?) and also what gets sent across the wire? Is it the usual HTML and JS or is there any server-side rendering going on? How big is the binary for the HN demo? What's the story for static assets like video or images? I've started u…

Thanks for your comment @ehaughee!

Great questions. I answered some above, so I'll copy some and then answer your other questions below:

>> what's it doing?

Bud server-side renders Svelte files, then hydrates them on the client. This is similar to what most other JS frameworks do, it works like this:

1. Create two builds: one for server, one for browser. Both are built using ESBuild. In development, builds happen lazily upon request, similar to how a CDN like esm.sh would build JS to be imported. This will hopefully allow the build system to scale for larger apps. Vite was my inspiration here, but it's all done in Go.

2. V8 and the Svelte compiler are baked into the bud binary. When a request comes in, V8 evaluates the compiler running the server-built page and returns HTML. That's a mouthful, hopefully that makes sense.

>> what gets sent across the wire?

What gets sent over the wire is HTML. That HTML then has a script tag which requests the client-side version of the page that's used to hydrate the HTML and make the page interactive.

>> How big is the binary for the HN demo?

I just checked the binary size and it's 47.6 MB. It's mostly V8 right now, but will definitely get larger as you add more assets. I haven't tested it yet, but hopefully you'll be able to rsync just the diffs to a server.

>> What's the story for static assets like video or images

You can add them in the public/ directory. There's documentation here: https://denim-cub-301.notion.site/Hey-Bud-4d81622cc49942f991...

---

Let me know if you give Bud a go on your side-project! Happy to go into more depth here, over email hi@livebud.com or on twitter @mattmueller

Post reply on HN