[Robin]: Exciting news! This week Astro was formally introduced — it’s a static site builder that is, well, pretty gosh darn exciting:
In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page. No monolithic JavaScript application required, just static HTML that loads as fast as possible in the browser regardless of how many UI components you used to generate it.
The idea here is that we get all the developer benefits of those frameworks whilst not hurting the user with long page loads or bundle sizes. And this is wonderful since a lot of folks in the front-end community have long complained that these frameworks favor developers over users.
Also, it’s worth noting that this blog post is extremely quote-worthy. Here’s another snippet:
Poor performance is often framed as a failure of the developer, but we respectfully disagree. In many cases, poor performance is a failure of tooling. It should be difficult to build a slow website.
There’s a blog post somewhere out there on the information super highway (which I’ve now forgotten the link to) which happens to complement the design of HTML and how it’s a remarkable thing because it’s so very hard to get HTML wrong. And CSS, too! If you mess up a CSS rule then your website might look a bit borked but all of the content on a page is still accessible. That’s really the sign of a well-designed system: that even when it breaks, it still kinda works.
However, once you start building more complicated websites with frameworks and state and what not then the surface area for failure expands exponentially. And so on this note, I agree with the Astro folks here. There’s no reason why we can’t have a great developer experience and a wondrously fast and accessible website spit out the other end. And our tools should be well-designed systems.
So how do we go about using Astro? Well, we have to make Astro components with the .astro file format:
Think of
.astroas component-oriented HTML. Components are reusable, self-contained blocks of HTML and CSS that belong together.
So we can write plain ol’ HTML and throw that in an .astro file:
<main>
<h1>Hello world!</h1>
</main>That right there is a complete Astro file! These files also share the concept of Front Matter, just like in Jekyll. And that’s where you define local variables:
---
let name = 'world';
---
<main>
<h1>Hello {name}!</h1>
</main>…or import other components:
---
// This area is TypeScript (and therefore JavaScript)!
import MyComponent from './MyComponent.astro'
---
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<MyComponent></MyComponent>
</body>
</html>There’s some tiny things I like about .astro over .jsx. Take the fact that you don’t need to wrap elements with <Fragment> or <>. That’s certainly neat.
How does all this relate to CSS though? Well, according to the docs, all styles are scoped to a component and you can then opt-in to creating global styles. So within a file called Title.astro, you could write something like this:
<style>
/* Scoped class selector within the component */
h1 {
font-weight: bold;
}
</style>
<h1>I have scoped styles</h1>And that’s it. No importing a ton of dependencies or whatever; Astro does it all for you. I also love that CSS is within the HTML but you don’t have to write weird JavaScript-esque CSS where it’s all CamalCase or any other format than regular ol’ CSS. This, to me, is a huge improvement over all CSS-in-JS things I’ve seen.
But it’s important to note that the styles above will only be applied to the <h1> in that file. If you want to use global styles then you have to opt into them, like this:
<style>
:global(h1) {
font-size: 32px;
}
</style>
<h1>I have global styles</h1>I think this is a smart move. 99% of the time I’m writing CSS I only want to style the component that I’m working on, and so this prevents accidental “leaks” into other files. However! This could easily lead to a ton of styles being made over and over again, as it does today with my experience of using emotion. No system will really save us from ourselves, sadly.
Anyway, ranting aside, I love the direction of Astro for one reason above all these niceties though and this is a completely non-scientific opinion with nothing but a ton of bias from me—but!—JavaScript frameworks always felt as if they took traditional programming and tried to shove HTML and CSS into the, end users be damned (this is an unextremely unfair opinion but it’s how they feel to me). Astro, on the other hand, seems to have learned from all those mistakes and instead takes a good look at HTML and a good look at how we’d like to build things and combines the two without sacrificing one for the other. So you want to use React components and Svelte components and then switch them out for another framework in the future? Go right ahead, Astro doesn’t care at all. It spits out HTML no matter what and then hydrates things when you need more interactivity.
I guess that’s what’s so exciting to me: the philosophy behind Astro, more so than just what it is today.
It’s a hopeful vision of a future web where we’re not limited by past technical decisions and our users aren’t harmed by our neato developer experience.
[Chris]: I am frickin’ stoked about Astro. I took an hour the other day and made a demo site. Look how silly easy it is to grab some remote data to render during the build process. Then I just barf out a quick template and it’s a JavaScript-free experience. To keep the content up-to-date, I’d just run the build like once a day or something. I’ll have to blog about it soon.
How and when to use Async and Defer attributes
This post caught my eye earlier this week when Zell Liew wrote about what happens when you use the async and defer attributes in HTML:
<head>
<script src="defer.js" defer></script>
<script src="async.js" async></script>
</head>Okay, so we’re loading two JavaScript files above but how do those two attributes differ defer. Get it? (Ugh okay, I am extremely sorry about that joke.) But Zell describes defer and async like this:
Both async and defer load scripts without blocking the DOM, but there are two differences between async and defer. Defer waits for the DOM. Async doesn’t.
So most of the time we should use defer if that script requires the DOM. If it doesn’t, we can use async. This is certainly a good reminder because I think I’ve seen folks use async when they mean defer.
What’s new in Safari 15
Chris broke down what’s new in the latest version of Safari:
Perhaps the most noticeable thing there in Safari 15 on iOS is URL bar at the bottom.
What! How dare they do this without consulting me! This is absolutely…
…oh wait, okay. This is actually a big improvement! No longer do we have to stretch our fingers to the top of the screen when hopping around different websites. Also, this sure is neat: you can now set the color of the URL bar via the meta tag and change it when the user has dark mode enabled:
Smart stuff! If you want to check out all the announcements, there’s a 33 minute video over on apple.com about these updates that’s very much worth watching. Jen Simmons walks through all the features and how we can apply them when iOS 15 and macOS Monterey ship.
Sponsor
Gather Virtual Offices
What if you could run into people at the office…while you work remotely? Gather makes it possible. Claim a desk, chat by the water cooler, and hold important meetings in an interactive space. Free up to 25 teammates.
Sponsor
Netlify Deploy Previews
Did you see that Netlify bought FeaturePeek and rolled into into all Deploy Previews? They did! It’s cool! Imagine you need to make a change to a website, and need approval from a client first. You can do a Pull Request against the site and your Netlify-hosted site will give you a URL with a Deploy Preview. They’ve done that forever, and it’s incredibly useful. Now, it’s even more useful, as that client can open up a little UI widget on the Deploy Preview and give feedback. They don’t need to know anything about GitHub, yet their feedback can manifest as a GitHub Issue. And that’s just one possible integration.
[Chris]: I’m going to steal Stefan Judis’ TIL (Today I Learned) for my newsletter shout-out this week. You know you can declare your social media image like this, right?
<meta property="og:image" content="https://.../your-image.jpg"/>Well that’s an image. Like an <img>. But with HTML, we get alternative text: <img alt="description of the image" /> Isn’t it unfortunate that we don’t have an alternate for the social media image? Not so fast, you can declare alt text!
<meta property="og:image:alt" content="Your image alt text"/>
<meta property="twitter:image:alt" content="Your image alt text">And yet, neither Facebook or Twitter do anything with that text. Sad trombone. I’d say it still might be worth using. If enough people use it, maybe the big players will start supporting it. And the world isn’t just Facebook and Twitter. These are just Open Graph things, they could be used by all sorts of things, and I have no doubt some kind of technology is making use of it.
