A ton of people say that Go's standard library is really powerful and usually enough to get by without external dependencies. I think that's true for companies that have the resources to build and maintain packages to reduce code duplication. For everyone else, we're left to finding the right set of packages to build our projects. So, I built Copper - a toolkit that helps you get your project off the ground with minimal dependencies. It covers everything from routing, html, storage to tooling and more.
Check it out, star it, and feel free to ask questions!
P.S. I also have a video demo building an HN clone in the docs
The way I use the standard library is like a super condensed version of React. Templates are my components. Since templates can be nested, templates can be used to build "components" and those components can be stored in separate files and compiled together at run time with a "model" being fed to the template(s) via a state object passed by the application.
So I may have a few dozen template files in a folder called /components, and another folder called /pages with a few templates that use these components. When a user visits a "page", the template file is "compiled" with the appropriate components.
A page might look like this:
<html>
{{template "nav"}}
{{template "thread" .Thread}}
{{template "footer"}}
</html>
I want to do a write-up on it but I'm not sure if it's a novel idea.
But the tldr is - you'll need a lot more than just templating for a production ready app. To name a few things - server, storage, migrations, logging, configs. IMO there's a huge benefit in having a batteries included toolkit that stays close to the stdlib - so you can totally keep your templates as is!
Can you elaborate? Like give me an example of a route path that uses placeholder values? I use Go to build web apps too and I really don't see a need for anything other than the standard library.
What he copy/pasted already exists, only better.
The HN audience doesn't seem very sophisticaed. Hell even reddit's /r/golang is better informed than HN in this regard. Just read through all the issues people have with gorm and if you've ever did any real Go development you would not pick gorm as the default database package in the first place.
Amateurs all of you, I'm seriously sick of your unprofessional lack of knowledge and experience.
HackerNews my ass, more like NoobNews. GTFO
There is no Rails equivalent in JS, theres lots of competitors that feel years away like SailsJS, the new Deno Fresh one etc, Adonisjs... Is NextJS/SvelteKit/RemixRun considered also? I don't even know if they have a standardised background job processor in JS land.
Java's solutions are dreadful imo for if you want to compare to Rails. Quarkus/SpringBoot/Micronaut are nowhere near productivity levels for a fullstack app. They lean heavily on the API only side of things. (I do like Java oddly enough)
PHP is the main competitor to Rails oddly enough, Laravel seems brilliant.
Go is just starting up in this space it looks like, Bud is another attempt at Rails in another language https://github.com/livebud/bud. However the Go ecosystem is heavily API only side of things instead of SSR. Go's templating libs suck imo.
Elixir of course has Phoneix which is apparently great, purely functional langs unfortunately dont fit my head and feel to abstract for myself (don't hate me)
Its no wonder we have the backend / frontend developer split nowadays.
Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on.
Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on.
In my 8 years of writing Go, I would liken it the most to C, where you had to spell everything out, except without the manual memory management and the macro preprocessor.
Doing magic with Go via reflection or other implicit behaviours is generally annoying to deal with. One example is some libraries using struct tags, most of the time they work as expected, but sometimes you get some weird failure and these kinds of implicit behaviours are the culprit.
Overall, I don't rate these "all in one" frameworks highly in Go. The standard library is excellent for most applications, you only need to add some code to remove some boilerplate. For most apps that I have worked on in Go that involved web components, we maybe had to import e.g a websockets library or a more elegant routing library, but that's pretty much it.
Generics help a little bit, but the fact remains that error checking is pervasive and verbose, and you can't chain calls (e.g. slice.Map(func(a int) { return a * 2 }).Filter(func (a int) { return a % 2 == 0}).Reduce(0, func(a int, i int) { return a + i }) is not something that can be supported by golang when errors are involved, not to mention the extreme verbosity since it does not have a short way to pass functions).
I'm hoping to add something like Phoenix to Copper. It should help with the "heavily API only side" problem. I've already added integrations for Tailwind and added some utilities on top of the templating (going to add more) to fix the lack of good templating.
My take is that Remix + Next.js + SvelteKit are going to continue to innovate fast in the Frontend and "Backend for Frontend" space. Rails and Laravel don't hold a candle to the experience you get in that ecosystem.
But the JS ecosystem is massive and, as a result, fragmented. As you mentioned, there's no consensus on ORMs, mailers, queues, etc.
I don't see those frameworks trying to push too far in that direction, they'll remain "UI focused". This is nice for their focus, but not great for someone who wants to launch a web app and doesn't want to figure out all the surrounding ecosystem tooling.
This is where Laravel, Rails (and soon Bud) (and I assume Copper) will shine. They provide more tools and interfaces out of the box for building full-featured backends. These frameworks definitely need to keep an eye on the best ideas coming out of the JS framework ecosystem though!
> One Binary
> Build frontend apps along with your backend and ship everything in a single binary.
I'm doing something similar and love it. Do you embed the entire `public` directory and then traverse the embed.FS to access the files in memory?
I've done this in Rust before, I'm sharing it here as I'm assuming that Go has something similar.
I'm basically hard-coding the paths in the backend to also serve static assets, and embed the bytes of the asset at compile time, so when it runs, it's just serving it straight from memory. Here how it looks for style.css for example: https://codeberg.org/ditzes/ditzes/src/branch/master/src-tau...
It'd be trivial to move the structure to something like a map instead, where the URL is the key and another map where bytes, headers and such is stored. Mostly I didn't, because I'm just embedding few amount of files.
Here are the embed statements [3]. One thing to note is that embed.FS does not send 304 Not Modified status back, which is why I made a CachingEmbedFS [4].
[0] https://github.com/binwiederhier/ntfy/blob/main/Makefile#L77
[3] https://github.com/binwiederhier/ntfy/blob/main/server/serve...
[4] https://github.com/binwiederhier/ntfy/blob/main/util/embedfs...
I am using svelte for the frontend and that was biting me.
Gotta put Go on my list of things to learn
As for database, jet is my favourite thus far.
but it could be decent choice if u want to build integrated framework i can understand why people would choose it, another option is code_generation_meta_hell with sqlboiler. upper db [0] would have been perfect fit for this kind of project but is not that famous, its development is slow but stable.
ps: i like sqlboiler what i am saying is if u are building framework top on it then not that fun
[0]: https://github.com/upper/db
edit: include link
My goal with Copper is to provide out-of-the-box integrations with popular solutions to various problems. For now, I picked GORM but I definitely see adding support for other tools.