Looks awesome. livebud.com isn't resolving though so I can't install.
Sorry about that – fixed the installation script in all the places!
curl -sf curl https://raw.githubusercontent.com/livebud/bud/main/install.s... | sh
Show HN: A Full-Stack Web Framework for Go
31–40 of 103 posts
Re: Show HN: A Full-Stack Web Framework for Go
#32The install link doesnt work. I wanted to view what it did before I ran it `livebud.com/install`
Sorry about that, fixed the installation script in all the places:
curl -sf curl https://raw.githubusercontent.com/livebud/bud/main/install.s... | sh
Re: Show HN: A Full-Stack Web Framework for Go
#33I 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.
> I think using Svelte was a mistake
Why do you think that?
Re: Show HN: A Full-Stack Web Framework for Go
#34Very interesting, and using all of the latest tech. I was literally dreaming about combining Remix + Cloudflare Workers + Golang the other day. The only problem is Go would need to be compiled into WASM for that [0]. But this would provide one of the best experiences both in terms of development and performance/latency. [0] https://community.cloudflare.com/t/support-golang-natively-f...
Last time I checked, there was a limit of 1MB or so for deployment wasm in cloudfare workers. Is that limit raised? Go binaries easily run on tens of MB with the default http library.
Re: Show HN: A Full-Stack Web Framework for Go
#35Great project, which UIKit do you use? Is it Tailwind or something?
Re: Show HN: A Full-Stack Web Framework for Go
#36Congratulations on the launch!
I've been using Kenny Grant's Fragmenta[1] for past 3 years and I haven't had need for anything else because I like SSR with Go and aim to keep JS as minimal as possible. I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end?
I hope that you get to answer the queries in other comments regarding the design decisions reg CSR & V8 while using SSR.
Re: Show HN: A Full-Stack Web Framework for Go
#37Cool 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 `order.customer.region` that intelligently hit the database, because you can't override the dot operator. Instead you have to write unreadable crap like `regionController.Show(userController.Show(order.customer).region)` which is infinitely less "productive" than the former, for obvious reasons. Oh, you can `go generate` the *.Show definitions from a simple struct definition (or with 1.18 generics)? Too bad the final product is still unusable!
Use Go where it excels and connect it to your Ruby/Python/Typescript web backend over gRPC or HTTPS.
Re: Show HN: A Full-Stack Web Framework for Go
#38Glad 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…
Hey, excellent question.
You're correct that Bud server-side renders the 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. This is done using ESBuild. This is actually done 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.
Happy to go into more depth here or via email hi@livebud.com.
Re: Show HN: A Full-Stack Web Framework for Go
#39Congratulations on the launch! I've been using Kenny Grant's Fragmenta[1] for past 3 years and I haven't had need for anything else because I like SSR with Go and aim to keep JS as minimal as possible. I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end? I hope that you get to answer the queries in other comments regarding the design decisions reg CSR & V8 while usi…
Thanks for sharing! I'm quite surprised I didn't come across this project in my research.
> I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end?
Yes, that's a big reason. Half of it's preference, the other part is that most of the JS frameworks don't provide a cohesive solution for sending emails, queues, scheduling tasks, etc. The backend is a larger part of your web app than most JS frameworks give it credit for.
Their stance is to outsource the backend to third-party services, but then you're stuck piecing all these SaaS's together. I like the approach Laravel takes here: provide interfaces for Mailers, Queues, Scheduled Tasks, File Storage, etc. then provide implementations for SQS, S3, Mailgun, etc.
Just answered the question about SSR + V8 above!
Re: Show HN: A Full-Stack Web Framework for Go
#40Congratulations on the launch! I've been using Kenny Grant's Fragmenta[1] for past 3 years and I haven't had need for anything else because I like SSR with Go and aim to keep JS as minimal as possible. I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end? I hope that you get to answer the queries in other comments regarding the design decisions reg CSR & V8 while usi…
Thanks for sharing! I'm quite surprised I didn't come across this project in my research. > I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end? Yes, that's a big reason. Half of it's preference, the other part is that most of the JS frameworks don't provide a cohesive solution for sending emails, queues, scheduling tasks, etc. The backend is a larger part of your w…
[deleted]