React Without JavaScript?

Hi. My name is Fred Schott, and this is my talk, Astro, React without JavaScript. This is a talk about language. And I don't mean JavaScript versus PHP versus C++ versus Fortran. What I mean is the language of the mind. And really, the language of how we talk about web development, and how we think about web development, and how that influences what we can build as web developers.

You know, what's seen as easy versus what's seen as hard. What's straightforward versus what's very difficult. What's possible and what's impossible. All comes from the language that we speak about web development.

And to give you an example, what I'm talking about, I want to show a conference talk that I really love. This is probably my favorite talk of the last 20 years. Besides, obviously the infamous what talk, if you haven't seen it, it's a delight. Definitely recommend you giving that a quick Google when the conference is over. But what I want to talk about is this talk. This is Pete Hunt, one of the creators of React, talking about React. And really launching React.

Now, what you need to know about this talk is that it's taking place in 2013. And this is essentially everyone's first time seeing React. And so, the ideas that are being pitched here, you know, in 2020, these are ideas of components and render cycles and how we think about Front End development. It all sounds like exactly what we have come to understand as good best practices. But, to this audience, these concepts are very foreign. This is not an audience that speaks in components and JSX. This is an audience that is traditionally only ever thought in terms of MVC. That's Model View Controller. If you were lucky enough to have missed this part of web development, I will spare you the details. You didn't miss much of anything. But MVC was this idea of separating your code, and separating your concerns in such a way as to bring some clarity and cleanliness to your code base. Separating your concerns was the goal here. And so, when Facebook launched Components, it was essentially this idea of, you know, MVC isn't the answer.

You're separating these things, but you've coupled yourselves in all these different ways. Components is a much better idea. That was the React pitch. And that was met with what I would generally call snark. Snark, I think, is the technical definition for what that reception was like. Because, you know, I think this tweet can probably say it better than I could. The general thinking was that Facebook was throwing away established best practices. And, you know, who were they to do that, right? MVC is the best it will ever be. Who does Facebook think they are challenging the status quo? And to be fair, I'm adding a lot of emphasis that isn't really there in this tweet. As far as Twitter feedback goes, this is pretty polite and straightforward. But the general response was, you know, this isn't how we think about web development. What are you talking about?

It starts to say, no, no, no. React is it's just like MVC, it's the view of MVC. Well, sometimes it's the controller, and sometimes it's the model, and it's really just the view. And I even remember myself thinking, like, oh, it's the view. It's the view. Okay. Cool. Even though to say it's all three is exactly what he's saying. The model makes no sense. Pete, even it works with your stack. It works with backbone, and the developers in the audience go, yeah! Backbone! A technology that we'll keep using forever!

So, this is very much a talk of its time. It is someone thinking about web development the way we think about it today. Almost traveling back in time to 2013 to try to explain this using a language and an architecture that we today see as outdated. And so, this talk today that I'm going to give, I want to do something similar. I want to, and, you know, I'll say we've seen some great talks from other web frameworks today. All amazing projects, Next.js, Gatsby, Remix, Blitz, Redwood, you know, this has been a conference full of different ways to build your site. All great projects. Fantastic stuff. But we're wrapping up the conference, we're kind of at the end, so I want to throw you all a curveball. I want to challenge everyone a bit. I want to present a way to build websites that actually challenges the way that we think about websites. I want to actually challenge the language that we use to describe what is a website today in 2020. And I'm no Pete Hunt. This is not React. I have a little bit more hubris or humility than to say that. But this is a new way of thinking about websites, and we're really excited about what it unlocks. I'm going to borrow a bit from Pete Hunt. Give it five minutes, and I think you're going to like what we've been working on. This talk is a presentation on Astro, which is a way to build faster websites with less client-side JavaScript. And everyone says they're fast.

And everyone says they're fast. Everyone says they're performant. All buzzwords. If you're looking for something a bit more click-baby, Astro is server rendered React components, but better. Got your attention now.

And you might be saying, what are you talking about? The React team has been working on server rendered React components for years. It's incredibly difficult. Suspense, concurrent mode, all of these things are coming together, but it's a huge lift. What are you talking about that you've figured this out? And this is exactly what I'm getting out about language. In some ways of thinking, it's very difficult. With Astro, it's very easy.

So, before we get into the demo, I want to just throw a quick little snippet at you. Astro is all about building your site with Astro files. It's essentially a super set of HTML. This is valid Astro as well. A lot like how JSX is to JavaScript. Astro is to HTML. But this is the foundation of every site. So, you can see this kind of pages index.Astro, that's essentially your index home page of your website that you're building. It's basic HTML as its base. And if you know HTML or even if you know JSX, then you already know Astro. And to build Astro's home page, Astro.build, I essentially threw together some static pages, HTML, threw an SVG on there, and measured it. And got a site so fast, so fast it was unmeasurable on Lighthouse. So, all these frameworks with their perfect score 100s and all green, that's not cool anymore. What I found that's really cool, zeros. Be so fast that you can't be measured. That's the new goal. Gauntlet thrown down. But that's what I want to get out here a bit. Is this idea of HTML.

And really the idea of how Astro compares to other frameworks that exist today. And the way I would frame it is JavaScript applications vs. HTML websites. JavaScript applications are what you're building with most of the frameworks that exist today. That's Next.js, Gatsby, Blitz, Redwood. All of those. They're all about building your site as a JavaScript application. And there's a lot of good reasons to do this.

JavaScript applications are powerful. They're super expressive. You can do data loading, you can do data fetching. You can do routing. And all of these different ways to build a site in a really nice language for power and control. But they're complex. Next.js and all of these frameworks essentially exist to give you different hooks to make your site faster than the traditional here's an entire application to the user, which is the traditional SBA model. So, you can build a JavaScript application and send it to the user. You could use something like Next which will render it on a server. It's all about optimizing that story because performance can be such a challenge. When you built one big application and now you want to ship it to the user on maybe a lower-powered device or a shakier internet connection, that can be really challenging to get right, which is why SSR, SSG, all these different optimizations are really important in the world of JavaScript applications.

And you might say, you know, that's if you think the distinction doesn't really make sense, that's almost what I'm getting at here is that we are so synonymous today with JavaScript applications and websites being the same thing. And there's good reason for that. You know, if you think about what an HTML website is, it's probably something a lot more lower powered. An Eleventy or a Hugo, it's really content focused, markdown, static generation of HTML, is a pretty low powered idea or at least it traditionally has been. What they end up having to do is say, yeah, JavaScript is this kind of other thing that we don't touch. We're HTML. You want to add React, go do it yourself. So Snowpax website, one of the projects I work on, we built that with Eleventy. It's great. It's quick, but the second you need interactivity, you're off setting up your own thing, which we have a Snowpack plugin for. It's great.

It brings a modern DevFlow to a static HTML site, but you definitely feel the sense that you've thrown two tools together. It's not the seamless dev environment that a Next.js would give you.

But that idea of making it difficult to add JavaScript is kind of the gift and the curse of something like Eleventy. When we launched the Snowpack doc site, the new rebuild back in December, I got something that made my whole month, a message from Alex Russell saying I did a good job with performance. Now, if you know Alex Russell on Twitter, this is unheard of. This is a shooting star on the 4th of May. I don't even know what that means. This was big and got me very happy.

As I'm putting this talk together, I see that, well, he didn't say it was that good. He said it pretty fast. For Alex, I'll take it. That's a pretty high praise. What was interesting is he went on to say how did you do this? Obviously, performance, it's so good to see people treating performance so seriously. We were kind of shocked because we hadn't really cared about performance. Not that we were being disrespectful to our users. We built a site and shipped it and it was fast. It was a really kind of cut and dry story. It was interesting because so much of my life has been spent being really careful performance. Here we were building a site that was fast by default. No JavaScript payload, HTML, CSS, and a few SVGs and images. That was it. And so this experience really shaped how we saw web development as a team and what Astro really is, is a chance to try to bring these two different ideas together.

The power of JavaScript, the expressiveness, and the kind of control that you have over what you build, but with the speed of something that's much more HTML first. No JavaScript sent to the client unless you explicitly want it to be. So the performance story of an 11d mixed with the power of a Next.js, that's what Astro is today. So what does that mean? Let's jump into a demo. What you have here is a pretty standard Astro site. You've got some static assets in a public directory and our main building blocks here in an Astro directory, components, layouts which we'll get to, but you'll spend the most time here in pages. These are the pages of your site, essentially a file-based routing system. And we said at the top any Astro file is a super set on top of HTML.

So what we have here is essentially just HTML. Valid HTML, it's pretty static. Let's run this with npm start. That's going to spin up the Astro dev server and you can see this running here in the browser.

Now, we talked about wanting to make HTML more dynamic, kind of give it the power of JavaScript in terms of expressing yourself and what you can do, but keeping that HTML-first document structure in terms of what you're building, the language of what you create. So the way we do that is with something called a frontmatter script. This is really similar to Svelte or Vue if you've used their concept of a single file component. Here we're going to do something similar to start mixing the idea of scripting and markup.

So here we'll just define an idea of a title, and it'll be AstroDemo. We'll get a little exclamation mark for fun. And just like JSX you can combine markup and JavaScript. So here we can use title in the value here, we can use it as an attribute, or we can use it again here as a value of actual content on the page. If we refresh that you see it's updated with a new title exclamation mark and all.

But we want to go further, we want to keep bringing more kind of modern component concepts into how you render this page. So let's actually think in components, let's bring some components into this HTML. We'll bring in two to start. One is something we'll call common head. And I got to spell that right, components.commonhead.astronaut, commonhead.astronaut. And the other is a hero image. Let's get a nice kind of hero image on the page. We'll start with that, we'll just kind of add that here.

And common head is actually going to be a component that that takes care of all of these meta properties. So if you have many sites, many or sorry, many pages on your site, you don't want to keep repeating yourself over and over again, we can use a component like this to bundle up some common head items and tags for you to use across multiple pages. Now common head is interesting in that it actually takes props. So it's an astrofile, it's a snippet of HTML that we're going to inject into the site, but it's going to take the title prop as we'll see in a second. You can see it doing that using again, a Svelte concept of actually defining your props as exported values. So here we've exported title to show that it is a prop. And then we can use that in the snippet of HTML that we're going to inject into your site. So again, really similar concepts to the react and Svelte we're borrowing from a lot of different kind of really good ideas that we've seen in the community before us. Also you might note, if you have a good eye, there is TypeScript in here.

We support TypeScript in your front matter by default. So feel free to mix and match there. Let's save this and refresh the page. And you'll see the hero image also showed up. So we have a actual DOM component that we've reused. Yeah, we could go out and have many, but let's keep it to one, that's respectable.

Now for the rest of this, I'll show a couple more kind of cool snippets. The first one is a Pokedex. What good tech demo doesn't include Pokemon? Now there's a cool, there's a couple of cool things I want to show off in the snippet. The first is that when we say we have this JSX-like syntax, we really mean it. You can see here a full JavaScript expression mixing astro syntax and JavaScript together. So just like the JSX we're used to in React, we are going to use this expression to actually render multiple components on the page. Here, we're going to actually show a Pokemon sprite for the first three Pokemon in the Pokédex. Oh, and we got to use it first. Pokemon lookup. And let's add a little bit of display flex just to get those all on the page. Look at that.

So if you don't know Pokemon, the whole idea of a Pokédex, none of that's important. We're just what we're doing here is having some fun with Pokemon and generating three little sprites here, three little images. What's cool about this component though, is that we're actually bringing in the idea of data fetching. So we don't ship with every Pokemon known to man. We actually have data fetching here, actually fetching at build time and making an API call. Not only do we have that support via fetch, but we also have top level await. So the idea of this ever affecting the user, it's fully build time. You get to use top level await as a part of your server rendering and the user never sees it. So there's not really a huge user performance concern here because this all gets rendered to static HTML at the end of the day. We can see that in the network panel here. I'll refresh and no JavaScript on the page, all static HTML. So that's a really cool idea of how you can express yourself with the server HTML based language called Astro in ways that are, you'd be much more limited to if you're using a front end framework like React or Svelte where you can't just throw a top level await in because a user would see it. In this world, we're fully server rendered.

So we don't actually have those concerns. We're a little more free to express ourselves in this way without the boilerplate.

I'll grab one more little demo snippet to show off here. And that is this idea of giving away the fun part, an emoji picker. This is not just any emoji picker. Let's add our import up here. You might have seen this in the components directory if you were looking for it. This is not an Astra file. This is a JSX file. This is a React component.

I said at the top in the talk, right, we have done server rendered components. What does that mean? That means we're letting you use React in your Astra application. We have here a React component. It's using another npm package. It's using some CSS. And this is all generating server side markup. We're going to render this component server side. Here we have three of them. Let's refresh the page. And look at that. We have just mixed. Actually, I'll do that. So, you can see yourself. We've just mixed Astro as an HTML language and React as a JavaScript framework. But we rendered them all server side. All generating HTML at the end of the day. So, you can do this with any framework. It's React Summit. We'll use React. But Preact is also supported.

Anything that renders to HTML can be used on the server this way. The user sees no JavaScript in their final payload.

Now, some things you actually might want to be dynamic. For example, these are meant to be clickable. And we have them generating random emoji, but nothing happens when I click. So, it's this idea of you actually want some functionality. We're not saying get rid of all JavaScript on the page. But the stance that we take is that interactivity in JavaScript should be opt in, not at a site level or a page level, but at a component by component level.

So, what we have here is the idea of taking a component written in a framework like React or pre-actors. And actually adding a modifier here to promote it to the client. Let's say we'll do idle here. What this does is actually generates not just the placeholder, but actual, you'll see here, code to hydrate this component on the page. So, now we actually have a fully interactive component. All working on the client. And you'll see here in the network panel, an actual networks trace, which shows like this actually loading. It's actually running on the browser. This is dev. So, we're being a little more aggressive in the Javascript we send in production. This would be bundled and minimized and tree shaken.

Another cool thing here is the idea of visible. If you spell it right, visible. And this actually, I'll do it here. As you scroll down, it'll only be when you get to the actual component that it takes that cost and actually hydrates those components. So, if something's below the fold, you would actually never even pay the price to load that until you actually interact with it and see it on your screen. There's a ton more cool stuff like this in Astro that I just don't have time to show you. We haven't even gotten to mark down how scope styling works by default. All of this stuff is about helping you build a site that is as little JavaScript and as little kind of weight that has to get sent to the user as possible. The superpower of Astro is something called partial hydration. This is that ability you saw to mix static HTML and client-side JavaScript on a component-by-component basis. So by default, everything you build with Astro is 100% HTML.

Zero client-side JavaScript by default. But you then have the ability to optionally go in and hydrate individual components that need them. So some sort of image carousel or something with interactivity, maybe client-side data fetching. You can opt into that on a component-by-component level.

This is something that we get for free because we've actually changed the way we think about what you're building. It's not one big JavaScript application that you build with Astro, you're actually building a website, a website that follows something called islands architecture.

So this was a term coined by Jason Miller of Preact and Google fame. And it's all about thinking of your website not as one big application, but as a series of components on the page, some of them statically rendered zero client side weight, but others can then be hydrated individually almost as isolated islands from each other.

So instead of one big application, you have many small, almost mini applications, mini React components rendering individually and isolated from each other. So not blocking each other, smaller components kinda hydrate themselves much faster, while maybe a slower larger one takes a little bit. They're all isolated from each other and hydrate as progressively as they load.

This is something that we get for free by thinking in this way. This idea of islands and components and an actual HTML-first output. That's the superpower of Astro.

So to recap, Astro is a modern way to build faster websites. By default, everything you build with Astro serves zero client-side JavaScript by default. Everything is HTML-based and HTML-focused, but with the ability to opt-in to different components for client-side rendering. So you can use React on the server, you can use it on the client, you can do both. You can mix it into your markdown. You can do all these things on a component-by-component basis that are really difficult to do in other frameworks.

And that idea of opting into individual components for hydration instead of sending down an entire application, that is a superpower of partial hydration that is at the backbone of what Astro is all about.

So one of the downsides of recording this talk so much farther in advance is I actually don't know what the state of this project will be when you watch this video. I can't commit to anything right now but what I will say is check out astro.build for an early preview of what we're working on. We can't wait to get this out into your hands and to see what you build with this new way to build websites using partial hydration and react components on the server. Hope you've enjoyed this talk.