Published by matthewmueller over 2 years ago
This release wraps up the v0.1 milestone 🎉
I'm completely overwhelmed by all the love. As I write this, we're still on the front page of Hacker News (13 hours in!):
And we're at the top of the Go subreddit.
Published by matthewmueller over 2 years ago
bud create .
bud create
for the development binary when outside the source tree.bud new controller
from route:resource (e.g. /:stories
) to resource:route (e.g. stories:/
) to avoid confusion with URL params.Published by matthewmueller over 2 years ago
bud version [key]
to make it easier to script getting the version of bud.Published by matthewmueller over 2 years ago
Download go modules after scaffolding
Hopefully fully fixing bud create <dir>
this time. Bud now downloads the runtime modules upon create.
Add some getting started instructions
I've written up a bit of documentation on how to get started. There's a lot more to come here!
Published by matthewmueller over 2 years ago
Fixed bud create
Now that bud is public and has versions, I did another pass over bud create <dir>
to get it working as expected
Add live reload to the welcome page
In an effort to vanguish all page refreshes, needing to refresh the welcome page stuck out like a thorn. This release clips that thorn.
Published by matthewmueller over 2 years ago
Next attempt at fixing bud run
after installing from Github
It turns out .go files are also required by the runtime. I've unignored them, but will think of better ways to handle this in the future.
Published by matthewmueller over 2 years ago
Fix bud run
after installing from Github
When you build the binaries with --trimpath, it removes the import paths stored within the binary. This is preferable because you don't want to see my filepaths within the binary, but it also means that the downloaded binary was no longer able to find where the standard library packages were located. I fixed this by calling go env
on boot. This adds about 7ms overhead on boot, so I'd like to find a way to do this without spawning, but we'll leave that as an exercise for the reader :)
Another problem we encountered was that the runtime was missing some of the necessary embedded assets. I've removed them from .gitignore to fix the problem. Longer-term I think it makes sense to use bindata for this case to turn them into Go files that can be ignored in development but are built into the binary for production.
Add back missing node_modules
I overpruned the dependencies and that was causing failures in CI. I added them back in.
Published by matthewmueller over 2 years ago
Bud is finally open source on Github!
I'm thrilled to finally share my side project with everyone! I first started working on this while in lockdown in Berlin on April 20th, 2019. A co-worker suggested I have a look at the Laracast videos about Laravel. I was just blown away by how productive you can be in Laravel.
As a former solo developer, I place a lot of weight on having all the tools you need to build, launch and iterate on ideas as quickly as possible. Laravel provides a comprehensive and cohesive toolset for getting your ideas out there quickly.
With Go being my preferred language of choice these days and a natural fit for building web backends, I started prototyping what a Laravel-like MVC framework would look like in Go.
At this point, I just had the following goal for Bud:
I got the first version working about 6 months in and I 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 been spoiled by the renaissance in frontend frameworks with Next.js. What I love Next is that it starts out barebones and every file you add incrementally enhances your web application. This keeps the complexity under control.
With these newly discovered constraints, I started working on the next iteration of Bud.
With these new goals, the Bud you see today started to take shape. But along the way, I discovered a few more project goals:
And this is the Bud you see before you. I have big plans for the framework and I sincerely hope you'll join me on this journey.
The tests are slower than they should be. What was curious was that they didn't seem to be doing much during a lot of the test run.
I dug into why and it turns out the test caching itself can be extremely slow. See this issue for more details: https://github.com/golang/go/issues/26562. It's slated to be fixed in Go 1.19, so I'm going to hold off on a fix for that.
Additionally, the tests weren't ever being cached. If you'd like to read about the whole debugging saga that took a day to figure out, head over to this issue: https://github.com/golang/go/issues/26562. I've remedied this issue, but it's something to keep an eye on.
I'm in the process of setting up curl -sf https://github.com/livebud/bud/install.sh | sh
. In doing that, I'm ironing out the publishing pipeline and install script.
Published by matthewmueller over 2 years ago