You can’t even look at code or documentation for Astro (publicly) yet — it’s an in-progress idea — but you can watch a video of Fred showing it off to Feross.
I gotta admit: it looks awesome. I’m bullish on two major parts of this:
- Jamstack is a good idea. Producing static, pre-rendered, minimal (or no) JavaScript pages is smart.
- Components are a good idea. Crafting interfaces from composable components is the correct abstraction. JavaScript does it best right now because of things like ES Modules, template literals, web components, deeply developed tooling, etc.
I’m a fan of Eleventy also, and this feels like Eleventy in a way, except that I don’t like any of the templating languages as much as I like JavaScript components.
Here’s a list of some interesting aspects:
- Like Vue has
.vue
files and Svelte has.svelte
files, Astro has.astro
files in a unique format. I like how it enforces JavaScript-at-the-top in a Frontmatter-like format. - It doesn’t replace other JavaScript libraries. It’s like a site-builder framework on top of them. You can literally use React and JSX components, or Vue files, or Svelte files, including using that library’s state management solutions. You
import
them in your Astro files. - It has the-filesystem-is-the-default-router, like Next.
- It has scoped-CSS-by-default like Vue’s
<style scoped>
, meaning it doesn’t even need CSS Modules since you get all the benefit anyway. - It ships no JavaScript to the front-end at all, unless you specifically opt-in to it (or use its
:visible
syntax, which injects just enough JavaScript to lazy load more as needed). - It embraces the idea of Islands Architecture — the idea that most sites are composed of static content with only parts of interactive/dynamic content.
- The idea of only requesting JavaScript for interactive components if they are visible (via
IntersectionObserver
) is a first-class citizen of the framework — Kinda likeloading="lazy"
for anything interactive. - They credit Marko (the HTML/JavaScript-kind hybrid language) right on the homepage (for “asking the question”). Reminds me of approaches like Alpine or htmx.
- It sneaks MDX (or the like) in there, meaning you can author content in Markdown (good) but sneak
<Components />
in there too (also good).
I quite like that it doesn’t have this whole, This is a new thing! You like it! Old things are bad! New things are good!
sort of vibe. Instead, it has a We’re gonna steal every last good idea we can from what came before, and lean on what the native web does best
vibe which, in turn, makes me think of Baldur Bjarnason’s “Which type of novelty-seeking web developer are you?” article
Bad:
This is the first kind of novelty-seeking web developer. The type that sees history only as a litany of mistakes and that new things must be good because they are new. Why would anybody make a new thing unless it was an improvement on the status quo? Ergo, it must be an improvement on the status quo.
Good:
This is the other kind of novelty-seeking web developer, one who seeks to build on the history and nature of the web instead of trying to transform it.
This looks pretty interesting — I’m always kind of split between Next.js and Eleventy — Like the former for React/MDX and the latter for speed and simplicity. Astro may help me mix the too. Looking forward to trying it out.
I created HTMF which is similar to HTMX, etc. It is progressively enhanced MPA/SPA. Super simple.
https://github.com/jon49/htmf
Jon Neal on the visibility trick:
Also extra context on the usefulness of MDX in this context. Here’s Josh W. Comeau on how he built his blog:
Josh uses this to great effect in many blog posts creating interactive demos. Not that you couldn’t do that in any other way, but the ergonomics of doing it as a React component make a lot of sense.
Definitely something I’ll be keeping an eye on.
I share your feelings about Eleventy. It’s a great SSG but I prefer a component-based setup as well.
Elder.js is another SSG you might want to check out that tries to tackle some of these same things. I just used it to re-do my personal site and am planning on using it for more projects going forward. It’s Svelte-based, so everything lives in
.svelte
files. And it’s also 0kb JavaScript by default; if interactive components are included, it uses anIntersectionObserver
by default for partial hydration.