Skip to content(if available)orjump to list(if available)

Astro 1.0 – a web framework for building fast, content-focused websites


I'm looking at and I still can't tell what's interesting and unique about this as compared to other options in this space.

I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation.

It seems like Astro's creators believe "content-focused" is a differentiator, but I find that confusing since content-focused sites are a popular use case for web frameworks that are also suitable for more complex apps.


It's interesting their blog post doesn't mention some of the benefits. Neither does the doc page you linked—at least it doesn't do it succinctly.

Essentially Astro lets you build sites using a JS framework like React or Vue without requiring that framework to be loaded on the frontend. By default, components are just HTML content. Super nice for building very fast static sites using a technology you may already be fluent in.

You can still add interactivity to components if you'd like—just tag components that require interactivity and Astro will bundle the requisite JS for the client.


Not getting it tbh. Why would you go nuclear and develop a React or Vue app and then not actually use it on the browser side? For content-oriented websites there are much simpler workflows based on SGML and other classic markup processing and content management practices. I mean the point of "content-oriented" and web sites in general really is that an expert in the field, rather than a web developer, can achieve useful results as an author.


Component-based UI frameworks and ecosystem has made building frontends much nicer, especially when you need some optional interactivity since you're already writing in JS.

Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.


Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.


You get the speed of SSR but can sprinkle interactivity into the app using the same SPA style frameworks via isolated “islands”.


I suppose it's just a different templating engine (plus some optional features for the client side). Probably as a front-end developer people are more familiar with that compared to Jinja for example? Though I think if the target is static web sites then it's simply overkill.


It might be all you know.

I'm not a web dev by trade but I have a website for a hobby project. I had taught myself React thinking I might make an app. (I never did.)

So now I want to maintain this thing on the side with not much effort using what I already know. And that keeps those skills fresh, which is great.

I'm very interested in Astro.


Their homepage has a nice summary of its approach and benefits.


> using a technology you may already be fluent in.

I think this is the only selling point, given the "content-focused". It's not different than just writing HTML and vanilla js for some interactivity.


So they have moved all the previously frontend stuff to backend and output Hot-wired / Liveview / Livewire instead?


I wish. AFAIK it's just classic server-side rendering with full-page navigation. Mind you, that's the optimal solution in many cases. But a full-stack JavaScript web framework with something like Phoenix's channels and LiveView built in would be a killer combination.


While Astro has a lot of impressive features I found that it was the "developer experience" (god I hate that term) that was superior compared to everything I've tried before.

With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues.

Publii was cool, but trying to shoehorn everything into fitting in the "Blog" model never quite worked out for me. Also being forced to work in a new IDE wasn't to my liking either.

Here are some of the things I love about Astro:

- The docs are great. You can read through them all really quickly. I tend to prefer systems that are simple to grok, and Astro is just that.

- The lightweight Astro components ( were great for me, because they delivered on being able to create reusable pieces of code very easily (without having to touch React).

- Being able to generate part of your site from markdown and part of it from precisely crafted HTML is a great way to be able to handle both repetitive and unique content.

- The Astro themes ( are a great way to start. Find something that's somewhat similar to what you want to build and study how they did it.

This is obviously very subjective, but for me Astro was the first SSG that I really enjoy using, and that I didn't feel like I had to fight against.


> "developer experience" (god I hate that term)

Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience).

Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, it's hardly the only offender) is servers and services, and the users (other engineers) consuming those outputs can have a nice time. The DX of using Chef, though, can be ughh....


> Honestly we need more DX improvements in this industry.

Nope, we need to roll back everything that happened in the last ~10 years. We at the very least need to stop sticking JS and the web stack everywhere. Use the right tool for the job, NOT pick up a shiny tool and try to do literally everything with it. NOT stumble upon solution and start looking for problems to it. Finally realize that software engineering is actual engineering that, like other forms of engineering, has a sizable impact on other people's lives. Unlike in other forms of engineering, the cost of a mistake might feel diminutive enough, but people do suffer trying to use modern software products. I wish I was joking.


100% agree with you that there's a lot of improvements to be done for a lot of the software we developers use on a daily basis. It's the term DX / Developer Experience in itself I dislike strongly. My sibling poster @swyx did a great job explaing my main gripe with using abbreviations like this.

I also hadn't had any coffee in way too long, so I have to admit I was a bit grumpy at the time of writing the comment :)


it is subjective and overused - perfect storm for industry jargon that takes up a lot of space without saying anything more than "this thing sparks joy"


Have you used Next.js much? Next was the first (and so far, only) SSG I enjoyed using in the JS world. Just wondering if you have any comparisons. Markdown generation in Next was also a breeze.


The core concept and main difference is described here I think:

There is also this page comparing it with other tools:


Comparison with alternative solutions is the first thing I look for in the docs. Great that they have it!


For me it's the pre-rendering. I've used Next.js, Nuxt.js, Remix etc and they all server-render great. But for deploying SPAs to file-hosting (S3 + Cloud Front or Firebase Hosting) without a server runtime, you end up with empty HTML on request which is worse for SEO, social previews etc. There are solutions to pre-rendering for these stacks but they're more focused on deploying to Vercel or Netlify functions, or having a post-build script which opens the site in Puppeteer and saves the HTML into your build file! With Astro, all this is out of the box immediately. Try putting together an Astro site and look in your build directory; you'll see even for React components the HTML is already there


I can just do a `nuxt generate` and put it on CF+S3 as well, right? how is that any different to what Astro does?


Yeah you can, but there's more configuration involved. The default `nuxt generate` output is an HTML page that just has a loading element and a bunch of JavaScript tags*. On my Astro apps all of components that don't explicitly have a "client" attribute are prerendered

* unless something changed since my last Nuxt project


Looks the same to me after a quick read as someone who has never used an SSG BEFORE


That's what I find confusing in Astro's self-presentation: they talk a lot about MPA vs SPA and how nicely they blend, making it abundantly clear that by MPA, they mean server-rendered. But then there's all the talk about static file hosting and I think the project even started as a static site generator ("dev-machine rendered")? It would be super awesome if they tackled what might be called "three level partial hydration" (build time, server side, client side).

Might even sneak in a fourth level, "server side, but cached until marked dirty". For when you are set up for static rendering, but want to reduce backend load for rarely changing stuff. I'd expect that it would be quite powerful to have that capability inside the engine that handles rendering, on component level if necessary,and not just on some internal microservice boundary (where I think it's quite common?).


Responding to myself: documentation clearly seems to come from two different areas, one when everything was either client side or build time and another after astro introduced server side dynamism.

Apparently there has been quite a watershed moment, with the announcement merely a few months ago:


If you look at the project structure it uses that might help make it more clear the capabilities: Content-focused seems to highlight that you can just dump markdown files into it and spit out rendered pages, very much like content focused static site generators (hugo, jekyll, etc.). But in addition to that static content it has all kinds of hooks and capabilities to add dynamic components or even pages, kind of like more modern web application platforms like next.js.


The winning point over other frameworks is the implementation of island architectures (streaming ssr static content + only load required js to run dynamic components)

This gives some more examples of what Astro offers


The one thing I like about Astro is the component island UI. With react you would need to re-render the entire UI on a UI change while in Astro you can signify which portions of your website are static and which dynamically should re-render upon data fetching or whatever.

It's just a faster way to build UI's that don't need the full complexity of a SPA and also don't need to come bundled with the entirety of react from what I've seen and used it for.


I feel you, tbh as someone who has NextJS as my main tools, it's hard enough to choose Remix or Redwood as a starter project, when I needed backend it's either Django or Spring boot from time to time.

Not really sure when to play around with these new frameworks if it's not giving me enough reason to switch, especially since they're not adopted in big tech companies it makes it harder to justify the usage when I want to build somethjing


I used Astro recently to rebuild my personal website/portfolio, and I really enjoyed it. I'm not a frontend dev and I quickly get overwhelmed by all of the choices and the breakneck speed that the web ecosystem changes at. Astro was exactly what I needed. It's optimized for spending most of your time writing content in markdown, but it gives you complete freedom to seamlessly add web code of any complexity you like. MDX is just markdown plus custom components, and Astro lets you drop in stuff from React, Vue or Angular, so you're not restricted to whatever components you can find for the single framework that you choose at the beginning of your project. Everything possible is made static. I found it to be pretty intuitive and I don't feel boxed in by it. This is how I want to make (frontend-only) websites in the future.

My biggest issues using it (admittedly in the beta state) were 1) wrong line numbers printed for errors due to extensive rewriting and transpilation without source mappings and 2) no built-in image optimization (there is a third-party tool that works well enough, but for a content-first framework this doesn't seem good enough to me).

[Edit]: Ah, I see in the 1.0 they have built-in image optimization :) I'll have to try that out.


I looked at your site and its source code. The site is snappy and code straightforward. I would love to tinker with Astro when time allows.


Is this it?

> it’s nearly impossible to sail on your own

Just have to comment that this is plain false (as already evident by dinghy sailing). I've sailed up to 35-footers solo (although I'd advise to stay below 30-ish or 3-4 tons, makes it easier to not crash hard into things). It takes a bit more prepping and does help a lot if you have an autopilot or windvane self-steering (for sail changes and reefing) but it can be done without as well.

And I used to sail my 28-footer solo without an engine.

If you're interested in sailing I recommend checking out Per Tangvald (known as Peter Tangvald). He sailed around the world in his homebuilt engineless ~52-footer for decades, generally handling the boat by himself.


No, my site is I know nothing about sailing XD. Thanks for caring enough to share the info with me, though :)


Hey, mind sharing your website?

I'd like to check it out.


I've added it to my profile. It's nothing fancy, mind you, but I think it gets the job done.


Cool, thanks. Looks good


Sometimes all the frameworks that re-invent MVC (but in a detached fashion) and tout "server side rendering" just feel like we've come full circle where we're just serving a static view cache that was generated from models and data using a controller.

The big difference here (as with other JavaScript-based renderers) is of course the "use one tool/language for everything" aspect which to me is a bit of a 'meh'-benefit.

At this point, while all the renderers get better and simpler, we're still in a situation where complexity or writing code hasn't really gone away, it just shifted around to new places. Perhaps at some point we get to the HTML + WebComponents stage again (kinda like MDX and React mixing), and classic Apache Server-Side Includes become the new hot thing again.


I think edge computing and CDNs might be what is making this all more interesting. It is not just where you render (Server vs. Client), it is where you render (Dallas vs. Rio). If you can get your app to re render small sections and have the framework figure out that these sections are static and can chuck them in a CDN (or they are not and need an edge server, or a central server) then you can get lots of optimizations that way.

That said, for most side projects and commercial projects the complexity may not be worth it. It probably makes the most difference to very high traffic sites where money is lost for each millisecond delay in giving you the page (or the ads). And in this sense it may be premature optimization.

I like using Next.js, but I often wonder if it is "too much" and adds complexity I wouldn't have otherwise. An old fashioned rails app, and some caching / CDN done in front of it as a separate concern is probably more than enough performance for most people.


I think that any view cache works fine with edge caching. Worst case your first request has to traverse the CDN network to your compute once every cache invalidation.

That said, none of the static site renderers really do anything special that is required to do anything on any edge. Considering the huge amount of storage and memory required to store a node_modules tree and re-render on demand, even classic MVC would easily do the same.

What would make a somewhat larger difference might be a combination of factors; something like centralised push and distributed compute via WASM. That means any logic could be compiled and packaged as-is without needing anything else. Somewhat similar to using cloud flare workers with something like Go or Zig.

Then again, like you described with the rails example, this is mostly a solved problem. Even a full server-side view with just classic HTML 4 and CSS output can do this, at very low latencies and very wide reach. After the first hit, the difference between this and static pre-rendered pages is almost irrelevant.

The biggest 'solves' one might get would be uncached always-computed content which needs to be executed on demand, and attack surface changes. But that gives us a different class of problem since we could also decide to simply offload all of the hard work to someone else and simply pay Squarespace and the likes ;-)


> I think edge computing and CDNs might be what is making this all more interesting

You know what's old-fashioned way of doing this? Buy multiple VPS around the world and deploy website files using a script.


Since this seems like a fairly separate concern, and it is a fair bit of maintenance, that is nice to outsource to the cloud.

Let the experts deal with adding locations, location detection, DNS, redundancy and so on, for a very small price, relatively speaking.

I am not saying you need Astro: You can make the files yourself, then use a service like Netlify to do the CDN-ing for you.


After having tried and given up on so, so many SSG frameworks, I'm loving Astro. In particular:

- Templates are plain HTML/Javascript, instead of some other templating language (e.g. Jekyll/Liquid)

- Typescript out of the box

- SCSS out of the box

- Easy remote builds on Netlify

- Scoped stylesheets

- No overcomplicated build process/customization (e.g. Webpack)

- Supports Markdown, YAML, JSON, all the things

- It builds really quickly

And all of that is with virtually no additional configuration. It's great.

Also a big bonus: the team is super friendly and very responsive!


Also out of the box:

- Tailwind support

- Optional choice of UI framework (React, SolidJS, Svelte etc...)

- Partial hydration. Generates _actual HTML_ on the server-side rather than JS blobs (which is what some other frameworks call SSR).

It really does work nicely. It's very fast, minimal config required.


As someone who started building web pages in the 90s, the "islands architecture" (generating HTML server-side) of Astro and others makes me laugh because it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago.

We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML.

There's nothing wrong with this coming back around, it worked quite well!

It's just amusing how some things come full circle and are now considered innovative again. I'm sure there are advancements under the hood of course.


Sure, and I was also around when XMLHttpRequest was new and innovative. And development then was awful compared to where webdev is today - I've been in the industry that entire time.

And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that load after the full HTML renders. You could use that to fetch static HTML, or you could use it to provide an interactive client-side experience that only operates on a portion of the page, up to whatever complexity you like. And if the user has JS disabled the rest of the site still renders correctly.


And before Ajax you could use a hidden iframe and update the parent page with some JS.


In early 00s, we even had frameworks that would do this all for you.


I've used Astro my company's landing page for the past year or so [0]. We write blog posts in Notion and port them right to the site and the experience has been fantastic. There are a few understanding quirks with regard to using React etc within Astro (it's SSR'd unless you add the "client" attribute, and counter-intuitively the Component Lifecycle doesn't run the same). For client landing pages, we'll use Astro too- occasionally they'll want a CMS to write their own blog posts without a Git / commit pipeline. In those cases, Netlify CMS plugs in seamlessly and has a generous free tier.



Netlify recently changed their pricing structure, so if you are using Netlify CMS (or just Netlify Identity) with a private repo, every contributor to the repository (committer) will be charged as full pro seat. This can get really expensive if you have a few users working with the CMS (and thus committing content to the repository). We will move a few pages from Netlify now because of this change.


Also, found out the hard way that "Enterprise" pricing (i.e. call us and we'll charge you an opaque amount based on whatever we think you can afford pricing) starts at 7 users.

Vercel is not much better at 10 users, and they hide it deep within their pricing table behind a tooltip so you're not likely to realize this until it's too late.

Cloudflare Pages doesn't charge per user but limits concurrent builds which can get really painful.

I honestly can't find a good option in this space anymore... What happened?


> I honestly can't find a good option in this space anymore... What happened?

They took lots of VC money, got crazy valuations and picked up a few enterprise customers as the JamStack trend grew - and now have to try to generate a return.


Assuming that 7-10 users are FTE, the company is already spending more than $1M on salary and related costs. I imagine the annual Enterprise pricing for Vercel for that numbers of users would hover around 1/4 of an FTE's salary, which is reasonable considering the value provided.


You can use CF Pages with your own build infrastructure, it has "direct uploads" now. It's currently unlimited in the amount of deploys you can do a month. I don't think CF knows how to price it yet, so I wouldn't rely on this being free forever.


+1, looking for answers too.


That pricing change only impacts private repos owned by organizations — you can still have private repos on a personal account and not be charged.


Interesting, how does the process of going from Notion to Astro work? Are you just exporting Markdown files, or is there an API integration in use?


Sorry for the late reply- we use the API! We had done so manually for a long time


Really interesting stuff especially for existing jam stack websites, but oh god

> This vision of a better web is why Netlify is bullish on Astro

can't this horrible stock market and crypto bro lingo stay in the casino bubble.


One thing that's not too clear to me is if it's possible to use existing UI libraries. For example, to install Vue's Quasar component library I need to run

    import { createApp } from 'vue'
    import { Quasar } from 'quasar'
    app = createApp()
But since astro abstracts away the root Vue application, I don't see how this is possible anymore.

Astro might make sense for a blog where you don't need a full blown component library but for any other web application, I'm skeptical of its capabilities.


If you are trying to "flip" websites, SSG isn't the way to go. I created websites with my own SSG using Javascript, Eleventy, Nuxt, Next.

But when I create a website now, I got to stick with Wordpress because they are easier to sell and non tech people can use it.


Check out Primo. Still in Alpha but very promising for that use-case.


It always annoys me when I read something like:

   To try Astro on your local machine, run npm create astro@latest in any terminal.
because it doesn't make it clear to me what to do before this command will actually do anything. No, running this command will not work in any terminal.


A few years ago when I was trying to understand the new JavaScript world with React and all its toys (moving from my background of PHP and other 'old-school' server-side rendered solutions), I hit problems similar to this.

This particular example isn't too bad -- looking at that line, it would be clear to me that I'm missing 'npm', and the solution is obvious -- find out what npm is, and get it installed. But the things that really bit me were tons of examples of JavaScript, which included strange lines like 'import', and I had no idea how to get my website's JavaScript to understand what an import is or any of the other syntax. Nothing would work! I didn't realise there was a whole ecosystem around how to build your code so that it can make use of these things. Every guide assumed I had things going, and I just didn't understand that I needed this other infrastructure in place first before I could do anything.


I’d recommend reading this[1] (fantastic) article that came out a few years ago. It’s exactly the kind of guide you’re looking for.


Some notes of things that have changed in the last five years:

- bundling is (almost) no longer needed for simple import/export as we now have a native module capability (esmodules). The biggest issue you’re likely to have here is waiting for any dependencies you have to upgrade from common js to esmodules.

- transpiling is not as necessary unless you explicitly have to support IE11, or require something in the latest ecmascript spec.

It really speaks to the maturation of front-end development that after five years that article is still fairly accurate.

About time too - I’m too old to put up with that level of churn anymore.


As long as you have npm installed it'll work. Npm create is an alias for the npm init command [1], which will look for a package with the prefix 'create-', install it, and run its bin file. It looks like this is the file that ends up being run:



> As long as you have npm installed it'll work.

Exactly proving my original point.


Well obviously you'll need npm to use a command that begins with npm. If someone gave you a terminal command to run that begins with curl, you'd be expected to have curl installed. This seems like pure pedantry.

Take a look for example at the rust installation steps [1]. They tell you to run the following command in your terminal: "curl --proto '=https' --tlsv1.2 -sSf | sh". They don't tell you to first make sure you have curl installed (or sh for that matter).



If you don't have npm installed, just stay as far as you can from this :D

Seriously, JS static website generators are the worst... use something written in any compiled language so you just download and run a single binary, no messing around with npm and millions of dependencies.

Take your pick here:


> in any terminal

I agree; the "in any terminal" part is paternalistically redundant - any software developer who recognizes the npm command will know what to do with it.


Because it is written in JS it assumes you have NodeJS installed. npm is the package manager bundled in with NodeJS.


just use yarn bro, or npx

the reason node based documentation sucks so bad, is that generally by the time you read it, it's already deprecated.



I used a static site generator for all of these benefits in the past, but the rebuilding process is a total nightmare.

The site has about 20 categories, and each category has about 100 images. Every time the team adds a new image or category, the deployment/building task clones the repo and then the build process generates all the optimally sized images again and then re-uploads multiple gigabytes to the host. Is there a way around this type of problem with static site generators?


Offload image optimization to separate service?


You might need ISR (incremental static regeneration). IIRC there are a couple standard SSG frameworks that support something like it. Usually only worth investing in if you are operating at a large enough content scale though.


A makefile


So excited for this. SSR with Astro is a gamechanger which opens up its usage to so many different avenues. Great strides with framework interop too. Named Slots really closing the gaps.

And of course any framework where SolidJS can shine so bright is going to be the top of my list.

Congratulations on an amazing release.


I'm developing in-house business apps, so I'm probably a bit ignorant regarding the new trend of all these SSR/hybrid/transitional frameworks. But I'm curious:

Is the difference in page loading speed really that significant? SolidJS or Svelte apps with lazy component loading are already pretty fast - Ryan Carnatio has shown some benchmarks on his Youtube streams where the differences are in the ballpark of around 50-500 ms IIRC. Is it a mobile client thing? Or more like "We are Amazon and every 0.1 seconds waiting for the page some xyz customers leave and therefore costs as quite some money"?

I mean, those frameworks are really complex. Is it worth it if you already use a fast and small SPA framework like SolidJS or Svelte?


500ms for a single page load? that's significant. even 50 is pretty significant. we should be targeting 400 or less, total to render the page