| title | description | publishDate | authors | socialImage | lang | ||
|---|---|---|---|---|---|---|---|
Astro 1.0 Beta Release |
The Astro 1.0 Beta is now available! This release marks the stabilization of all major APIs, with no more major breaking changes planned between now and the official v1.0 release. |
April 4, 2022 |
|
/src/content/blog/_images/astro-1-beta-release/social.webp |
en |
The Astro 1.0 Beta is now available! This release marks the stabilization of all major APIs, with no more major breaking changes planned between now and the official v1.0 release.
In addition, we are thrilled to announce that the official Astro v1.0.0 release will be available on June 8, 2022. We plan to use these next two months to improve documentation, squash bugs, collect your feedback, and finish up a few final Astro improvements.
We are incredibly grateful for the support Astro has received so far. Thousands of developers – including teams from Firebase, Trivago, and The Guardian – are already running Astro in production today. If you’ve been waiting to try Astro, there has never been a better time to get started.
Visit astro.new to try out the Astro v1.0 beta release right in your browser. You can also run npm init astro to get started locally. Read our Getting Started and Migration guides to learn more.
To celebrate the release, this post will explore Astro’s background and the 3 core principles that drive our project:
For the last decade, developer tools have optimized for a single type of project—JavaScript applications, typically Single Page Applications (SPAs). SPA frameworks have revolutionized the way we build software on the web, dominating the last decade of web development.
But even the best SPAs come with trade-offs, some of which make little sense in less stateful, content-based websites. Thoughtworks Technology Radar said it best:
"Too often [we see teams] blindly accepting the complexity of SPAs by default even when the business needs don't justify it.” — Thoughtworks Technology Radar
This got us thinking... what would a web framework designed for content-focused websites look like? How would a tool that prioritized performance shift our approach? If we abandoned the notion that SPAs are always better, could we push the web forward the same way that JSX did almost 10 years ago?
We found our answers in Astro.
It should be impossible (or at least very difficult) to build a slow site in Astro.
By default, Astro helps you build sites that ship zero JavaScript to the browser. Astro’s built-in component syntax generates static HTML as much as possible, only sending down JavaScript for any interactive parts of your page. You’ll be shocked by how little JavaScript you actually need when you build your first Astro website.
Astro also lets you bring your own framework. React, Svelte, Vue, Solid, and all of the popular web UI frameworks are supported in Astro. You can mix-and-match these components on your page, while still enjoying Astro’s automatic JavaScript reduction. If a component is 100% static, Astro strips out the JavaScript entirely and just sends it as HTML.
This unique approach to JavaScript (known as partial or selective hydration) unlocks some really compelling, fine-grained optimization features. Components load and hydrate individually, so we can customize and control loading behavior on a component-by-component basis:
<!-- client:load -- high priority, load this component on the page ASAP -->
<MyCriticalBuyButton client:load />
<!-- client:visible -- low priority, only load when visible on the page -->
<MyHeavyReactImageCarousel client:visible />This level of control is extremely difficult in an SPA framework like Next.js or SvelteKit, and wholly unique to Astro.
We designed Astro’s language syntax to be simple, with the hope that anyone could pick it up regardless of background or skill level. Astro will feel familiar even if you’ve only ever used a frontend JavaScript framework, are used to more traditional backend tooling, or are just working on the basics of HTML and JavaScript.
The most important thing to know about Astro’s component language is that it’s a superset of HTML. A valid HTML snippet is a valid Astro component. There are no render functions to export, JSX to return, or hooks to manage. In fact, there’s no JavaScript at all!
<!-- This is a valid Astro component! HTML is the best :) -->
<p>Hello, World!</p>You’d be surprised how far you can get in Astro with HTML alone!
As you gain more experience, you’ll learn how Astro supports dynamic templating with JSX-like expressions and component props. You’ll also grow more familiar with the “frontmatter” component script that we use to run server-side code alongside your template. In no time, you’ll be writing more powerful UI components like this:
---
// Run JavaScript code in your component frontmatter.
// This all runs at build time, so no JS on the client!
const message = "Hello, " + Astro.props.name
---
<p>{message}</p>We designed the rest of Astro to be equally straightforward: We support Web Standard APIs wherever we can, so you can use the fetch() API with top-level await to fetch data from an external source. Use an explicit ESM import to read local data from your project, instead of an invisible implicit data waterfall.
Earlier we mentioned that Astro supports all of the popular UI frameworks—React, Vue, Svelte, Solid, Preact, and Lit. The implications of Astro’s framework-agnostic design are massive, and something that we always consider actively when designing new features for Astro.
Case in point: SolidJS launched in 2021 without an official full-stack web framework like Solid Start. Sure, you could use SolidJS in a new project, but many tools make it impossible to incrementally try SolidJS in your codebase without doing a full rewrite to a new, Solid-compatible web framework.
Framework lock-in can be a huge problem, especially in large organizations that think about technology decisions on a much longer time-scale than the rest of us. In the larger open source ecosystem, framework lock-in just makes it harder for new frameworks like SolidJS to gain traction.
With this in mind, we’ve designed Astro to be completely framework-agnostic. Our focus is to build the best foundation for long-term projects, giving organizations the flexibility to change technologies and frameworks over time. Large organizations like Google can also benefit from streamlining infrastructure and support to just a single tool (Astro) while still giving their frontend teams the flexibility to use their favorite UI framework.
If you’re building a new UI framework for the web, consider launching your project with Astro support.
This week is Launch Week at Astro HQ, so we have a few more exciting announcements lined up for the rest of the week.
- Tuesday, April 5: Going Beyond Static Sites
- Wednesday, April 6: Themes, Components, Integrations
- Thursday, April 7: Contributor Day
- Friday, April 8: Recap (and one more thing...)
Beyond that, you can check our public roadmap for updates as we work towards the official release of Astro v1.0.0 on June 8, 2022! 🎉
If you’re interested in getting involved or sharing any feedback, we invite you to visit our GitHub repository and join our Discord server.