Why I'm Thinking of Switching My Portfolio to Astro.js
Lately I have been spending most of my time building auditing dashboards. Working on data-highly interactive applications changes the way you think. After a while my default workflow became simple: create a new React + Vite project. Start coding.
It's a stack for building web applications.
When I looked at my personal portfolio and blog I stopped and asked myself:
Why am I using the setup for a website that is mostly static ?
A portfolio is not a dashboard. It does not manage state, update data in real time or require every component to become interactive the moment the page loads.
Yet with my React setup the browser still has to download and execute JavaScript for the entire application before everything becomes interactive.
While browsing through developer blogs and discussions I kept seeing one framework mentioned again and again: Astro.
The more I read about it the it seemed designed for exactly this type of website.
The Problem with Hydrating Everything
A typical React application works by hydrating the page.
For example a React application starts like this:
import ReactDOM from "dom/client";
import App from "./App";
ReactDOM.createRoot(document.getElementById("root")).render(
<App />
);
Everything inside <App /> eventually becomes part of one large JavaScript application.
Before users can fully interact with the page the browser needs to:
Download the JavaScript
Parse it
Execute it
Hydrate the UI
For applications like dashboards admin panels or collaborative tools this trade-off is completely reasonable.
For a portfolio?
Most visitors just want to:
Read about you
View your projects
Open your GitHub
Read your blog
Hydrating the page feels unnecessary.
I mean think about it. My portfolio does not need to be interactive all the time.
Astro Takes an Approach
Astro follows a different philosophy.
Of assuming everything needs JavaScript it assumes nothing does.
A simple Astro page looks like this:
---
const title = "My Portfolio";
---
<html lang="en">
<head>
<title>{title}</title>
</head>
<body>
<h1>Hello I'm Kavin</h1>
<p>Welcome to my portfolio.</p>
</body>
</html>
When you build the project:
npm run build
Astro outputs HTML.
That means visitors immediately receive content without waiting for a JavaScript bundle.
I like that.
Islands Architecture
One of Astros interesting ideas is Islands Architecture.
Of making the whole page interactive Astro only hydrates the components that actually need JavaScript.
For example:
---
import ThemeToggle from "../components/ThemeToggle.jsx";
import ProjectCarousel from "../components/ProjectCarousel.jsx";
---
<h1>My Portfolio</h1>
<ThemeToggle client:load />
<ProjectCarousel client:visible />
Here the page itself remains static.
Only the components that need interactivity receive JavaScript.
That's really cool.
Client Directives
Astro gives you control over when a component should become interactive.
client:load
<ThemeToggle client:load />
What it does
Downloads JavaScript immediately
Hydrates soon as the page loads
Best for
Theme toggles
Navigation menus
Search boxes
buttons
I can see why this is useful.
`client:
`astro
`
What it does
Waits until the component appears on the screen
Downloads JavaScript only when needed
Imagine your portfolio contains an interactive project carousel near the bottom of the page.
If a visitor never scrolls far Astro never downloads its JavaScript.
That's bandwidth saved without writing any optimization code.
Why This Matters
of sending JavaScript for everything upfront Astro sends JavaScript only where its actually needed.
That means:
Smaller JavaScript bundles
Faster page loads
Lower memory usage
Better Core Web Vitals
Less work for the browser
For content- websites this approach makes a lot of sense.
I think it's a fit for my portfolio.
SEO Benefits
Another thing I like is how Astro handles SEO.
Since pages are rendered as HTML by default search engines can immediately read:
Page title
Meta description
Headings
Content
links
They don't have to wait for a large JavaScript application to finish executing before indexing the page.
For blogs and portfolios that's an advantage.
Where Astro Makes the Sense
After reading more about Astro I realized it fits perfectly for websites where content's the main focus.
Some examples include:
Developer portfolios
Personal blogs
Documentation websites
Company landing pages
Marketing websites
E-commerce storefronts where fast loading improves user experience
That does not mean React is obsolete.
If I'm building another auditing dashboard with forms, charts, filters and live updates I'd still reach for React without hesitation.
The tool simply matches the problem.
I like that.
Final Thoughts
This was not really about finding a "framework.
It was about choosing the one for the job.
For years my mindset was:
"I'll just use React."
Now its becoming:
"What does this project actually need?"
For interactive web applications React is still one of the best choices available.
For a portfolio or blog Astros approach of shipping static HTML first and loading JavaScript only when its needed feels much more appropriate.
I'm seriously considering rebuilding my portfolio with Astro—not because React is not good enough. Because Astro seems like the better fit, for the kind of website I'm trying to build.
Sometimes the biggest performance improvement does not come from writing code.
It comes from choosing the tool before writing any code at all.
Top comments (0)