Why I Added Astro to My Stack (And Why It Challenged Everything I Thought I Knew)
Exploring how Astro challenged my approach to web development and led me to build a more intentional, specialized tech stack with TanStack Start for apps and Astro for content.
I had it all figured out.
TanStack Start for web apps. Hono.js for microservices. A clean, isomorphic stack that handled everything I needed as a freelancer. When I expanded into design-centric static sites, I assumed I'd just keep using what I knew. After all, TanStack Start can do static generation, right? The ecosystem is there. The patterns are familiar.
Then I had a conversation that stopped me cold.
The Friction I'd Been Ignoring
Someone asked me about my blog.
Not the content—the experience of building it. And I realized: my blog worked, but it was a workaround. I had taken a framework designed for complex, interactive web apps and bent it toward something it wasn't optimized for. Markdown felt bolted on. Content felt like an afterthought. Every blog post required me to think like an app developer, not a writer.
I was so comfortable with my tools that I'd stopped asking whether they were the right tools.
The Question That Changed Everything
"What if the framework itself was designed for content first?"
Enter Astro.
I'll be honest: my first reaction was resistance. I knew TanStack Start. I was productive in it. Learning something new felt like backtracking.
But then I looked at what Astro actually does:
- Zero JavaScript by default — Your content ships as HTML, not as a React bundle waiting to hydrate
- Markdown as a first-class citizen — Drop files in a folder, get blog posts. That's it..md
- Content Collections — Type-safe, organized content without building a CMS layer
- Islands architecture — React where you need it, static HTML everywhere else
And the killer realization: I could bring my React components with me. Astro + React meant I didn't abandon my skills—I just used them where they actually added value.
Framework Comparison: App-Oriented vs Content-Oriented
| Aspect | TanStack Start (My Old Approach) | Astro (My New Perspective) |
|---|---|---|
| Default output | SSR with hydration | Static HTML, zero JS |
| Blog setup | Manual routes, API endpoints | Drop .md files in folder |
| Content workflow | Build your own CMS layer | Built-in Content Collections |
| Markdown handling | Requires libraries/plugins | First-class citizen |
| JavaScript shipped | React bundle by default | Only where explicitly added |
| Mental model | App-first | Content-first |
The Perspective Shift
This wasn't about replacing TanStack Start. It was about recognizing that different problems need different tools.
| Project Type | Tool | Why |
|---|---|---|
| Hybrid apps, dashboards, complex state | TanStack Start | Isomorphic React, full ecosystem |
| Content sites, portfolios, marketing pages | Astro | Content-first, performance by default |
| Microservices, APIs | Hono.js | Lightweight, edge-ready |
I wasn't losing anything. I was gaining intentionality.
What This Means for My Freelancing
| Client Need | My Approach |
|---|---|
| "We need a blazing fast portfolio" | Astro + React islands |
| "We need a customer portal with dashboard" | TanStack Start |
| "We need APIs for our mobile app" | Hono.js microservices |
| "We have a marketing site + member area" | Astro for marketing, TanStack for member area, Hono connecting them |
What I Wish I'd Known Sooner
Your tools should disappear so your content can shine.
When I write a blog post now, I don't want to think about API routes, data fetching, or loading states. I want to think about what I'm saying. That's what Astro gives me—the freedom to focus on content when content is the point.
And when I build a dashboard or a customer portal, I still reach for TanStack Start. It's unmatched for complex interactivity. The key is knowing the difference.
The New Stack
So here's where I've landed:
- TanStack Start — For web apps and hybrid projects
- Astro — For content-driven sites
- Hono.js — For microservices and APIs
Three tools. Each optimized for what it does best. No more square pegs in round holes.
Common Objections Addressed
"But isn't learning another framework complicated?"
The initial learning curve takes about a weekend, but it's a one-time investment. And because Astro lets you bring your React components, you're not starting from zero—you're just placing your existing skills more strategically.
"Can I really use both in client work?"
Absolutely. Many clients have both content needs (marketing site) and app needs (customer portal). Having both tools means you can deliver exactly what each part of the project requires, without compromise.
"What about maintenance overhead?"
Two focused tools are often easier to maintain than one tool stretched to do everything. When you reach for Astro, you're reaching for a tool that wants to do content. When you reach for TanStack Start, you're reaching for a tool that wants to do apps. No more fighting framework defaults.
Getting Started with Astro
If you're a React developer considering Astro:
- Start small — Build one blog post page or a simple portfolio section
- Bring your components — Drop existing React components into Astro with client:load
- Embrace markdown — Write your next blog post in markdown and see how it feels
- Compare the experience — Notice where friction disappears
Lessons Learned
- Friction is signal — If something feels like a workaround, it probably is
- Tools shape thinking — The framework you choose influences how you solve problems
- Specialization wins — Use tools designed for your actual use case
- Skills transfer — Learning Astro doesn't mean abandoning React
- Right tool, right job — The best stack is the one that fits the project
Conclusion
I didn't abandon TanStack Start. I added Astro to my toolkit. And in doing so, I gained clarity about when to use each one.
The $0 cost of adding Astro to my stack isn't just about money—it's about opening up a new category of projects I can confidently take on. Design-centric sites that once felt like bending tools now feel like exactly what the framework was built for.
If you're building everything with one framework, ask yourself: Is it serving your content, or is your content serving the framework?
The answer might surprise you.