Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
xo
Command line tool to generate idiomatic Go code for SQL databases supporting PostgreSQL, MySQL, SQLite, Oracle, and Microsoft SQL Server (by xo)
-
gomodest-template
A template to build dynamic web apps quickly using Go, html/template and javascript
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Hey HN, I want to show you my side project. It's called Bud and it's a full-stack web framework for Go.
I created a 15m video to show you how to create a minimal Hacker News clone with Bud: https://www.youtube.com/watch?v=LoypcRqn-xA.
The framework is free, open source and MIT Licensed. You can find it on Github: https://github.com/livebud/bud.
I started working on Bud 2 years ago after watching the introductory Laracast videos about the Laravel web framework. I was just blown away by how productive you can be in Laravel. However, like many of you, I've been so spoiled by Go. I didn't want to go back to writing PHP, so I decided to try creating Laravel for the Go ecosystem.
At this point, I just had the following goal:
Be as productive as Laravel in a typed language like Go.
I got the first version working in 6 months and tried building a blog from it... It fell flat. You needed to scaffold all these files just to get started. If you're coming from Rails or Laravel you may shrug, this is pretty normal. Unfortunately, I've also been spoiled by the renaissance in frontend frameworks like Next.js. What I love about Next is that it starts out barebones and every file you add incrementally enhances your web application. This keeps the initial complexity under control.
With these newly discovered constraints, I started working on the next iteration. Bud should:
Generate files only as you need them. Keep these generated files away from your application code and give developers the choice to keep them out of source control.
Feel like using a modern JS framework. This means it should work with modern frontend frameworks like Svelte and React, support live reload and have server-side rendering for better performance and SEO.
With these new goals, the Bud you see today started to take shape. But along the way, I discovered a few more project goals:
The framework should be extensible from Day 1. Bud is too ambitious for one person. We're going to need an ambitious community behind this framework.
Bud should be able to provide high-level APIs for developers while compiling down to performant low-level Go code for production.
Bud should compile to a single binary. With platforms like Fly.io and Heroku, these days it's easy to not care about this, but I still cherish the idea that I can build a single binary that contains my entire web app and secure copy it up to a tiny server that doesn't even have Go installed.
It's still super early days. You can find the the Roadmap on Github: https://github.com/livebud/bud/discussions/9. I encourage you to contribute your thoughts.
And here's the current documentation for what's already in Bud: https://denim-cub-301.notion.site/Hey-Bud-4d81622cc49942f991.... Comments are enabled for anyone to chime in.
I have big plans for the framework. I hope you'll join me on this journey to build ambitious websites faster with Go!
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 there might still be JS-hydrated code if the Svelte component included something involving an interactive component).
I think the idea is to ingest a JS "template" and spit out the rendered HTML+JS, kind of like traditional SSR templates, but it could be possible to shoe-horn in an entire client-side router that gets initialized as a DOM object somewhere.
[1] https://github.com/rogchap/v8go
Whoa, this looks insane!
_shameless plug_
I kind of made an almost similar thing can generate custom boilerplate for backend servers a while ago -> https://github.com/tompston/gomarvin
- 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)
- 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)
Thanks for your comment and question @onionisfruit. Top-notch handle too!
>> What are your plans for models and persistence?
I haven't worked out all the details, but it's going to be some blend of https://github.com/xo/xo and https://sqlc.dev/.
Design goals:
1. High-level, type-safe "ORM" that's generated from your database schema.
Thanks for your comment and question @onionisfruit. Top-notch handle too!
>> What are your plans for models and persistence?
I haven't worked out all the details, but it's going to be some blend of https://github.com/xo/xo and https://sqlc.dev/.
Design goals:
1. High-level, type-safe "ORM" that's generated from your database schema.
Oh wow someone finally went ahead with the server rendered js in Go ! Looks great. I have been experimenting various ways to build web apps in Go: https://github.com/adnaan/gomodest-template. I have landed on pursuing one approach more deeply: server rendered html templates over websockets. Don’t have a lot of code right now but here are some examples: https://github.com/goliveview/examples.
Oh wow someone finally went ahead with the server rendered js in Go ! Looks great. I have been experimenting various ways to build web apps in Go: https://github.com/adnaan/gomodest-template. I have landed on pursuing one approach more deeply: server rendered html templates over websockets. Don’t have a lot of code right now but here are some examples: https://github.com/goliveview/examples.
Sure, it's actually been a long journey since PHP.
I switched from PHP to Node about 11 years ago. I was probably one of the first 100 Node.js developers. My biggest contribution there was creating https://github.com/cheeriojs/cheerio.
Go spoils me because it "just works". The best way I can explain it is when I'm stuck on something in Go, it's almost always my bad, not something that Go is doing poorly. This is in contrast to the Node.js ecosystem where it feels like half of the problems I run into shouldn't be my responsibility.
I relate a lot to this post by @kburke: https://kevin.burke.dev/kevin/one-year-of-node-js/
My transition from Node.js to Go happened because I was working solo on https://standupjack.com/ and I kept running into issues with the message broker. It was using the most popular RabbitMQ library for Node.js, yet was still super flaky.
About 6 years ago, I was chatting with TJ Holowaychuk and he kept singing Go's praises. One holiday I decided to rewrite the message broker in Go. I got it into production in 3 days and didn't have anymore problems with it. That set me on the Go journey :)
After I read the documentation in your project it feels like you really stepped on a lot of minefields. Great job!
One thing is still bothering me though (or maybe I missed it in docs): how is Bud dealing with realtive links? Very often JS writers forgetting about the situation when the application could be served under different root locations. Does Bud have helpers to construct relative URLs without relying on user-provided server url? (I made PoC for that - don't use it in production https://github.com/reddec/gin-template-manager/blob/eb09f4e8...)