Hello! Welcome to your first lesson on building a modern accounting website with Astro.
Your background as a UI Engineer with strong experience in React and its ecosystem gives you a fantastic starting point. You're already familiar with building dynamic user interfaces and understand the Single Page Application (SPA) model inside and out. This lesson will leverage that knowledge to highlight what makes Astro different and why it's a powerful choice for your project goal.
Today, we will tackle the first learning outcome of the course: explaining what Astro is and how it differs from React SPAs in terms of rendering strategy. We'll explore the core philosophies behind Astro, compare its Multi-Page App (MPA) approach to the SPA model you know, and introduce the concept that makes Astro so fast: the "Islands Architecture."
Let's begin.
The World You Know: React and the Single Page Application (SPA)
From your work with React, you're accustomed to the SPA model. In a typical React application (often set up with a tool like Vite or Create React App), the browser downloads a large initial JavaScript bundle. This bundle contains React itself, along with all your application's component code.
Once loaded, React "hydrates" the page—it takes over an empty HTML shell and builds the entire user interface on the client-side, attaching all the necessary event listeners and state management logic. When you navigate from one page to another, client-side routing handles the view change without a full page refresh, creating a smooth, app-like experience.
The key characteristics of this model are:
- Client-Side Rendering (CSR): The browser does the heavy lifting of rendering the UI.
- Full-Page Hydration: The entire application is made interactive by JavaScript, even if most of the page is static content.
- Large Initial JavaScript Payload: All the code needed for the entire app (or a large initial chunk) must be downloaded upfront.
While excellent for highly interactive web applications (like dashboards or social media feeds), this model can be overkill for content-heavy sites, where performance and SEO are top priorities. The large JavaScript bundle can lead to slower initial page loads, which is precisely the problem Astro was designed to solve.
To get a concise refresher on these rendering models, let's start with a quick overview.
React vs Next.js vs Astro: Content Sites vs App Platforms (2026)
The following article, "React vs Next.js vs Astro," provides a helpful table defining the key rendering terms we'll be discussing. It's a great reference for clarifying concepts like SSR, SSG, and Hydration.
Please read just the first section, which contains a table defining key terms. Focus on the definitions for SSR, SSG, Islands Architecture, and Hydration.
Introducing Astro: A Different Approach
Astro is a modern web framework specifically designed for building content-driven websites—like blogs, marketing sites, e-commerce stores, and the professional accounting site you aim to build. Its primary goal is to deliver the best possible performance by drastically reducing the amount of JavaScript shipped to the browser.
To understand why this is a fundamental shift, please read the "Why Astro?" page from the official documentation.
The official Astro documentation clearly explains the framework's design principles. This will help you understand its core philosophy.
Read the sections titled "Content-driven" and "Server-first". Pay close attention to how Astro positions itself against frameworks designed for web applications and its distinction between the MPA and SPA models.
As you just read, Astro embraces a Multi-Page App (MPA) architecture. Unlike an SPA, where the client manages routing, an MPA requests a new, complete HTML page from the server for each new URL. This is a classic web architecture, but Astro supercharges it with modern tooling.
This server-first approach leads to Astro's most defining feature: zero client-side JavaScript by default.
The Core Difference: Zero-JS by Default and the Islands Architecture
In a React SPA, JavaScript is essential for the page to render. In Astro, it's optional. Astro renders your UI components to static HTML on the server at build time. The browser receives lightweight, fully-formed HTML and CSS, resulting in incredibly fast page loads.
But what about interactivity? Your accounting site will need interactive elements like a mobile navigation menu, a contact form, or testimonial carousels. This is where Astro's "Islands Architecture" comes into play.
Watch this short, energetic video from Fireship for a high-level introduction to the concept.
Astro just Launched.... Could it be the ultimate web framework?
This video from Fireship provides a quick and engaging overview of Astro's core features, including its approach to handling JavaScript.
Watch from timestamp 00:52 to 01:50. Focus on the explanation of shipping zero JavaScript by default and the concept of 'islands of interactivity.'
An "island" is an interactive UI component on an otherwise static page. You can think of your webpage as an "ocean" of static, server-rendered HTML, with a few "islands" of client-side interactivity.
This approach is also called partial hydration. Instead of hydrating the entire page as a single unit (like in a React SPA), Astro hydrates only the specific components you mark as interactive. This means if you have a page with 10,000 words of text and one "like" button, only the JavaScript for that single button is sent to the browser.
For a more detailed technical comparison of how this differs from the hydration model in React-based frameworks, the following video is very insightful.
Next.js vs Astro Rendering Strategies (SSG, SSR, Hydration, and Server Components)
James Q Quick provides a deeper comparison of rendering strategies between Next.js (another React framework) and Astro. This will directly connect to your existing knowledge.
Please watch two segments: Astro's Default (SSG): From 01:26 to 03:43. This explains how Astro generates pages by default. Astro Islands vs. Hydration: From 09:04 to 12:43. This is the most crucial part, as it directly contrasts Astro's partial hydration with the full-page hydration model of SPAs.
Test your understanding!
Imagine you are building a blog post page for your accounting website. The page contains the article text, several static images, and an interactive "Share on Social Media" widget at the bottom.
How would the JavaScript for this page be handled differently in a traditional React SPA versus an Astro site?
Show answer
- In a React SPA: The entire page would be controlled by JavaScript. The initial download would include the code for the article, images, and the share widget. Even though the article text is static, React would still need to process it on the client to render the page and make it interactive (a process called hydration).
- In an Astro site: The article text and images would be rendered to static HTML on the server. They would arrive in the browser with zero JavaScript. Only the "Share on Social Media" widget, marked as an interactive island, would have its JavaScript sent to the browser. The browser would load the static content instantly and then hydrate just that one small component, leading to a much faster Time to Interactive.
Summary: SPA vs. Astro at a Glance
Let's consolidate everything into a clear comparison. The inhaq.com article you reviewed earlier has excellent summary tables that make the differences clear.
Here is a breakdown based on that resource and what we've covered:
| Feature | React SPA | Astro MPA |
|---|---|---|
| Default Rendering | Client-Side Rendering (CSR) | Server-Side Rendering (SSR/SSG) |
| Architecture | Single-Page Application (SPA) | Multi-Page Application (MPA) |
| JS by Default | High (React + App Code) | Zero |
| Hydration | Full-page hydration | Partial hydration (Islands) |
| Best For | Complex, app-like experiences (dashboards) | Content-heavy websites (blogs, marketing, e-comm) |
| Performance | Slower initial load, fast subsequent navigations | Extremely fast initial load, traditional navigation |
The performance metrics from real-world sites tell a compelling story about why this matters for your project:
| Metric | React SPA (Typical) | Astro (Islands) (Typical) |
|---|---|---|
| Initial JS Bundle | 150-300kb+ | 0-20kb |
| Time to Interactive | 3-5s | 0.5-1.5s |
For a content-driven accounting website where first impressions and SEO are critical, Astro's approach offers a significant advantage out of the box.
Conclusion
In this lesson, we've established the fundamental difference between the client-centric SPA model you're familiar with and Astro's server-first, content-focused approach.
Here are the key takeaways:
- React SPAs render on the client, requiring a significant JavaScript bundle to hydrate the entire page, making them ideal for web applications.
- Astro is an MPA framework that renders to static HTML on the server, shipping zero JavaScript by default for maximum performance.
- Astro uses the Islands Architecture to enable "partial hydration," meaning only the interactive components you specify are hydrated on the client. This keeps pages lightweight and fast.
This foundational understanding of Astro's rendering strategy is the first step toward building the high-performance, maintainable website you've envisioned.
Up Next: We'll build on this by diving deeper into Astro's default rendering mode: Static Site Generation (SSG). You'll learn why it's the perfect strategy for content-heavy sites and how it contributes to superior performance and SEO.