Great project, which UIKit do you use? Is it Tailwind or something?
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 ;)
Show HN: A Full-Stack Web Framework for Go
61–70 of 103 posts
Re: Show HN: A Full-Stack Web Framework for Go
#62I 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.
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
Re: Show HN: A Full-Stack Web Framework for Go
#63Earlier quoted context omitted.
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 ment…
I just want plain HTML and some of {{ .These }}
You wish will be my command https://github.com/livebud/bud/discussions/8 :D
Re: Show HN: A Full-Stack Web Framework for Go
#64Earlier quoted context omitted.
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 ment…
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.
Re: Show HN: A Full-Stack Web Framework for Go
#65dude this looks awesome! can't wait to dive into this and learn a bit more. i come from a ruby, js and python background using frameworks like: react, django, rails, etc. always wanted to excuse to use GO and this might be it!
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 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.
Re: Show HN: A Full-Stack Web Framework for Go
#66Great effort in a great lang. Constructively speaking: Hacker culture could benefit from less frameworks to more low code/no code platforms (which is a space with more fertile ground)
I worried about this, but it seems like there's enough "framework supportors" in the comments!
Re: Show HN: A Full-Stack Web Framework for Go
#67I thought of building my own framework then I remembered dealing with http headers, ssl, and http2
That's the beauty of using Go. All of this stuff is provided by the standard libraries.
Re: Show HN: A Full-Stack Web Framework for Go
#68Whoa, 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
Looks super cool. Starred @tompston!
Re: Show HN: A Full-Stack Web Framework for Go
#69I'm experimenting with something similar as well, I'm curious - how do you solve HTTPS support since it's a built-in web-server?
Something like https://github.com/caddyserver/certmagic perhaps?
Re: Show HN: A Full-Stack Web Framework for Go
#70Cool 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…
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.