GoFastr: The Framework Nobody Asked For

This is the first article about GoFastr, a full-stack Go framework I have been building. This one is all about the why — the motivation and the thinking behind it.

In the wake of AI-assisted development, I found myself working on multiple projects at the same time, and that turned out to have a very real device cost that - coming from working on 1 project at a time - I had not anticipated. This became painfully clear when trying to run three Node servers at once — say three worktrees for three different features I was working on simultaneously — and then run some Playwright tests on top of that. A normal machine just gets completely bogged up in its memory. And on top of that, every single project starts getting either a symlinked-ish or a straight copy of node_modules, which is not optimal and eats a ton of physical storage. Now try to do this with a machine that has a hard-drive instead of an SSD ... ☠️.

That is the part I did not expect. The ability to work with AI in parallel now has a hardware constraint attached to it. That was one of the biggest motivations that got me to start looking into something other than Node.

During the investigation I looked into Rust, I looked into C#, and I looked into Go — which is the one I decided to go with. A few reasons:

• The syntax is very similar to TypeScript. Coming from years of TypeScript, it makes it feel not too foreign.
• The output is lean. Roughly 15 to 50 megabytes for the small kind of side projects I normally work on.
• There is a shared local machine registry cache — you do not need to re-download or rebuild a bunch of the same packages every time across different projects. Which, in the case of working with AI across a bunch of worktrees, matters a lot.
• The idle compute is tiny. A Go binary sits around ~50 MB on a dev server, compared to 300 MB up to multiple gigabytes in Node.
• Lower disk usage than Rust. Rust for some reason wants to generate a bunch of artifacts and they occupy a ton of disk. That is something I did not want to deal with nor had the drive space for (why did I buy a machine with 512 GB...).
• C# just felt convoluted in general.
• Go cross-compiles Windows, Mac, Linux, and Wasm out of the box for the most part — as long as you stay within the standard library. That last one I really really love!.

After I settled on Go, I went looking and there was not a lot out there that did exactly what I wanted. I wanted an experience similar to server-side render and hydration — like Angular, kind of like React, but honestly more like Astro. The fast frameworks that hydrate the UI. Nothing really felt like it had that experience, so I just decided to build it from scratch.

And the other reason — the one that made it actually feasible — is that I had AI to assist me. I was not really stopped by the normal time-and-difficulty constraints, because AI could pick up all the slack, all the actual scaffolding and writing the code itself, while I directed the direction of the product.

There was maybe a lot of "Well if I'm already gonna build do something in a language I don't know and have AI to assist me then why not just build it from scratch" kind of thought. So I did. And it was fun. I learned a lot, and I am still learning a lot.

Disclaimer: a lot of GoFastr's code was generated or heavily assisted by AI. I steered, it typed. This is intentional.

Now this is where it got fun, because I was able to make GoFastr AI-native based on new capabilities and trends on purpose:

• It generates MCP routes and LLM.md files.
• And the one I really like — it lets you introspect the dev server via an MCP server. So something like Claude Code or Codex can check exactly how the server is behaving while it is live. It can query the database, hit the updated database, all just naturally by interacting with the introspecting server. I find that very, very useful, and I much prefer that experience.

• The Go Reddit community was not very welcoming. It even prevented me from posting on the subreddit, which is kind of sad and annoying — but you know, to each his own.
• Not even your friends are going to use your framework. This one I learned the funny, weird, and sad way at the same time. It is a whole framework, and there is the running joke about a new framework popping up every other week, especially in the JavaScript ecosystem. So yeah, that part is a little disheartening.
• You will find out how much you don't know. Building this has been a humbling way to explore how much I know and how much I don't know about web development. I brought a lot of ideas from Node and client-side apps into the server, and that surfaced both my strong areas and my knowledge gaps pretty quickly.

Now, should you go build your own framework in a language you just picked up? I will leave that up to you (but probably yes, and stop reading here build your own then leave me a comment with it - if you are reading on medium, my site does not have comments).

Here is the thing — despite all of that, I have already built a couple of projects with it and I find the experience quite amazing. I am actually very satisfied, and I hit a lot of the things I originally wanted.

The hosting win is the one that keeps surprising me. I host a lot of my projects on VPSs, and a single Node project — especially the Next.js ones — can idle at around 500 MB of RAM. GoFastr idles at about 50 MB. So it becomes very possible to say: you have a DigitalOcean $5 droplet, you will be able to host ten projects on it and not even sweat too much about it, because it just works out of the box and fits within the deploy pipeline.

And the deploy is almost silly how easy it is. Because of the cross-compilation, I do not even bother compiling in a pipeline:

I am compiling from a Mac into Linux and it is a non-issue. I literally just drop my binaries into my VPS and do not even worry about compiling it in the pipeline, because it is so easy to just do it on my machine. Super cool, super useful.

Food for Thought: the more I lean on AI to run projects in parallel, the more the bottleneck moves off my editor and onto my machine and my servers. Node was never designed with ten-idle-projects-per-droplet in mind. Maybe the "AI-native" part of a framework is not just MCP routes — maybe it is being cheap enough to idle that you can afford to have a lot of things running at once.

Wow, you made it to the end of a post that was mostly me explaining why I built a thing nobody asked for. Thank you for that.

If you want to poke at it, GoFastr lives at DonaldMurillo/gofastr, and it is on pkg.go.dev too. It is still experimental — ride it at your own risk. One of the first real things I shipped with it is a barcode generator, if you want to see it doing actual work.

Have you ever hit the wall where AI made you productive enough that your hardware became the constraint? Have you built your own framework and watched even your friends refuse to touch it? I would love to hear it — don't hesitate to leave me some comments and feedback here or on the repo.

Happy Coding!

PS: yes, it is really spelled GoFastr, not "Go Faster." My voice-notes app has heard me say it a hundred times and still refuses to believe me.

PS2: If you are interested in the name, that is a story for another day.