Check out a free preview of the full Astro for Fast Website Development course

The "Astro Adoption" Lesson is part of the full, Astro for Fast Website Development course featured in this preview video. Here's what you'd learn in this lesson:

Jason highlights the advantages of adopting Astro, which encompass a content-focused approach, streamlined maintenance, and decreased bundle sizes. This section also includes instances of websites that have utilized the Astro framework.


Transcript from the "Astro Adoption" Lesson

>> And I think the biggest piece of this and one of the things that is nearest and dearest to my heart is most of what we're doing is not complex and now that is not to say that the work we're doing isn't challenging it's not to say that it's not important or that it's not hardly it's not easy right but it's not complex we're not building multiple updates per second hundreds of thousands or millions of concurrent users like the vast majority of us are just trying to get information on to a website.

And that website is updating, I don't know, maybe once an hour, maybe a couple times an hour on a really active site, because it just, that's just the nature of the internet. Most of what we're doing is informational. Most of what we're doing is we're allowing people to perform a task.

And the vast majority of websites, even really busy websites, aren't seeing the type of scale. That a lot of these frameworks have been built for when you start looking at what next or react or some of these frameworks are built to handle, they're built to handle the scale of Facebook.

They're built to handle the scale of a site like Airbnb, where the things that are happening are extraordinarily high volume, extraordinarily high complexity, and realistically speaking, if you think about the websites you visit on a day-to-day basis, the websites that we work on, most of them aren't that most of what we use is not Facebook or Twitter or Airbnb or similar types of sites.

It's usually something that's more like, I need some information. I need a list of products. I need to see what my shopping card is doing. And each of those things is, it's not easy to build, but it's not the level of complexity that that seems necessary to manage alike multi-user real time feed or something like that, right?

So we get told that we need these these big frameworks with lots and lots of power and you know, the ability to instantly invalidate things or the ability to control your cache or to do all of this stuff, and we just don't it's it's a lot of kinda voluntary suffering to pick up caching manually to pick up managing servers manually.

If you're not actually using those features for a business critical thing if you're opting into that, because somebody told you that maybe you'll need it someday. If you grow to Twitter scale you can do that there is no wrong choice in tech they are just trade offs. Right?

And so what I like about Astro is that it's going at it the other way. Where frameworks like Next and Remix and stuff, they're thinking about, like, how does this thing become big and very complicated and very interactive, what Astro is saying is, it's probably gonna start simple. And it's gonna scale, and it's gonna get complex. But you should do that like on a per page or even on a per component level, not necessarily up your entire website into this very complex, hard to manage framework that is gonna have things like pagerduty, that's gonna have things like Running servers and caches that you have to now think about and maintain.Whereas Astro's like just put it on a CDN.

You'll know when it's time to no longer use the CDN, but it probably won't be as soon as you might suspect, because again, we kind of get sold this idea that we need all of this complexity and all this power. But we just don't, in the vast majority of websites.

>> Yeah people are just kinda debating in chat around the adoption of astro and I pointed to the astro showcase, but maybe you could talk about how either you're using it or companies are using it.
>> So there's the fairly standard this is a listing of the things that happen on learn with Jason.

So I've got these are dynamic in the sense that they update whenever my schedule updates, but those are once per day not per second or anything like that. These are pulled from YouTube at build time again, these update once per day probably a few times per week same with these and then I have a list of episodes that list of episodes is everything that I've ever made this is I think where am I at three almost 350 episodes of the show I've got the schedule of everything that's coming up and then I also run a blog I've got a newsletter capture.

And then a few really dynamic pieces like we've got fuzzy search so if you wanna find stuff about Astro you can jump through and find a video on Astro right and this is powered by Algolia and so this is a like partially hydrated section of the website that runs this command K overlay

>> So do you have it set up where Netlify builds every night or something.
>> Netlify builds whenever I make a change and so I just have webhooks built so that if I update my CMS Netlify knows to rebuild, whenever I change the YouTube stuff, that one I haven't bothered to set up a webhook for because I build the site often enough anyways, that it kinda doesn't matter, but yeah, all of this is run, the episodes in the schedule are powered by, Sanity CMS and that has web hooks.

So, whenever I make a change, Astro is aware of it because of Netlify and that rebuilds the, the site. Astro itself is being used by a lot of different websites It's still pretty early. So take like take a lot of what I'm saying with a grain of salt like Astro is still a relatively new coming framework.

And this idea of partial hydration is solid, but not thoroughly battle tested on every particular use case. So use your judgment and and you like my goal today is not to tell you that you should use Astro for everything. My goal is to give you another tool in your toolbox, so that as you're looking at projects that you need to build, you're able to say this doesn't seem as complex as would be as would merit like a next JS build.

Let's put this thing on Astro. And a lot of times you can, and what I wanna show you today is actually how far you can take Astro so that, where that window of this is complex enough to use something else. It's actually further away than I think a lot of us might suspect.

But yeah, there are a lot of sites on here.The Firebase website is running on it. Everybody's welcome to dig through these and see what they can find. But in the grand scheme of things, in the grand scheme of the web, a fun stat that I found that kinda blew my mind, I was thinking, I'm on Twitter, and I spend a lot of time on Twitter talking about tech and listening to people talk about what they're excited about, what the standards are, what you should and shouldn't be building with.

And because I've spent so much time in that bubble. I was convinced that React had a chokehold on the industry and that everybody was building in React and so many websites were in React. And so I went and I looked at it. There's this website called W3Techs and it keeps track of what they can measure from millions of websites, right?

And so if you start digging in to how many websites use React. This is giant JavaScript here's react React is being used by roughly 3% of all websites on the internet and that is not by no means a small number like 3% of the Internet is a huge number of websites but to listen to the bubble of tech discourse, you would think that this number was significantly higher, right?

And also, the way that I hear people talk about things like jQuery, it sounds like it's dead. It sounds like nobody uses it. But look at this. Almost every website, that is shipped with JavaScript is running jQuery today, right? This is these are relatively recent stats. I think they update weekly or something.

So if three out of four websites on the internet is shipping jQuery, and three out of 100 websites is shipping React the use cases that we think we need React for. They're just not as prevalent as we think. Right? And so reaching for these frameworks as a default, it can get us into maintenance trouble later down the road.

And for me, the biggest thing that we're after here is I want to spend my time building things, not maintaining things. I don't ever want to get paged because the marketing site is down. I don't ever, actually, I don't ever wanna get paged ever. So if I can build every single part of the website in a way that doesn't go down and like, if you want to go for never get page ship HTML and CSS to a CDN, it will not go down.

CDNs are about the last thing in the technology chain that's gonna get taken down. And if the CDN goes down, nobody's worried about your website, the whole internet is down. So yeah, like I said, I want to build stuff, not maintain it. And I think that one of the reasons that Astro is attractive to me is that it defaults toward the thing that has the least number of moving parts.

I don't want to have to think about whether or not my serverless functions are speaking to my cache properly or speaking to whatever other piece. I don't wanna be maintaining a server. I had to ship a server for a server full framework and for the first time in my last decade of work was getting emails about your server is out of memory.

Your server crashed and was restarted. And I just I was like, My God, I forgot that these problems existed because I'd been shipping static websites and not having to deal with these problems. So what part of the problem that I think we have is that a lot of us just either never had to do it or have forgotten how much work it was to keep servers up and running.

And so seeing everybody moving towards servers as a default freaks me out. Again, there is no such thing as a wrong choice, there's just trade-offs. And I personally I'm not willing to accept the trade-off of running a server unless there is no other option, and the way I see it in the vast majority of cases, there are other options and you can ship something much simpler that takes a lot less maintenance and is easier to deploy and keep healthy question.

>> So would it be accurate to characterize Astro as content oriented versus app oriented?
>> I think that is what has been most proven out right now, is that Astro is very, very good for content oriented. That being said, most apps are single page apps. Like if you look at the dominance of the 3.3% of websites on the internet that are running React, most of them are running create React app.

So it's mostly single page apps that are just mounted into HTML. And if you wanna do that on Astro, you absolutely can because Astro under the hood is running Vite. So if you wanna build a page on your Astro site that has a div that mounts a single page app that runs React router.

And has your whole dashboard on it. You can absolutely do that. And I've seen that done is like, is it gonna give you server rendering? It can we'll talk about how Astra does server rendering if you if you wanna opt into that. But for the vast majority of use cases, we're seeing that single page apps are the way that that the internet gets built.

Despite claims to the contrary, like server rendering is the exception, not the rule. And I think that we've, again, tech Twitter is a is a big bubble and Hacker News. And these these websites are very, very aggressively telling us that things are this way and they must be this way and I just, I'm not here to tell you that anything must be anyway, I'm trying to remind everybody that there are a lot of tools and this is a big spectrum.

And you wanna pick a tool that's actually solving the problem you have, you know, like, sure you can go and get a pneumatic drill and use that to put in one painting. But why? Like it's a lot of setup and maintenance to keep a pneumatic drill running when all you need is one hole.

All right so just get the hammer get the screwdriver like it's gonna be okay you don't need the big complex many moving parts thing. I really like the developer experience of modern JavaScript I really really like building component based websites I love the portability of being able to build with React or Solid or Svelte and Vue is wonderful to work with.

So all of these have amazing perks of how it is to work with them the improvements they have over manually rolling your own JavaScript or writing HTML templates and copy pasting the headers and footers around The problem is that all of them come with JavaScript trade offs. You get these big bundle sizes of, it's 30 something kilobytes for React these days, and that's before you add any of your app code.

And again, when you're running it like that, the whole page has to be hydrated as JavaScript. And so when the whole page has to be hydrated to JavaScript, and that means that people need to be able to run it without JavaScript, but it won't work. So then you have to reach for server rendering.

So this is again, like some of this stuff is like we're solving problems that we created for ourselves that we could have solved by going the other way. And I think that Astro is going the other way. It's saying, you don't need server rendering. Just build with the DX that's great.

And ship the thing that works best for the vast majority of use cases. And only add complexity when it's necessary. And I think that leads me to like my biggest takeaway which is Astro is the right kind of boring. I desperately want to be bored at work. The last thing I want to use my energy my excitement for is putting out a fire at work.

I want to cook over fires. I don't wanna put out fires Right. I want all of my energy left to hang out with my friends and family to do my hobbies to work on projects that are fun for me. I don't want to ship some complicated thing into production and then find out that is down on a Saturday night.

Now I get to leave the barbecue to go do something for work. That is never how I wanna spend my time. So I want my tech to be boring. And I want it to be boring in the way that after I've shipped it if I forget to look at it for the rest of my life it will continue to be on the internet and HTML and CSS on a CDN will continue to function probably until the heat death of the universe judging by the way that We've handled web standards.

So far, the web is very, very good at maintaining backward compatibility. The JavaScript ecosystem is less so. So if you're betting on something that takes the least amount of your time after you build it, go for the things that don't have moving parts go for the things that don't rely on changing standards that are very fast.

Look for something that is just gonna set and forget for the rest of time.Maintenance should be because you've got a new feature to add or because you've, you wanna go overhaul that page, not because it's broken or because it's down or because the major version change and now you've got to rewrite the whole thing to match whatever the breaking changes.

We're in version four. Right?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now