matthewmueller

Bud author here, thanks for including Bud on your list. That's a really good overview of the landscape!

My take is that Remix + Next.js + SvelteKit are going to continue to innovate fast in the Frontend and "Backend for Frontend" space. Rails and Laravel don't hold a candle to the experience you get in that ecosystem.

But the JS ecosystem is massive and, as a result, fragmented. As you mentioned, there's no consensus on ORMs, mailers, queues, etc.

I don't see those frameworks trying to push too far in that direction, they'll remain "UI focused". This is nice for their focus, but not great for someone who wants to launch a web app and doesn't want to figure out all the surrounding ecosystem tooling.

This is where Laravel, Rails (and soon Bud) (and I assume Copper) will shine. They provide more tools and interfaces out of the box for building full-featured backends. These frameworks definitely need to keep an eye on the best ideas coming out of the JS framework ecosystem though!

Author of https://github.com/livebud/bud here, congrats on the launch Tushar! Looking forward to building up the Go web framework ecosystem with you!

I think an ORM like https://github.com/xo/xo with https://sqlc.dev/ as a fallback for complex queries will be a killer combo!

@reddec, thanks for chiming in.

Having path helpers absolutely needs to happen, something like: https://guides.rubyonrails.org/routing.html#creating-paths-a.... I'll probably get custom routing up before that though because I want to make sure the design covers changes to routes.

There's a whole layer of generated JS/TS that will eventually be built out here.

Agree with you on both accounts!

Starred!

Love seeing people experimenting in this space with Go! One of my favorite things about this HN post is everyone is coming out of the woodworks to share their ideas.

What's the advantage of rendering HTML templates over websockets? Is this similar to Hotwire where it sends you HTML fragments over websockets when you, for example, click on a button?

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 strongly relate to this post by Kevin Burke: https://kevin.burke.dev/kevin/one-year-of-node-js/. A lot has improved since this was written. We're finally over the ES Module vs CommonJS hump, Typescript has become the defacto standard, Babel is less used now and Webpack is effectively abstracted away. I still run into way too many problems with the ecosystem and the transition to Rust will make the ecosystem more complicated, not less.

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 client for Node, yet it 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 just 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 :)

Thanks for the comment!

I haven't actually used generics in any serious way yet. I haven't needed them. That being said, I'm happy they're in the language now and I'm really looking forward to seeing what the Go community comes up with during this period of experimentation.

I'm aware of the "anti-framework" ethos in the Go ecosystem. I think it comes from a good place, but there's room for other approaches. Go was created to build large-scale networked applications. The Go community deserves tools that are specifically designed for building web applications. Tools that are just as productive as Laravel, Rails and Next.js.

If this puts me at odds with some Go developers, I'm okay with that. We're probably just focused on different areas. Go is a big tent with plenty of room for different perspectives.

One thing I like about the code generation approach that Bud is taking is that there's more flexibility in the API design.

Need to break out of Bud's Controller conventions? Just pass a http.ResponseWriter and *http.Request and Bud will generate the glue code to wire everything up. You can go high or low-level depending on the problem that's in front of you.

I don't think this will appease the "just use the standard library" faction, but these kind of escape hatches will at least put a dent in their argument.

Yes, exactly. Even the creator of Node says so:

"I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever."

Heavy computation still ties up the event loop in Node.js. We're just not talking about it as much because most people deploy to serverless functions nowadays which can spin up compute upon request. I love serverless and use it with https://standupjack.com, but it comes with it's own tradeoffs!

You're exactly who I'm building Bud for! I fit squarely in your camp :)

Please hit me up when you give Bud a try over email hi@livebud.com or on twitter @mattmueller. I'd love to hear what you think!

>> I personally don't find the go ecosystem very good for people who want to goto market as fast as possible, the libraries are less developed and you're going to have to build your own stack.

Agreed, though when I do find a library it tends to just work. The challenge is finding the right library. There's no real reason for this though and I think with Go modules finally maturing and hopefully more web frameworks written in Go we're going to see an explosion in this space. Fingers crossed.

>> I'm now using Ruby on Rails in the next version, and I couldn't be happier - maybe it's not as fast, but it certainly helps me ship features faster to customers!

This is the spirit I like to see!

Yes! This might be the one I add to Bud! Seems like a more mature version of: https://pkg.go.dev/golang.org/x/crypto/acme/autocert

Not available yet. I did write the docs though, digging them up...

Created an RFC: https://github.com/livebud/bud/discussions/33. Feedback very welcome!

Hit me up on Twitter @mattmueller or over email hi@livebud.com. I'd love to hear what you're working on!

Thanks for your comment @pphysch!

So for authoring an app, I tend to agree with you. Languages like Ruby/Python/Typescript are probably faster to get something working.

I try to consider productivity holistically though. With Go, there's a lot less fussing with the tooling. I've also found Go saves a lot of time when onboarding new teammates. This is because of Go's intentional decision to be conservative with syntax. After all, most developer time is spent reading, not writing.

I respectfully disagree with your preference to split your backend up over gRPC or HTTPS. I prefer the approach Shopify takes to break up it's monolith: https://shopify.engineering/deconstructing-monolith-designin...

Bud will support something like this in the future.

Looks super cool. Starred @tompston!

That's the beauty of using Go. All of this stuff is provided by the standard libraries.

I worried about this, but it seems like there's enough "framework supportors" in the comments!

Thanks for the kind words @jacktheturtle! I like your handle. As the author of https://standupjack.com, all Jacks have a special place in my heart <3

Let me know when you give Bud a go! Feel free to email me at hi@livebud.com or hit me up on Twitter @mattmueller.

Agreed. I love Next.js and used it religiously for the first couple years. I'm not trying to beat Next.js or any framework. There's plenty of space in the web ecosystem for alternative solutions.

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.

You wish will be my command https://github.com/livebud/bud/discussions/8 :D

Thanks for your comment @dimgl!

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

Psst... I'm using https://www.untitledui.com. Please don't use it though, I don't want the whole web to look like UntitledUI ;)

Thanks @dougbarrett! Let me know when you give it a shot! I'd be curious if there's anything your implementation that you'd like to see in Bud. Hit me up at hi@livebud.com or on twitter @mattmueller.

Thanks for the kind words @dgb23!

Bud on a raspberry pi sounds like a fun weekend project! Let me know if you give it a shot!

It seems like fly.io is the best option right now for edge-optimized Go apps. My dream would be that Bud becomes something that Cloudflare simply can't ignore :D

Their reliance on V8 Isolates will make it difficult, but if they add Docker support at some point, then we're good. I don't see how Bud would work with WASM at the moment, but if someone gets it working, that would be a very pleasant surprise!

I'm more focused on getting Bud working well for deployment targets like Fly.io, Heroku, Lambda, K8s, Fargate and EC2.

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.

2. sqlc as a fallback to cover the more complex SQL queries in a type-safe way.

The hard part is going to figuring out how to support extending the ORM with your own custom methods, hooks, computed fields etc.

What do you think?

Samesies! I'll be recording a weblog demo in one of the upcoming releases. Need migrations and database access first!

Fun fact: It took DHH a year after he first introduced Rails to get that famous weblog demo up. This stuff takes time :)

I should add that lazy builds only happen in development. In production, it's all bundled at once.