Why I use Astro

I’ve been thinking about writing this since a few months ago when some prominent people in the industry were battling “why I use Next.js” vs “why I use Remix”.

Now, I don’t try to claim that this is the thing you should do.

It’s just a collection of thoughts on why I use Astro.

What works for me.

And what works for me might not be what works for you.

That said, I’ve been using Astro for well over 2 years now.

For like a dozen of sites, from small to medium-sized.

Medium-sized like this blog which has 1600 blog posts and hundreds of thousands of visitors per month, or The Valley of Code which has a ton of content, and a members-only area.

I won’t go bigger than this.

I also build sites that are single landing pages with an email opt-in.

Simple stuff, really.

No Facebook-level applications. I will never build one of those, and I don’t care to build one of those or the scale of problems that this kind of app brings to the table.

I want to build one-page websites, sites with a few pages, blogs, storefronts, and sites that might get from 10 visitors a day to 10,000 and I don’t have to maintain a Kubernetes cluster or a docker swarm or some complex AWS setup to run them.

I host my static sites on Netlify, Cloudflare Pages, and more dynamic ones on Vercel or DigitalOcean, using Droplets or the App Platform.

Here are my needs as a solo indie Web Developer creating these kinds of sites and web applications:

• I want my tools to be simple to use: if I have to create an entire castle in my head to understand how things work, it’s not going to be a healthy relationship between me and that tool
• I want my tools to be flexible: I have needs, and the tool should be designed effectively to fulfill my needs, to do what I want (within certain constraints, of course)
• I want my tools to not change: it takes a while to learn something, and once I spend time to learn something, I don’t want that thing to change. Small changes, ok. Radical mind-shifting changes, hell no
• I want my tools to grow with me: I hate the idea that a tool is limited to “toy apps” and cannot “scale”. But I also hate the idea that a tool should be hard to use right from the start, because “it can scale”. It should be nice to use at a small scale, and also nice to use at (relative) scale (not Facebook’s scale, of course)

I find that Astro satisfies all those points for me.

Also, Astro is conceptually simple.

By default, an Astro website is static, and it’s generated at build time.

It creates plain, simple HTML.

This means I can deploy Astro on any hosting platform that allows static sites to be hosted, including my favorite Netlify, and also Cloudflare Pages, Vercel, and more complex ones too.

Heck, if you want you can even build the site locally and just upload the dist folder on shared hosting or S3 via (S)FTP or rcopy, like we used to do (I’ve never done this, but it’s nice to know I can). Or have your own VPS with a Web Server and host the site there.

I can’t emphasize more how amazing a static site is. No more worrying about the Web Server, a backend language, if it’s up or down, being hacked, whatever.

This has been one of the key selling points for me. Instead of having a server-rendered site, or JavaScript create the interface for me client-side, I want my sites to be 100% static most of the time. Just turned to HTML pages at build time.

But I still want to use an excellent framework to build those sites.

And, if I want to server-side generate a few pages, Astro got me covered. I can enable “hybrid mode” and I can decide “this page should be server-side-generated upon each request, not statically generated at build time”.

If I want, I can also enable “server mode” to do the opposite: all pages should be server-generated, and I can optionally set some specific pages to be statically rendered at build time.

I have total control over the HTML rendering, and I can even just use author plain HTML.

But typically I use the Astro Components syntax.

A couple years back I introduced Astro to my bootcamp students right after teaching basic HTML and CSS, so I could teach how to build a UI using components. Astro has this very cool component-based system to build UIs which I think is kind of unique in the space.

It works exactly like you’d expect with JavaScript modules, you import an Astro file, and then it works like you’d expect in a modern frontend framework, you add the component to your HTML like it’s an HTML tag.

You can pass props to it, too, like in a React/Vue/Solid/Svelte component.

Except it’s all then rendered statically as HTML.

Astro Components have this syntax which is basically JSX like in React, but with a better DX (developer experience) than in React (for example no className, no key in loops, no fragment…).

So if you come from a React background, Astro Components will make you feel at home.

I previously said that there is no client-side JavaScript by default. This doesn’t mean we can’t add client-side JavaScript if we want.

We have to specifically enable client-side rendering, but once you do, JavaScript is shipped to the client, and you can do anything. With one peculiar feature: you can use whatever frontend UI library you want.

Even multiple ones.

Embed a Svelte component alongside a React one? No big deal (never had the need, but nice to know I can use the tool I think is best for doing a specific thing).

This lets you do 2 things:

build interactive interfaces using “JavaScript sprinkles”, where little specific portions of the UI are interactive build immersive client-side interfaces, and full “client-side rendered” apps. It all depends on your needs.

But by default, Astro tries to limit the amount of JavaScript shipped to users, and I think that’s a good thing.

We’re overusing JavaScript these days. Even for things that the platform already gives us.

Next up is markdown.

I use markdown for everything.

My blog has 1600+ blog posts written in markdown, and my biggest tutorial site (The Valley of Code) is entirely written in markdown.

I just love it.

And do you know what I also love? Astro, because it has an incredible markdown integration. It just works. It has something called “content collections” which helps you manage all your markdown content.

I tried building a blog with other frameworks and it’s just not the same thing.

Markdown in Astro is a first-class citizen. Not an afterthought or something you integrate.

Yesterday I built a 1-page website with just 1 markdown file, I just dropped the .md file in the site, and voilà it works.

It provides built-in syntax highlighting, so you don’t have to worry about it.

Do you want to embed a little Astro component in markdown? Use MDX, simple. Built-in too.

Those are just some of the reasons why I use Astro.

In the end, it’s about the ergonomics and feelings.

I really like using this tool.

I don’t fight against it.

It’s lightweight and it doesn’t put me against the Web Platform. On the contrary, it enhances the Web Platform and my interaction with it.

And the team behind it is filled with smart people that make smart and sane decisions. They have built a great product. Useful, and neat, and it doesn’t try to do too much or impose too many restrictions upon me.

I think you should try it too, and see what it’s all about.

Now let me add a section of updates, I’ll add an item any time I’ll think “I should have added this thing to my blog post”:

• Do I want to add some client-side JS to a page? No need to fight a framework, just add a <script> tag in the page, anywhere you want.
• Do I want to add some CSS to a page? No need to fight a framework, just add a <style> tag in the page, anywhere you want.