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.
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.
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.
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.
I spent the entire time building a business network platform with Astro instead of WordPress or other web frameworks because it is exactly what I need to easily manage UI components and provide a safer JSX-like environment.
In comparison to Ruby on Rails, Django, and Laravel, Astro stands on the same level but much less learning curve.
Those shared on Twitter when they deployed React app and assuming I came across one of the popular site that always prompt a notification (https://www.carousell.sg) to reload the page whenever there is a new update.
still think that your users will encounter broken links when you re-deploy a new build to production, which is common in SPAs. Have YNS solved this issue?
It's fast because your demo prefetches the listings when the mouse cursor hovers or taps, which is possible with traditional e-commerce, I dislike that kind of UX that are wasting user data usage. Is there an option to disable prefetching?