[HN Gopher] Show HN: A Full-Stack Web Framework for Go
___________________________________________________________________
Show HN: A Full-Stack Web Framework for Go
Hey HN! I want to share my side project with you. It's called Bud
and it's a full-stack web framework for Go. I created a short
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!
Author : matthewmueller
Score : 498 points
Date : 2022-05-13 19:01 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dinvlad wrote:
| Very 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...
| matthewmueller wrote:
| 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.
| mayama wrote:
| 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.
| grose wrote:
| AFAIK that is still the limit. You can try and use TinyGo to
| reduce binary size but it's an uphill battle:
| https://nicholas.cloud/blog/continuing-hijinks-with-
| cloudfla...
| DoctorOW wrote:
| See also: Buffalo
|
| https://gobuffalo.io
| matthewmueller wrote:
| 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.
| mdw wrote:
| I started with golang as the basis for my SaaS I've been
| building now for 2 years, the first version that shipped (and
| is still in production) is based on Go.
|
| 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.
|
| Bud and Buffalo seem like great developments, but your
| comment about the Buffalo one no longer being in active
| development would just totally suck if you had invested your
| time into building your SaaS on this.
|
| 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!
| matthewmueller wrote:
| >> 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!
| tompston wrote:
| 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
| matthewmueller wrote:
| Looks super cool. Starred @tompston!
| tompston wrote:
| Thanks!
| mavbo wrote:
| 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 then opting to CSR for subsequent
| navigation. I like the browser's built-in implementation of
| navigating between pages because it preserves things like
| mutations to the document and scroll position out of the box,
| with no additional JavaScript. If you collapse a comment in this
| thread, navigate back to the home page, then use your browser's
| back button, the comment you collapsed should still be collapsed.
| In my experience with SPA CSR, you'll need to track and restore
| the JavaScript state driving that collapse on your own (a
| combination of the window.history object and CSR hooks), since
| navigating back to the page is a full client side re-render of
| the page.
|
| I've found Svelte+React have good support for TypeScript,
| especially for guaranteeing the types of props passed to
| components, are there plans to support this? With controllers in
| Go and Views in Svelte/React, is there any way to help with
| correctness of data passed as props to the Svelte components?
| matthewmueller wrote:
| 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.
| matthewmueller wrote:
| I should add that lazy builds only happen in development. In
| production, it's all bundled at once.
| ammanley wrote:
| 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.
|
| EDIT: I could be wrong, please correct me if so.
|
| [1] https://github.com/rogchap/v8go
| matthewmueller wrote:
| Nice sleuthing! Bud heavily relies on
| https://github.com/rogchap/v8go
| c0balt wrote:
| Browsing the runtime/view/ssr source code it appears to use
| esbuild (over the VM?) for rendering the svelte views while
| injecting the relevant code etc.
| anthropodie wrote:
| Great work.
|
| The last bit about single binary is quite interesting. I could
| easily deploy app to my raspberry Pi without worrying about
| bundling things. I know Go can do this but it's nice that
| framework aligns with Go philosophy.
| matthewmueller wrote:
| Bud on a raspberry pi sounds like a fun weekend project! Let me
| know if you give it a shot!
| [deleted]
| ehaughee wrote:
| 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 using Go at work so definitely interested in using
| this for side-project web apps to keep me in the Go mindset.
| matthewmueller wrote:
| 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
| rnewton wrote:
| Your site's DNS is currently not resolving. Should provide
| alternate install instructions for cases like this.
|
| https://www.whatsmydns.net/#A/livebud.com
| matthewmueller wrote:
| Truth. Website coming soon! This post exploded way more than I
| expected. Can't complain!
| dmix wrote:
| > Build a Minimal Hacker News Clone in 15 Minutes with Bud
|
| I started my programming career after following the Rails how to
| make a blog in 15min youtube video. Always a good choice.
| matthewmueller wrote:
| 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 :)
| ValtteriL wrote:
| Interesting project, good luck with it!
|
| Can you elaborate how you were spoiled by Go and don't want to go
| back to writing PHP?
| matthewmueller wrote:
| 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 :)
| dimgl wrote:
| I 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.
| drewry wrote:
| In the video it says they are frontend agnostic and will be
| adding multiple frameworks soon. React was mentioned
| specifically as coming soon.
| theptip wrote:
| 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 that this is a fairly different solution; one of
| the author's explicit goals is that it should "Feel like
| using a modern JS framework". Personally I'd rather have it
| "feel like I'm using Django / Rails", except with most of the
| superpowers that were historically FE-framework-only.
| quickthrower2 wrote:
| 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 mental gear switch as you switch from
| front to back to front.
|
| The only small negative is you need to be careful what that
| first "server side" render produces and what it can access.
| But that is also part of the magic, as you can fine grain
| control the initial flash of content. For example include
| the layout/menus. Or include a cached view of a list that
| then updates on final render.
|
| It just feels so well integrated more than any other
| framework I have tried (like aspnet mvc or RoR for
| example).
|
| It will be hard to beat: If you want to beat it in Go you
| need at least a good Go->JS transpiler so you can use the
| same language. But even then anything other than
| JS/Typscript means I need a mental modal of what the
| transpiler is doing. I don't get a free pass on
| understanding JS or the DOM.
| matthewmueller wrote:
| 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.
| 0des wrote:
| I just want plain HTML and some of {{ .These }}
| quickthrower2 wrote:
| as well as sister comment, there is hugo, jekyll, etc.
| 0des wrote:
| fucking no. I want plain html.
| matthewmueller wrote:
| You wish _will be_ my command
| https://github.com/livebud/bud/discussions/8 :D
| 0des wrote:
| How realistic do you think it is that you'll be able to
| complete all the what-abouts everyone is proposing to you
| before you get burned out? Genuine question.
| fsociety999 wrote:
| > I think using Svelte was a mistake
|
| Why do you think that?
| matthewmueller wrote:
| 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
| realrocker wrote:
| 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 documentation
| right now but here are some examples:
| https://github.com/goliveview/examples.
| matthewmueller wrote:
| 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?
| realrocker wrote:
| Like you said in another thread, there are two choices here.
| I took the other choice because I wanted to: 1. not build a
| new templating language 2. not maintain a custom server side
| renderer(v8). 3. Keep javascript to the minimum 4. Build for
| developers who know Go and maybe a little html/css. 5. No
| special html attributes. It should be just standard
| html/template i.e easy to delete the websocket stuff if it
| doesn't work for you 6. Offer a view library instead of a
| framework. Go users are likely to be more open to adopting a
| library.
|
| The approach is similar to hotwire except I only use
| stimulusjs and not use turbojs. turbojs doesn't integrate
| well with html/template. In my approach, you can simply reuse
| the html templates you have already written with standard
| html/template package.
|
| Sorry for the rambling, I haven't gotten around to writing
| down all of it in a more structured way.
| jdauriemma wrote:
| If you ever ship an Airflow integration, consider this an
| official request to call it Air Bud.
| matthewmueller wrote:
| Ahahaha. I watched this movie 100 times as a kid. I cycled
| between Air Bud and Flubber.
| [deleted]
| jacktheturtle wrote:
| dude 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!
| matthewmueller wrote:
| 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.
| cjohansson wrote:
| I'm experimenting with something similar as well, I'm curious -
| how do you solve HTTPS support since it's a built-in web-server?
| grose wrote:
| Something like https://github.com/caddyserver/certmagic
| perhaps?
| matthewmueller wrote:
| 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
| mholt wrote:
| Yes, definitely use CertMagic. Let me know if you have any
| questions!
| matthewmueller wrote:
| 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!
| novoreorx wrote:
| Great project, which UIKit do you use? Is it Tailwind or
| something?
| matthewmueller wrote:
| 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
| ;)
| Abishek_Muthian wrote:
| Congratulations 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.
|
| [1] https://github.com/fragmenta
| matthewmueller wrote:
| 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!
| [deleted]
| tekkk wrote:
| Wow is this like Go version of SvelteKit? Except without SSR so
| it serves only static files? I just thought about the same thing
| recently and I'm glad somebody made it! IMO Go is better fit for
| server backend than Node.js, especially with I/O.
| matthewmueller wrote:
| 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!
| Scarbutt wrote:
| _" 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."_
|
| But then he created deno....
| titaniczero wrote:
| Yeah, I'm glad these projects are emerging. I love svelte but I
| am not entirely convinced about how they push you towards
| sveltekit, especially in the docs. (I know there are adapters
| that allow you to use another backend but everything in the
| docs and examples push you towards NodeJS and sveltekit). It is
| as if react docs were written in a way that pushes you towards
| NextJS (they're from different companies so this is not the
| case, but I still think it is a good analogy).
|
| I just don't want a NodeJS backend, all our team wants is to
| use a Golang backend which saves us ton of resources, which
| means less instances required, which means less $$$ (and Golang
| is awesome - performant, easy to read and write, easy to code
| concurrency, type safe without the hassle, built-in test
| suites/formatter/etc).
|
| I'd love something like Laravel but for Golang+Svelte.
| matthewmueller wrote:
| 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!
| winnipeg wrote:
| Great 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)
| matthewmueller wrote:
| I worried about this, but it seems like there's enough
| "framework supportors" in the comments!
| mav88 wrote:
| Looks awesome. livebud.com isn't resolving though so I can't
| install.
| matthewmueller wrote:
| Sorry about that - fixed the installation script in all the
| places!
|
| curl -sf curl
| https://raw.githubusercontent.com/livebud/bud/main/install.s...
| | sh
| lifeplusplus wrote:
| I thought of building my own framework then I remembered dealing
| with http headers, ssl, and http2
| matthewmueller wrote:
| That's the beauty of using Go. All of this stuff is provided by
| the standard libraries.
| throw_m239339 wrote:
| Nice, with generics, some things that were hard are easier to do
| when it comes to polymorphism thus code re-use.
|
| Go community has been pretty "anti-framework" (AKA "just use
| net/http" when it clearly doesn't solve every problems..., "don't
| put request scoped variables in context" when it's the very
| purpose of that interface...) and there was a lot of drama around
| some framework creators, unlike any other web language community
| I have seen by the way (remember Martini and the insane backlash?
| Iris and the constant drama, was that Iris, I don't even remember
| the name...) so it will be pretty interesting to see the
| reception for that framework.
|
| One advice to the author, congrats but don't call your framework
| "framework", it's like the go community hate that word, just say
| "a set of useful libraries to help web development", it seems
| like euphemisms are easier to swallow for some...
| matthewmueller wrote:
| 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.
| emehrkay wrote:
| The install link doesnt work. I wanted to view what it did before
| I ran it `livebud.com/install`
| matthewmueller wrote:
| Sorry about that, fixed the installation script in all the
| places:
|
| curl -sf curl
| https://raw.githubusercontent.com/livebud/bud/main/install.s...
| | sh
| pphysch wrote:
| 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
| `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.
| minism wrote:
| 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).
| pphysch wrote:
| That's fine, but you are making a trade off with productivity
| here.
| minism wrote:
| You have to be careful because sometimes productivity is
| just an illusion caused by accruing technical debt that you
| have to then pay for in time later. With database
| abstractions you often pay back this debt once the app
| reaches even slight complexity and you need to spend a lot
| of time understanding, debugging and refactoring query
| flows.
| matthewmueller wrote:
| 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.
| pphysch wrote:
| > 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.
|
| Ultimately you will be teaching the framework, not the
| language, when it comes to large frameworks like this. Both
| Go and Python are easy to learn, but frameworks always add a
| lot of complexity.
|
| > 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:
|
| I'm not arguing for this or that architecture cargo cult. I
| prefer monoliths too, but sometimes you really need
| distributed microservices and Go+gRPC is one of the most
| maintainable ways to do that.
| matthewmueller wrote:
| Agree with you on both accounts!
| dougbarrett wrote:
| This is really cool! I tried building something more basic than
| this a few years back, but this looks a lot more mature. I'll
| definitely be following and testing it out on a few small
| projects.
| matthewmueller wrote:
| 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.
| reddec wrote:
| First of all - great work, thanks. Will follow the progress.
|
| I have been working with Go professionally since 2015 and quite
| often it makes me feel frustrated due to lack of full-stack web
| frameworks.
|
| I was thinking to do something like your project, but with focus
| to full SSR/zero-js. Lucky me, you started it first . Maybe be in
| some things I will prefer different approach, however, your
| project already released (and it's excellent) while mine only in
| prototype. 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 relative 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...)
| dgb23 wrote:
| This is a very ambitious project and from the looks of it, it
| makes a ton of good decisions.
| matthewmueller wrote:
| Thanks for the kind words @dgb23!
| mstef9 wrote:
| 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://htmx.org
| matthewmueller wrote:
| 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.
| throwamon wrote:
| 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.)
| matthewmueller wrote:
| 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)
| chabad360 wrote:
| There is https://github.com/jfyne/live which is probably what
| you're looking for.
| matthewmueller wrote:
| Starred!
| sunfmin wrote:
| People interested in this might also find my project interesting:
| https://docs.goplaid.dev, https://github.com/goplaid/
| matthewmueller wrote:
| 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!
| onionisafruit wrote:
| Congratulations on shipping. The demo looks great.
|
| I see views and controllers in the documentation, but the only
| mention of model is that "model" is a reserved directory. What
| are your plans for models and persistence?
| matthewmueller wrote:
| 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?
| onionisafruit wrote:
| Your design goals look good to me. I think this will be one
| of the hardest parts to get right, so it's probably wise to
| save it for later so you can learn from implementing the rest
| of your design first.
___________________________________________________________________
(page generated 2022-05-14 23:02 UTC)