Live data from Hacker News

Goravel: A Go framework inspired by Laravel

goravel.dev

51–60 of 170 posts

Re: Goravel: A Go framework inspired by Laravel

#51

Earlier quoted context omitted.

Not sure there's a Go equivalent of Laravel, so not sure which tooling you suggest people adopt. If I want an all inclusive MVC (or similar) web development framework with all batteries included - why not build a Go Laravel? Python has Django Java has Spring (among others) C# has asp.net Ruby has Rails PHP has Laravel What does Go have?

> If I want an all inclusive MVC (or similar) web development framework with all batteries included I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just…

> It's quite easy to do most things you would want by just writing some code

OK, I want a similar thing to ActiveRecord - with all the features, is that quite simple to build?

Now you'll tell me I probably don't want an ORM at all. But lets say I do, lets say many people find value in these things.

Re: Goravel: A Go framework inspired by Laravel

#53
post #24

Earlier quoted context omitted.

What would you use if ORM is to be avoided? Perhaps something like https://github.com/sqlc-dev/sqlc ?

My advice is to just use standard library `database/sql`. Every abstraction on top adds extra complexity and isn't really necessary. Just execute a query, map the results, and there you go.

"Every abstraction on top adds extra complexity and isn't really necessary"

This. In my experience, every project that has non-trivial query requirements starts out as "this ORM is nice, it takes away 90% of my work" and ends with "how do I get rid of that leaky abstraction layer that constantly makes my life harder."

Re: Goravel: A Go framework inspired by Laravel

#54

Earlier quoted context omitted.

> If I want an all inclusive MVC (or similar) web development framework with all batteries included I think that maybe you shouldn't want that. Go is a simple language with a very extensive standard library. It's quite easy to do most things you would want by just writing some code, leveraging the standard library, and maybe including a handful of external libraries. Frameworks are not needed and will eventually just…

> It's quite easy to do most things you would want by just writing some code OK, I want a similar thing to ActiveRecord - with all the features, is that quite simple to build? Now you'll tell me I probably don't want an ORM at all. But lets say I do, lets say many people find value in these things.

I personally believe ActiveRecord is a gigantic anti-pattern and should be avoided at all costs (by anyone, ever). And I also happen to have had very bad experiences with ORM and feel like most of the time they are not needed at all. So yes. But even if you want an ORM, there's a few popular ORM libraries. You can just include one and start using it, no need to use a framework for that (for ActiveRecord I wouldn't know).

Re: Goravel: A Go framework inspired by Laravel

#56

Earlier quoted context omitted.

Batteries included very opinionated way of building amazing things. That said you can choose to go your completely own way and ignore the Laravel way. But good luck with hiring. I think Laravel is the best framework for getting an idea going, to MVP to MMP to scale. It just works. Purists hate it because it is PHP and they still think it is 1999. They also hate that there is the “Laravel way”, even though you can com…

Laravel seems to get a lot of hate from within the PHP community as well. I suppose every framework in use has its detractors.

Who, the one guy pledging Trongate, or the people in the Symfony camp?

I assure you React gets plenty of hate from the JavaScript community - enough to spawn over a dozen competitors. At some point, community love/hate is irrelevant.

Re: Goravel: A Go framework inspired by Laravel

#57
post #36

Earlier quoted context omitted.

In my experience building the site with Go (Echo) with Postgres and a vanilla frontend from scratch, I realised that maintaining my codebase as a solo developer for a medium-sized platform was challenging. At one point, it became unmaintainable, and I had to rewrite it three times. The third time? I switched to the Astro web framework, and it solved all my problems. Go is indeed easy to get started with, but it's dif…

Can you go into a bit more detail about what became challenging and what Astro helped you solve?

At first, my goal was to go pure with vanilla JavaScript and CSS, hand-coding Echo routing, authentication, secure cookies, etc., using Go libraries—and I did just that. But as a solo developer managing both backend (Go + SQLC) and frontend (vanilla JS + CSS), it became overwhelming. My co-founders had no concrete feature roadmap, throwing in whatever they thought was good, and our UI/UX designer was stuck with a buggy Marvelous app. Managing both sides while constantly adapting to shifting requirements became exhausting.

To ease the burden, I introduced Alpine.js, which helped, but the real challenge was juggling Go and TypeScript for different parts of the stack. When the team decided to revamp the site with a new Figma design, I switched to Astro after the release of Astro 2.0—it simplified frontend development and allowed me to gradually move away from Go. This wasn’t just about adopting a new language with old patterns; it was about making my workload sustainable while improving maintainability.

A month later (after three years), bad news—they ran out of funding and had no time for marketing. On top of that, I have vision problems (genetic and post-cataract surgery), making job options limited. But one thing I’ve gained from this experience is a strong grasp of frontend performance optimisation—JavaScript, Tailwind CSS, HTML, and responsive images. There are millions of poorly optimised websites that Astro could improve. At least in Singapore, where we have great internet connectivity, I can keep refining my skills.

Astro solved:

- Same codebase: Both frontend and backend with TypeScript, meaning I no longer have to write routers whenever we add a new category.

- Optimisations: Reducing JavaScript and loading JavaScript as a module for better security.

- Maintainability: Go HTML templating was harder to maintain; I prefer Astro’s JSX-like syntax.

- Performance: If I need performance, Bun can be as performant as Go, which is a bonus.

- Reusability: Lots of UI and Astro components can be reuse.

- Productive (Future): I’m waiting for Vite (Rolldown) to speed up my build times. Evan You has lots of ideas for Rolldown plugins.

- Community: Of course, an active community that is improving Astro so we don’t have to reinvent the wheel, with lots of sensible features by default, including Starlight for docs. I proposed to the Echo maintainer to adopt it over Docusaurus, but I was turned down.

Re: Goravel: A Go framework inspired by Laravel

#60
post #21
post #20

I'm not a fan of the complexity added by this and other similar frameworks. PHP and Go are very different languages, so trying to replicate the same concepts for one language to another I don't think it is a good idea. One of the things I would discard would be the use of an ORM library : every library adds another level of complexity and doesn't allow to see what is happening when the SQL statements are built. In my…

> One of the things I would discard would be the use of an ORM library ... In my opinion, it is better to create some simple methods for each object that implement the CRUD operations and build the SQL statements directly. Have you done this for any complex system? I'd love to see you do this for the AzerothCore: it has 298 tables, 3,010,875 rows across those tables, and one table (quest_template) has 105 columns. In…

Writing SQL against systems much larger than that used to be the norm.

You are correct that "using the right tool at the right time" is important, and often, that right tool is SQL. Other times it's not. Unfortunately there are many developers who don't really know SQL, so every problem is ORM-shaped.

Post reply on HN