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 different when dealing with server-side rendering and not a single-page application where Go is a backend.
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.
The frontend is always going to be a pain since you have to deal with JS in some form, and a culture of ever increasing complexity until people give up and rewrite everything and throw away years of work.
When you have Go, I don't see how switching to JS/TS comes with any benefit on the backend.
At some point I would have liked to meet people who struggle using Go on the backend and learn what their process is and how they structure things. I've written quite a few backend systems in Go for a variety of domains (anything from PKI systems to industrial automation and various real-time streaming systems). Surely people who struggle must either do something that is very different from what I do, or be sensitive to entirely different issues than I am.
Your original message was "Inert should be used instead of overflow" which is incorrect because `inert` doesn't affect scrolling of the viewport. Your CSS rule example is a good way to demonstrate using the presence of an `inert` attribute on the body to determine when `overflow: hidden` should be applied to the body.
That section of the MDN article is somewhat confusing but if the dialog is opened using the `.showModal()` method, there's no need to add an `inert` attribute yourself, the browser automatically makes the rest of the page inert.
If a <dialog> that's meant to be modal is opened not using `.showModal()`, say by making it a `popover` and the `popovertarget` of a button, then you might set `inert` yourself (and remove it when the <dialog> is closed). However, you can't simply do <body inert> if that <dialog> is inside the <body> because then the dialog itself would be inert.
You're going to encounter various limitations with the CMS that it was designed for. I'll say this once: if we need a complete rebuild in 2025 and beyond, the Astro web framework could be the core engine due to its unopinionated nature and support for many UI components, including the latest addition, VanJS. It's seem like a well designed to keep things as simple as possible and still open to community feedback.
Of course, you could host it on Netlify, Cloudflare, and Vercel using adapters from Astro. Although it's not a traditional CMS, it's capable of serving as the core engine that should serve well for 99% of use cases out there.
Unfortunately their signature dirt cheap bandwidth isn't so cheap in Singapore, you only get 1TB inclusive instead of 20TB and the overage rates are 7.4x higher than their EU and NA datacenters.
That's a problem but still cheaper than UpCloud. I do find Cloudflare pricing is more attractive for read heavy website and startup plan is useful for us.
