What is Astro? Its technical approach and how it works

Until recently, when I built a corporate website, the usual choice for me—and for almost everyone—was WordPress. For obvious reasons: it’s easy, almost everything you need is already built, and after many years my workflow is very fast.

But on the latest project I developed, the website for Rondabus, I used Astro. 

The reason?

It had been recommended in an AI newsletter I follow because, they said, it integrates very well with agents.

And it certainly does.

I mainly treated the project as a test of the current state of web development. To see how much still depends on a human and how much can already be done with AI. That is why I used the recommended framework.

Obviously, I did my research to understand whether it suited what I wanted to do. That research led to this article, where I explain what you need to know to give it a try. And a bit more.

But before we get into it, a couple of things:

The first is that I was blown away by its HTML first approach. It is exactly what I had been preaching for years.

The second is that, as of today, when developing a website, apart from judgment, ChatGPT or Claude can provide everything else..

Now, let’s begin.

What exactly is Astro?

Astro is a framework for building websites, that is, a set of tools and guidelines that helps you generate your website’s code.

No more, no less.

There are many frameworks, each with its own quirks. Here I’ll explain Astro’s.

Astro lets you work with reusable pieces, shared data and templates. It then combines everything to produce the website.

In other words, think about what you need to build a company website: header, menu, service pages, photos, text, a form and footer. You could write every page by hand in HTML, but you would repeat a lot of work.

If you change the phone number, add an item to the menu or add a link in the footer, you would have to update it in every file on the site. Not with Astro, because it reuses elements.

And you’ll tell me WordPress does the same thing. Yes, true, but there is no database behind it here.

You could also reply that this is like any server-side language such as PHP, and I would answer that you do not need any language running on the server—just the files stored there.

Like websites were originally made: one HTML file per URL, with its accompanying CSS and JS.

In fact, you can use HTML, CSS and JavaScript or TypeScript, but you can also add React, Vue or Svelte components if you need them, which I don’t.

So how do you get reusable elements and lots of HTML files?

The fundamental difference: generate the website before the user arrives

To understand Astro, it helps to separate the two moments in a website’s life:

1. When it is developed.
2. When someone visits it.

On a traditional dynamic website, the server prepares the page when it receives a request. It runs code, gets the necessary data, puts it into a template and returns the result to the browser.

WordPress, for example, works this way: PHP runs the application, queries its database and uses the theme and plugins to generate the page. Yes, the cache can save a response and reuse it, so the entire process does not have to be repeated on every visit. The important thing is to understand that there is an application capable of producing the response while the website is running.

However, with Astro you can do that work before publishing. You prepare the pages, generate the files and place the result on the hosting. This is what is called a build..

So when someone opens the contact page, the server delivers an HTML file that was already created. It does not need to rebuild the header, retrieve the phone number and assemble the footer for that visitor.

This way of working is called SSG, or static site generation. And it has several advantages, such as the fact that websites built this way literally fly..

There are more, which I explain in the article.

What I’ve explained so far should give you an idea of what we’re talking about if you’re not technical. If you are, from here on we’ll go deeper into how the framework works.

Strong coffee for coffee lovers. You’ve been warned.

Let’s talk about builds

First, understand that a build is simply the result of an automated process that takes all the files you have written (code, images, styles) and turns them into a package ready for the server or web browser to run..

That’s it.

In other words, you have a series of code files that do different things. When you run the command to compile the build, Astro identifies the pages, gets the content, runs the templates and prepares the assets, finally giving you a complete static website, with its HTML, CSS and JS (if needed)..

For example, you might have one shared template and eight service records. The build combines the template with the data for each record and produces the corresponding pages.

In Astro, this is done with the command npm run build , which normally runs astro build. . The website prepared for upload is in the dist folder, ready to be uploaded to the server your domain points to.

How a page is built in Astro

If you’re not used to it, the vocabulary sounds more complicated than it is. Let’s look at it with a small company website.

What an .astro file looks like

An .astro file can combine a code section with an HTML-like template:

—

const titulo = 'Transporte para tu empresa';

—

<h1>{titulo}</h1>

<p>Organizamos los desplazamientos de tu equipo.</p>

What appears between the two groups of dashes prepares the data. Below it is the template that uses that data. The braces indicate where a value should be inserted.

That code runs when the website is built, and the browser receives a normal heading with its text and a normal paragraph, using the contents of the variable titulo.

Components

The elements that are reused.. 

For example, the header can be one component. The footer, another. A template for the hero banner module on service pages can be another. You store them separately and use them on the pages that need them.

For example, a page can import Header.astro and Footer.astro and place <Header /> at the beginning and <Footer /> at the end. Astro turns those pieces into the corresponding HTML markup.

Props

The props are the data you pass to a component so it can be reused with different content..

If you have created a component for the hero banner module on service pages, you can pass it a title, a description and an image. The structure keeps its design while the values change. So the hero module for service 1 can be one thing and the one for service 2 another, with different content but the same design.

In Astro, the component can read those values through Astro.props. 

Layouts and slots

A layout is a structure shared by several pages. Let’s say it is like a component taken to the next level: : a component is usually a small part of a page, while the layout covers practically the whole page..

It can include the HTML document, metadata, header and footer.

The slot is the space where each page’s own content is placed. 

If you come from WordPress, it will remind you of templates that share a header and footer while the main content varies between URLs. It does not work exactly the same way, but it serves a similar purpose: avoiding rebuilding the shared parts every time.

How Astro organizes URLs

Astro uses a file-based routing system. In a simple project, a page’s location inside src/pages determines its address:

File	Route
src/pages/index.astro	/
src/pages/contacto.astro	/contacto
src/pages/servicios/bodas.astro	/servicios/bodas

The trailing slash depends on the configuration and hosting, but that is the basic relationship.

You do not need to manually create a different file for every article or service. That lets you generate many pages from one template and a dataset, without copying the same code again and again.

Where content is stored if Astro has no database

The fact that Astro does not require a database means text and data have to be stored in some kind of source; you can choose which one.

Files, Markdown, JSON and YAML

For a small site, some text can live directly in the pages. Shared data, such as the phone number, is better kept separately so you do not have to update it in twenty places.

An article can be stored in Markdown, a text format with simple markup for headings, lists and links. JSON and YAML are used to organize data: service records, vehicle information or text by language, for example.

They are different formats for different needs. You do not have to use all of them or turn every sentence on your website into a complicated structure.

Content Collections

The Content Collections help organize sets of data entries and define their structure..

Imagine a services collection where every record must have a title, description and image. You can define those rules and validate the data, making it easier to detect an incomplete record or a value of the wrong type.

If you know WordPress content types and custom fields, the idea of organizing records will feel familiar.

Advanced content: APIs, CMSs and external databases

Even though we are generating static websites, content can also come from a CMS, an API or a database. An API is a way for two systems to exchange information: Astro requests data and the other system delivers it.

You can even use WordPress as the source for articles and build the public-facing site with Astro. We’ll return to this combination in Astro vs WordPress..

The key question is when you retrieve that information. If it is incorporated during the build, changing it at the source does not modify the published HTML until you regenerate it. If it is requested during a page request or from the browser, the behavior is different and more like traditional dynamic pages.

What Astro Islands are

A page can have lots of content that you only need to read and a small part you want to interact with. For example, a quote calculator inside a service page. Or a form..

The islands architecture allows that component to have its own behavior without turning the whole page into an application that runs in the browser.

What hydrating a component means

Hydration means adding the code for an interactive component to HTML that has already been generated, so it can respond to user actions.

The calculator or form can be displayed when the page loads and then activate its logic.. 

Here we are talking about client islands. Astro also has server islands to handle dynamic parts separately, although you do not need to get into them to understand this first explanation.

When the browser needs JavaScript

Not every interaction requires an island. A link works with HTML. A simple menu dropdown can be handled with HTML and CSS.

By contrast, a calculator that updates results as you change options will usually need JavaScript. And the form needs an integration or server-side language to send the data.

And this is what I love about Astro’s approach: the decision is based on the function you want to provide, not on the worn-out idea that a modern website has to load an entire application..

Astro tries to send zero JavaScript by default

Careful, let’s not get confused: we are talking about the website the user actually sees.. 

Because Astro does use JavaScript for development and compilation, but .astro components do not need to send their preparation code to the browser. 

Scripts you add, islands you hydrate and external tools can still add JavaScript. A chat, an analytics platform (GA4) or an embedded video needs it.

So “zero JavaScript by default” is the starting point, not a requirement.

And, as I explain below, this fits corporate website development extremely well for me, for example.

Astro can be static, dynamic or hybrid

Right, so far I have focused on just one approach, but there are two possibilities.

SSG

What we have seen so far: the page is generated before visits, during the build. 

It is perfect when the content can remain the same for everyone until the next publication. In other words, for pages that do not change much.

SSR

The page is generated on the server on demand. It can use information that is not available during the build, such as data associated with a session. 

Not just any server will do anymore: you need a compatible runtime environment and the corresponding adapter.

Hybrid rendering

You can combine prerendered pages and on-demand pages. For example, keep public pages prepared in advance and handle a private area on the server.

What role Node.js and Vite play

Node.js lets you run JavaScript outside the browser. In a typical Astro project it takes part in development and in building the site, where npm helps manage packages and commands. For a static website, Node.js does not need to be running on the production server that hosts the build.

Vite is an engine used by many modern frameworks. It is part of the machinery Astro uses to work with files and provide the development environment. 

Enough to give you the idea.

How an Astro project is organized

When you open a project, you will see folders that are not pages and files that are not published. This small map will help you tell them apart.

src

It contains the source code: pages, components, layouts and other working files. This is where much of the website is built.

public

It contains assets that are served without the usual processing applied to imported files: a robots.txt or certain images, for example. Anything you put here will be public, so it is not a place for credentials.

package.json

It describes the project, its dependencies and its scripts. This is where it is defined what commands such as npm run build do. The dependency lock file helps preserve specific versions so the installation can be reproduced.

node_modules

This is the folder where the packages the project needs are installed. It is normally rebuilt from the dependency files and is not stored in full in Git.

dist

It contains the production output after the build. For a static website, this is where you will find the files ready to publish.

What the browser and Google actually load

I’ll say it one more time for those in the back row: the browser does not receive your project as you see it in the editor. It receives the HTML and the resources needed to display and use the page.

A search engine requesting that URL will receive the HTML, whether you prepared it during the build or generated it on the server. That does not guarantee it will index or rank it well: content, links and crawl/indexing settings still matter, but in my experience you can optimize what it receives very, very well.

The idea I want you to take away is this: all those templates, collections and components exist to produce a website that still uses the technologies we have always used. Astro directs the creation of the site; the resulting HTML is received by a browser.

Conclusion: what kinds of websites Astro makes sense for

This way of working fits websites whose content does not change excessively:

• Corporate websites.
• Portfolios
• Landing pages.

I would not recommend it for magazines, blogs and websites where a lot of content is created or several content creators work. For that, I still prefer WordPress over Astro..

If you like the approach and want to learn more, you can continue by reading about Astro’s advantages and disadvantages..

And if you prefer to apply it to a complete project, I have prepared the process of building a local business website with AI, using my latest project as the example.

I guarantee that once you try it, there is no going back.