Server Side Rendering with Nick Taylor

Episode Description

Nick Taylor joins Anthony Campolo to explain server-side rendering, compare it with static site generation, and live-code an Astro project with Preact islands.

Episode Summary

Anthony Campolo welcomes Nick Taylor from Netlify to discuss server-side rendering and how it fits into the modern web development landscape. The conversation traces the history of web rendering from traditional server-rendered pages through the Ajax era, single-page applications, and the current swing back toward server-first approaches. Nick explains why SSR matters for SEO, performance, and handling large-scale content sites, using examples like news archives and scientific documentation to illustrate when static site generation breaks down. They explore concepts like streaming SSR, hybrid rendering strategies, and the "spiral" metaphor for how web architecture is evolving rather than simply reverting to old patterns. The discussion highlights how serverless infrastructure has made SSR more accessible and affordable. The pair then transitions into a live-coding session where they scaffold an Astro project, configure it for Netlify deployment, and demonstrate islands architecture by building a Preact component with client-side interactivity. Using the Node.js debugger, Nick proves the page is genuinely server-rendered by pausing execution mid-render. They wrap up by celebrating the cooperative spirit among modern frameworks and the strength of open-source communities.

Chapters

00:00:24 - Introductions and Nick's Background

Anthony welcomes Nick Taylor to the fourth episode of AJC and the Web Devs, and the two share some lighthearted banter about Nick's online handle, "Nicky T Online," which originated from his rugby days in Montreal. Nick explains how the nickname stuck and became his consistent identity across platforms.

Nick then describes his career trajectory, having been a professional developer since 2002 across industries including .NET shops and Dev.to. He now works at Netlify on the ecosystem and frameworks team, where he deals with SSR, SSG, client-side rendering, and a wide range of frameworks including Gatsby, Remix, Astro, Next.js, and Fresh. He describes the role as sitting at a unique intersection — not quite frontend, not quite backend, but something in between.

00:04:18 - Understanding SSR vs. SSG

Anthony shares his own learning journey, explaining how he first understood web deployment through static site generators and Create React App before encountering server-side rendering as a concept. He found the distinction between SSR and SSG confusing at first and asks Nick to clarify the difference and the historical context.

Nick walks through the evolution of web rendering, from early days when servers delivered complete HTML pages over slow modem connections, through the Ajax revolution that enabled partial page updates, to the rise of single-page applications. He explains that SPAs shifted most rendering work to the client, which worked well for highly interactive apps like Figma but was overkill for content-heavy sites like Dev.to, which runs on Ruby on Rails and relies on traditional server rendering.

00:12:13 - The Pendulum Swings Back to SSR

Anthony and Nick discuss the industry's renewed interest in server-side rendering and multi-page applications. They note the irony of coining new terms like "MPA" and "serverful" for patterns that predate SPAs. Nick references a colleague from the Remix team who described the trend not as a pendulum but as a spiral, gradually converging on a balanced approach between thin and fat clients.

The conversation turns to how serverless infrastructure has enabled this shift by making SSR cheaper and easier to manage. They discuss the appeal of monolithic development experiences without monolithic architectural drawbacks, with Anthony referencing the "full-stack Jamstack" concept and Redwood's composable approach. Nick coins the phrase "composable monolith," and chat participants chime in with observations about the new architecture resembling a redefined monolith.

00:17:29 - When SSR Beats SSG

Anthony poses a pointed question: if Astro targets content sites, why would it need SSR instead of just SSG? Nick explains that large content archives — like a newspaper with decades of articles — would produce impractical build times if statically generated. A hybrid approach pre-generates recent content while server-rendering older pages on demand, then caching them.

They discuss additional scenarios where SSR shines, including dynamic content that changes frequently, error handling advantages of build-time generation, and Google search results as an example of content that could never be statically generated. Nick also introduces streaming SSR as a solution for extremely large payloads, sharing an anecdote about a researcher loading 50 megabytes of scientific documentation where streaming allowed users to start reading before the page fully loaded.

00:25:16 - Streaming, Caching, and Framework Support

Nick and Anthony explore how streaming SSR works across different frameworks and deployment platforms, noting that both the framework and the hosting provider need to support it. Nick mentions that Netlify offers streaming SSR on edge functions and references a Builder.io article evaluating whether streaming is worthwhile.

The discussion shifts to caching strategies, particularly how Remix uses standard browser cache headers to get SSR performance benefits without regenerating pages unnecessarily. They touch on how frameworks like Astro abstract away caching configuration to keep developers productive, and Nick briefly shares his background in ASP.NET, drawing connections between C# and TypeScript through their shared creator, Anders Hejlsberg. Anthony likens cross-language influence to musical genres borrowing from each other.

00:30:27 - Islands Architecture Explained

Nick introduces islands architecture, a pattern coined by Katie Sylor-Miller and popularized by Jason Miller's writing. He drops several resource links and explains the concept using the metaphor of an ocean representing a web page, with islands representing isolated pockets of client-side interactivity that only load the JavaScript they need.

Anthony shares his own experience building a framework called Slinkity with Ben Holmes that explored similar ideas. They discuss how islands differ from traditional SPAs where megabytes of unused JavaScript get loaded. Nick highlights that islands combined with SSR deliver fast initial page loads with targeted interactivity, and Anthony adds the "sprinkles of JavaScript" analogy from the Rails community, contrasting it with the modern tendency to dump entire buckets of JavaScript onto pages.

00:35:54 - Live Coding: Setting Up Astro with Netlify

The pair begins a live-coding session, scaffolding a new Astro project and configuring it for Netlify deployment. Nick walks Anthony through adding the Netlify adapter using the Astro CLI, which automatically sets the project to server output mode. They discuss how the adapter's presence implies SSR since pure SSG projects just generate static files without needing one.

Anthony shares his custom GitHub CLI command for initializing repositories, and they examine the Astro config file with its server output and adapter settings. They also briefly discuss TypeScript configuration options in Astro and how to gradually tighten type strictness during migration projects. Viewers in the chat, including Astro team member Fuzzy Bear, provide additional context about how adapters work.

00:43:15 - Proving SSR with the Node.js Debugger

Nick demonstrates that the Astro page is genuinely server-side rendered by using the VS Code JavaScript Debug Terminal. He guides Anthony through adding a debugger statement in the Astro file's frontmatter, which pauses execution mid-render and leaves the browser hanging on a white screen — proof that the server is building the page before sending it.

They explore the compiled output of the Astro file, examining the transpiled JavaScript and discussing source maps. Nick shows how the Astro object contains request metadata like cookies, params, and URLs, which Anthony finds useful for understanding how his blog generates canonical URLs. The exercise serves as both an SSR demonstration and an introduction to Node.js debugging for viewers who rely solely on console logging.

00:54:07 - Building Interactive Preact Islands

After demonstrating the debugger, Anthony impulsively deploys the site to Netlify. They then add Preact as an Astro integration, creating two components: a simple Hello component and an interactive Island component with a button. Initially the button doesn't work because it lacks a client directive — Nick uses this to demonstrate how Astro's directives like client:load and client:visible control when JavaScript hydrates each island.

Once the client:load directive is added, the button becomes interactive. They inspect the page source to reveal the <astro-island> custom element wrapper, which contains metadata mapping the component to its source file and managing hydration. Nick contrasts this approach with React's hydration model, where the entire component tree re-renders client-side to verify server markup, whereas Astro simply attaches interactivity to pre-rendered HTML.

01:11:02 - Framework Philosophy and Closing Thoughts

Anthony and Nick reflect on Astro's approachability, with Nick emphasizing he went from zero to productive in just a day and a half. Anthony shares his journey of trying seven different frameworks before settling on Astro for his blog. They praise Astro's philosophy of supporting any component framework rather than forcing developers into a single choice, comparing it to Netlify's platform-agnostic approach.

The conversation closes with appreciation for the cooperative spirit in the web development community. Nick shares a story about Preact creator Jason Miller voluntarily helping debug an issue in a pull request, illustrating how open-source maintainers go above and beyond. Both hosts encourage viewers to engage with framework communities on Discord and Twitter, emphasizing that modern tooling and supportive communities make it the best time to be a web developer.

Transcript

00:00:24 - Anthony Campolo

Hello everyone. Welcome back to AJC and the Web Devs. This is episode four, and we've got Nick Taylor with us. How's it going, Nick?

00:00:33 - Nick Taylor

Pretty good. How are you doing, Anthony?

00:00:36 - Anthony Campolo

Doing good. I always call you Nicky T from Jersey, Canada, because you would be from Jersey. But you're not from Jersey. You're from an entirely different country.

00:00:47 - Nick Taylor

Yeah. No. I'm from Montreal in Quebec, Canada. East Coast represent. The origin story of my handle isn't really that exciting, but I use Nicky T online.

When I used to play rugby, it was common to call you by your last name. People would say, "Hey, Taylor, pass me the ball," and sometimes they'd just call me Nicky T for short. It's easy to say. Then I created a terrible handle called Nicky T online because you're online if you're on the internet. It's a terrible name, but I stuck with it, and here we are today.

00:01:32 - Anthony Campolo

Yeah. It sounds like you've been able to hang on to that handle across most channels. That's the main thing. I think it doesn't really matter what your handle is as long as it's unique.

00:01:41 - Nick Taylor

Yeah, exactly. It is unique and, like you said, consistent everywhere. It'd be cool if I could have Nick or something, but unless I registered all these services when they literally just started, it's not happening. So I think I'll still sleep well at night.

00:01:59 - Anthony Campolo

Awesome. Well, thank you so much for being here. We've had a bit of a hiatus from AJC and the Web Devs, but we're back now and I'm really, really stoked to dig back into this stuff.

You're going to be talking a little bit about SSR here. I proposed this topic to you because I know that you are working a decent amount on this type of stuff at your place of work, Netlify. Why don't you let our listeners or viewers know what you do and where you're coming from?

00:02:30 - Nick Taylor

Yeah, for sure. I've worked in several industries over the years. I've been in the industry for a while, professionally since 2002. My latest role is at Netlify. I work on the ecosystem stuff there, specifically frameworks.

So basically anything frameworks-related, and that includes SSR, client-side rendering, SSG, static site generation, and all kinds of stuff. Then a ton of frameworks like Gatsby, Remix, Astro, Next.js, and a whole bunch of new frameworks too, like Fresh coming out of the Deno folks. There's a new generation of frameworks that are kind of like HTML-first, which ties into the server-side rendering story. So, yeah, I like it.

[00:03:32] It's a lot to take in sometimes because for anybody that tries to drink from the firehose that is JavaScript land, it can be pretty intense. I just think it's pretty cool that I can work with all these frameworks or enable them in terms of working on Netlify.

I think it's pretty cool. I was a lead front end when I was working at Dev.to, and I worked in .NET years before that. So this isn't really back end. It's not really front end. It's kind of like middle end of the build step, almost like plugin stuff for your build. It's really interesting work and challenging for sure, but cool stuff.

00:04:18 - Anthony Campolo

Yeah. This is why the whole topic of SSR has been really interesting to me, because I'm someone who, when I originally learned web dev, the first thing I kind of understood as a way to build and deploy sites was with static site generators.

Even if you're using Create React App, if you're doing it just with a build command, you're basically creating a static site at the end of the day. You do a build, you have some sort of public directory, and you plug that into a Netlify or something, and it would just do it. For a while I was like, okay, I have this project, I plug it into Netlify and then it deploys and I have a project, and I didn't have any concept of what was happening at all.

[00:05:12] Then at a certain point, I understood that it was going through this transformation and building a bunch of static assets, sticking that on a CDN, and that's the project. So that made sense to me. Then I started learning about static site generators. The mental model was very clean. It was very clear.

At a certain point I started hearing about SSR, and I heard there's SSR and SSR is different from SSG. So it's server-side rendering, and I didn't really understand what that meant or what server-side rendering was. It was very confusing to me.

It's funny because you say this used to be just the way we made websites, that you'd have some sort of back-end server that would get a request, build a bunch of HTML, and serve that HTML up to the user. That mental model didn't quite click in my head. I didn't really understand what this meant, why I would want that, or how it was different from SSG. It took me a really long time to wrap my head around it.

[00:06:04] So can you talk a little bit about that? What is server-side rendering, and how does it relate to static site generation?

00:06:13 - Nick Taylor

Yeah, for sure. If you go back to when the internet started, if you went to a page, it would pull down the whole page. Hey, what's going on, B1 Mine? Hey, Ben. If you wanted to visit a website, you'd go to something like Coca-Cola.com and it would pull down the whole page.

It depends when you started doing web development. Over the last five years, a lot of people got introduced to static site generation and stuff like Create React App.

[00:07:09] So you have this index.html that ends up getting deployed to Netlify, Cloudflare, Vercel, wherever. Then all of a sudden you're loading this whole thing. It's like this empty page, and then it just kind of blows up with your content. That's not how a lot of sites used to work, and there's still a lot of sites that don't work like that.

There are a lot of reasons. We won't dive into too much, but SEO, search engine optimization, getting hits on your page, and Google being able to crawl it. This is super important for e-commerce stuff and just having your page found. I know Google does crawl JavaScript to see what's going on in pages now. But the main point was also the hardware back in the day.

[00:08:04] I worked at a place where there was literally a server in the other room, and that's where our website was running. There was no serverless yet. I can't remember when serverless started becoming a thing. It's early 2010s, I believe.

00:08:20 - Anthony Campolo

What we think of as serverless usually starts with Lambda, which is like 2014, 2015 kind of era. And what's funny is that if you use serverless, you can server-side render with serverless.

00:08:35 - Nick Taylor

That's the other thing. You can definitely do server-side rendering in serverless too, because the name serverless is always misleading. You still have a server.

00:08:48 - Anthony Campolo

It's like wireless. Wireless has wires. It's just in a different part of the chain.

00:08:56 - Nick Taylor

So the main difference is that with traditional servers, the server is always running. To some degree the server is always running in serverless too because it's providing stuff for more than you, but basically serverless is when you need it, it's going to spin up and run.

That's kind of the very high-level main difference between that and a traditional web server that's just always running. In both scenarios you can definitely server-side render the stuff. That literally means generate the whole page or a majority of a web page that you're viewing.

Once we get into some live coding, we can show this in the dev tools and stuff. When the tech first came out, like when I was in high school, broadband internet didn't exist yet. I was on a modem. Feel free to Google it if you don't know what I'm talking about, but it was like a 14.4 baud modem, which was very slow.

[00:10:03] You're on a landline. You can't use the phone, and it's a super slow connection. Your page would be loading and it would be like chunk, chunk, chunk, chunk. Then broadband came in, I think late or mid-90s, so you got faster internet. But people were still complaining about pages loading slowly sometimes.

Then this whole new thing popped up called Ajax, asynchronous JavaScript and XML, which nowadays people just say you're making fetch calls or whatever. Back in the day it didn't return JSON. It actually returned XML for your data. It changed over time, but the name stuck for a long time, and I still call it that.

So then there was this thing like, okay, let's load part of the page so it loads fast, and then we'll use Ajax or fetch calls to pull in things that we need as we go along.

[00:11:04] That kind of evolved into single-page applications, SPAs, where it was like, okay, let's still load a shell, but it was a very minimal shell in a lot of cases, and then just literally load everything on the client side.

Things were like that for quite a while. Not everything, obviously, but a lot of people, like when I started doing React, that's what I was doing. I was doing single-page applications. I think there's still value in certain scenarios, but it's not necessarily everything.

If you're like a Figma app, which I'm sure some folks are familiar with, there's a lot of client interactivity in there. So something like a single-page application makes sense there. But when I was working at Dev.to, which is a programming community, it's a heavily content-based site.

[00:11:57] You know, you don't need that.

00:11:59 - Anthony Campolo

It runs on Ruby on Rails, right?

00:12:01 - Nick Taylor

Yeah. That's the other thing that we're kind of not talking about right now. We're talking about JavaScript pretty much on the stream, probably. But a lot of frameworks out there aren't JavaScript and they do the server-side rendering.

00:12:13 - Anthony Campolo

So things like Django or Rails or even Laravel, most of that stuff is set up to serve up HTML, and that's kind of always been standard. Now we've moved to this area where we have more heavy JavaScript-based applications for spots and things like that.

But I think within the last year or two, we're now seeing the pendulum swing back to more server-side rendering. Now they're calling them MPAs, multi-page application, which is just what it used to be. You have multiple pages.

00:12:50 - Nick Taylor

We're creating names for stuff that already existed. Like you said, MPA, a multi-page application, is literally what websites were before single-page applications existed. But because we created single-page applications, we had to give a name to websites.

00:13:05 - Anthony Campolo

People also call it using a server. Now they call it serverful instead of serverless.

00:13:10 - Nick Taylor

Yeah.

00:13:10 - Anthony Campolo

It's like, well, it should be server more, actually.

00:13:14 - Nick Taylor

Yeah, I think you're the one that said that. I heard server more somewhere too.

There's this shift. There's still single-page applications going on, but there's this shift coming back to server-side rendering. You're seeing a lot of this too with edge computing, where all these HTML-first frameworks are popping up.

The thing is, Chad Strickland, who's on the Remix team, said something along these lines. I said what you said before, which is we're kind of coming full circle and we're going back to the way things were. I'm paraphrasing, but he pretty much says that.

When things first started off, you had a thin client and the server did all the things. Then when we got into SPAs, that's when it was like the server was thin and you had a fat client where most of the work was being done there. But now we're, it's not so much the pendulum.

[00:14:10] I like the way Chan said it. He said it's more like we're going in a spiral, and we're kind of getting closer to where, at some point, it's going to be the sweet spot where it just makes sense.

Going back to the serverless part, I think the whole serverless movement, or not movement but the technology, has enabled a lot of people to do this stuff a lot cheaper too. You could still have shared hosting, which wasn't that great, but that's one way you could share, and you'd pay like six bucks a month. This is like early 2000s, but now that serverless is available, especially on platforms like Netlify, Cloudflare, Vercel, and all that, it's just so easy to do these things.

[00:15:02] You don't even have to manage the server. It enables us to come back, and this kind of ties into what I was saying about the spiral. Chan was saying spiral in a good way, not a downward spiral. Taos in the chat is saying, "Yeah, I thought about this the other day and we're just defining a new architecture for monolith."

00:15:25 - Anthony Campolo

Yeah. I think this is actually a good thing. There were a lot of things people liked about the monolith, and there were a lot of good productivity wins we got from the monolith.

Once we went away from the monolith into something more distributed, something more like microservice-based or just decoupled, as you know, the Jamstack is all about decoupling. You get benefits from that as well, but you also lose this really nice kind of having your whole project in one area.

People who know me know that I'm very big on the full-stack Jamstack. A lot of that was about how do we get back to the niceties of the monolith without necessarily bringing back the downsides. So I think aiming for a monolith, a monolithic-like development experience without the architectural pitfalls of the monolith, is something that we can all aim toward.

Most people agree that's a nice workflow as long as you don't have the actual pitfalls of a monolithic architecture.

00:16:27 - Nick Taylor

Yeah, it sounds contradictory, but I almost feel like saying composable monolith.

00:16:33 - Anthony Campolo

Yeah. That's exactly the idea of Redwood. It's basically like a monolith, but it's not.

00:16:41 - Nick Taylor

Yeah, exactly. I think the technology is in a great place now too, because there are still people that don't have amazing internet, but serverless and everything is just kind of enabling us.

We're in a good space now where we can come back to these things. Again, it's not for everything, but I'm going to be paraphrasing again here. I don't know if it was Fred K. Schott from Astro. It's on the Astro blog. They aren't trying to target every kind of web application, but I think he said something along the lines of their niche is what 60% of the web is, which is content, you know, content. Or maybe I said it wrong.

00:17:29 - Anthony Campolo

No, you're right. I want to dig into this because this is exactly what they've said, that Astro is aiming towards content sites, which are things like blogs or documentation or front pages.

00:17:44 - Nick Taylor

Yeah.

00:17:46 - Anthony Campolo

If that's what you're aiming for, why do you need SSR and not SSG? To me, if you're creating content, you shouldn't necessarily need a server at all. So I find that to be really interesting that they're saying we're for content, but at the same time they're saying we want SSR. How do you square that?

00:18:07 - Nick Taylor

Yeah, no, it's a great question. It depends, which is the classic answer. For example, say you're some really large newspaper that has their online presence, like the New York Times or something. Say whoever was architecting that was like, yeah, we're going to go SSG, we're going to auto-generate all the pages.

If you think about that, depending on how long the newspaper has been around, they probably have archive pages going all the way to the 1970s, maybe before that. Realistically, you don't want to auto-generate at build time potentially millions of pages because your build time is just going to tank and might never even finish.

This is where a hybrid approach can be interesting. You pre-generate maybe this month's articles or this week's articles. As people go to, say, "Hey, I want to read that page," that's when that first request gets made and that's when it'll server-side render.

[00:19:18] Then it'll get cached somehow using regular web dev, like caching headers and stuff. That's where a hybrid approach makes sense. You could say, okay, that's this thing. That's how Smashing is doing it.

I agree with you. When do you really need to SSR some things? I think that's a nice balance there, potentially.

00:20:02 - Anthony Campolo

So for Smashing, are they doing that because it would take too long to build the entire site at once?

00:20:10 - Nick Taylor

I would guess so. I don't know what Taos has to say, but imagine generating, say, 10,000 pages. Your build time is going to be pretty okay.

They said millions of. He said millions of. Are they?

00:20:24 - Anthony Campolo

Yeah. This is what I've heard. If you want to look at the ultimate thing that would break SSG, look at how you would build something like Mozilla Developer Network. Could you build that with SSG? For the most part, no, you cannot, unless you use something like Elder.js, which is a static site generator that's built to generate tens and tens of thousands of pages very quickly. But the vast majority of static site generators can't handle that kind of load.

00:20:53 - Nick Taylor

The other thing that differs here too is why people might do SSG. With SSR pages, you could get an error when you go to hit that page. It could, for example, fail to hit the database or something went wrong, so the page couldn't load. You get a 500 error or a graceful error message. Maybe just reloading the page is fine, but that could be an argument in some cases why people might want to statically generate these things at build time, because you'll see the error at build time.

The other thing too is if your page is super dynamic. I don't necessarily mean client-side. You might have a lot of dynamic content coming in from the server side. Then maybe it makes sense to SSR that and then caching is needed.

[00:21:48] There's many ways to slice it. I don't want to pigeonhole an answer because I think it really depends on the kind of thing you're building and what you're trying to accomplish. I don't know how Google scales, but if you do search queries on Google, that's probably cached in the back end somewhere, but they're probably still SSRing all those pages when you do a search. There's no way they could static those things. Every question a person could ask is massive. The number of permutations, there's no way you could do that, but you could cache parts of it.

[00:22:27] Facts. Nicky, what are you building? I know people get annoyed when you give that it depends thing, but it really does depend what you're building.

00:22:44 - Anthony Campolo

Well, it's depends, and then you say what it depends on. It depends is only a cop out if you don't say what it depends on.

00:22:51 - Nick Taylor

Yeah, exactly. Another thing is I was speaking to somebody the other day. Not that I'm looking to work anywhere, but I always speak to people because people are always in your LinkedIn messages or whatever.

Somebody was talking to me about how they had this massive payload. Not making it like a fetch request, but the actual page loading was loading like 50MB of data. This isn't consulting. I just happened to mention it. I wasn't doing consulting for him, I was just giving him an idea.

This is related to SSR. You can do streaming SSR, which is like as stuff comes in, it can start rendering the page. That would be a good use case if you have a lot of information but you need people to start seeing it. You could start streaming it. This is stuff that's available. I don't think it's available just on edge stuff, but I could be wrong about that.

[00:23:59] I know at Netlify, because I can't speak for the other platforms, we have streaming SSR on edge. That's interesting. You could just start people even though the page isn't fully rendered. You can actually start reading pertinent content. Again, it depends on what you're building and how big the data is. There's many ways.

00:24:18 - Anthony Campolo

You mentioned streaming, actually, because there was just an article that came out on Builder.io. This is the company that builds Qwik. This is Misko Hevery. They just wrote an article called "Streaming: Is It Worth It?" This is a really interesting conversation because partly about does the framework support streaming.

So I know that with something like React server components, which is kind of a new paradigm that React 18 has been building towards, getting them set up for streaming is a huge part of that. There are going to be frameworks that support streaming, frameworks that don't support streaming, and deployment platforms that support streaming deployment, that don't support streaming.

This is back to that question of does your framework support it? Does your deployment platform support it? You have to find both, and then you can combine them.

[00:25:16] If this does support streaming, then you get this really nice kind of experience of having stuff just load as it comes in.

00:25:24 - Nick Taylor

Yeah, exactly. And again, it all depends. That link I just dropped there that you popped up, it says SSR, but it's from patterns.dev. It's a really great website, but they talk about streaming in there in general. It's not talking about a specific framework.

I'm not an expert in that yet or anything, but I worked with it recently and it's just really nice. You've got this buffer and you're just emptying the buffer. Again, to my point about that person I was speaking to, they were having a huge problem just loading this 50-megabyte page of data, which most people would say, like, why are you doing that? The context of this was it was like a lot of scientific documentation and a huge amount of data that researchers need to look at.

[00:26:17] So the faster they can start reading it, even though the page isn't loaded, made sense.

00:26:22 - Anthony Campolo

So yeah, that's interesting. Because it was like, you know, I think there's this tendency to look at things like that and just be like, this is wrong. This is bad. You should not do that.

For most sites, yes, that would be bad. That's a bad experience, and it takes a whole chunk of users in parts of the world and with certain internet connections and just says, like, you can't even attempt to view this. But there are situations where there is a good reason to do that.

We should always take that into account. It may seem like a bad idea for the vast majority of sites. It can be a bad idea for the vast majority of sites and still be necessary for a very small subset of sites. That's okay. We all have different use cases.

00:27:07 - Nick Taylor

The other thing is I know Remix is SSR-first. It renders the page, but then you just use regular caching that's built into the browser.

So you serve the page depending on what the page is like. If it's something you want to cache for a while, you set the cache headers appropriately so you're still getting the benefits of generating this page when you need it, but then it's cached at that point.

The only time you really don't want to hit the page again, like brand new, is if it's stuff where you don't need the page. The page really isn't changing. The caching can stay for as long as possible. There are ways to invalidate this as well.

00:27:55 - Anthony Campolo

Cache headers is a kind of a related but slightly separate topic. How would you do this type of thing within the web platform itself?

What we're talking about right now is how do frameworks set us up for this so that you may or may not necessarily need cache headers. With something like what you would do with Astro, you wouldn't have to necessarily set a cache header. It's just... [00:28:25] - Nick Taylor Yeah, the framework will. Yeah. The frameworks can guide you there. I'm still pretty new to Astro, so I imagine you can probably override it and set explicit caching headers if you need to. Don't quote me on that, but the whole point of these meta frameworks or end frameworks is to make you productive, you know?

So, yeah, Tiles is saying it's coming back to single server. I did a lot of ASP.NET back in the day, ASP.NET and ASP.NET MVC, and yeah, that's all server-rendered. It solved a few things that should have been solved in things like ASP.NET. Yeah.

I have to give it, like I made a conscious shift to Node.js and frontend dev specifically in 2016. But until that time I was pretty much in Microsoft shops doing .NET.

[00:29:27] I actually appreciate having had that experience because one, it was backend experience working with typed languages. Two, and I won't derail this conversation, but TypeScript was created by the same person that created C#: Anders Hejlsberg.

00:29:44 - Anthony Campolo

So there's some similarities there.

00:29:46 - Nick Taylor

Yeah. You can thank C# for async/await. Basically, there's a lot of stuff that came in TypeScript that got put into the platform itself. I think nullish coalescing too; I could be wrong about that. Anyway, that's a small tangent.

00:30:02 - Anthony Campolo

Languages always learn from other languages. It's one of the great things about webdev and programming. To me, I kind of think of it like music genres. People look toward jazz, people look toward hip hop and be like, "Oh, that's a cool beat. I'm gonna steal that." And then people will look toward jazz like, "Oh, that's a cool scale. I'm gonna steal that." That's how we all grow together, by drawing influences from each other.

00:30:27 - Nick Taylor

Yeah, for sure. We'll get into some live coding soon. The other thing I'd mention about server-side rendering is there's this other pattern that got coined by, I believe I'm saying her name correctly, Katie Sylor-Miller, who worked at Etsy. She might still be there, I'm not sure.

It's called Islands Architecture, and I'm going to drop a link to a couple things about that if folks want to check that out. This kind of ties into the server-side rendering story as well.

Oh, those didn't paste together too well. Hold on. That's going to end up being one big thing. Let's just do those separate. There, here, and here. They're all good reads. JSON format is; that's Jason Miller, who's the creator of Preact and works at Shopify now, and previously Google.

00:31:25 - Anthony Campolo

Dropped one of my own. Actually, I wrote a blog post going over a lot of this history as well. I had Ryan Carniato read this over for me and make sure it was all correct. So there's a lot of good resources now about islands and kind of what this whole partial hydration thing is. This will be partly what we'll look at with Astro.

00:31:48 - Nick Taylor

Yeah, yeah. Ryan's a super cool dude. I have the luxury of working with him now. He works at Netlify. I haven't spoken to him too much because he's super busy, but I had a really nice one-hour conversation with him when he started, and he seems like a really kind person. Honestly, he's just trying to help out frameworks in general. Obviously he's working on Solid, but I like what he's doing in that space. He just wants the web to be better, basically.

00:32:19 - Anthony Campolo

So yeah, very, very big Ryan fan. He was the second guest on this stream, so if you want to check out the backlog you can find one of those.

Then we got some love for the Astro team. I've had a lot of the Astro people on my podcast, and they will be coming up on the stream undoubtedly at a certain point. People like Ben Holmes and Dan Tan and Fuzzy, a fuzzy bear for anyone who knows Fuzzy. That was an awesome, awesome team.

00:32:47 - Nick Taylor

I don't know Fuzzy Bear, but sounds cool.

00:32:49 - Anthony Campolo

Yeah, he's a foul-mouthed Scottish dude. Very fun.

00:32:54 - Nick Taylor

Cool, cool. Getting back to the islands architecture, this pairs really nicely with server-side rendering because basically think of an ocean. Visualize an ocean, and you can picture islands on it. Those islands are basically the pockets of interactivity that are on your web page, and think of your web page as the ocean. Oh, there's Fuzzy.

00:33:19 - Anthony Campolo

All right. Fuzzy. What's up, man?

00:33:21 - Nick Taylor

Cool, cool, nice, nice. Is that how it works? It's like you put out the "I love Astro" kind of like the Batman signal, and the Astro team shows up.

Anyway, you have these pockets of interactivity, and that's what the islands are. It's basically loading only the JavaScript you need for that particular interactivity. Astro supports this as well.

I was dabbling with this over the weekend. Like I said, I'm still super new. I'm literally probably a day and a half into Astro. Side note, it was really easy to get up and running with Astro even though I've barely used it, so that was pretty cool.

It's just this nice way because if you think of, like, I've worked on SPAs where you're loading up two megabytes, four megabytes of JS. In some cases, like fintech apps and stuff. In this case, you can server-side render.

[00:34:17] Boom. You get the quick page, and then you have that interactivity with that little bit of JavaScript that's related to that particular thing. So it's a really nice pattern.

I really love that name, Islands Architecture, because visualizing it is so easy to understand, I find.

00:34:35 - Anthony Campolo

Yeah, I remember I used to hear this term, "sprinkles of JavaScript," and I feel like that's a similar idea. That was a Ruby on Rails thing where they would say Ruby on Rails was server-side rendered, like we've been talking about, but then you kind of sprinkle some JavaScript on top and that can give you your interactivity.

But now we're in a place where you're dumping a bucket of JavaScript on top of your page. And it's like, well, maybe we can set ourselves up so you dump that bucket and a lot of it gets filtered out, and then you just get left a little bit of sprinkles on top. Your tooling will set you up to have the sprinkles, even if you write it like it's a whole bucket.

00:35:18 - Nick Taylor

Yeah. Because, like, it might sound obvious when you say it, but why load JavaScript that you're never going to use? You're just wasting bandwidth. Even if you can't think from an environmental standpoint, you're loading all this stuff that's never being used.

Obviously code splitting helped with that. Shout out to Webpack for code splitting and others that followed. But I really like the islands architecture pattern.

00:35:52 - Anthony Campolo

Yeah. Yeah.

00:35:53 - Nick Taylor

You want to jump into it?

00:35:54 - Anthony Campolo

Okay, cool. Start coding some stuff. All right. So we're gonna do some screen sharing here. We close that up.

So I got here, we got our Astro site over here. Got home in code editor. Pop it in, and got Fuzzy also saying hey. So thank you everyone in the chat for hanging out. We're gonna start doing encoder there.

00:36:20 - Nick Taylor

Hey, it's going home, encoder.

00:36:23 - Anthony Campolo

All right. And this is Astro's website, Astro, for people who want to check this out. And should I just grab this guy right here?

00:36:35 - Nick Taylor

Yeah, you can do. We can start that up if you want to open up VS Code, or I'm assuming you're using VS Code. I could be wrong, but of course.

00:36:44 - Anthony Campolo

And let's call this agency web dev Astro SSR. And you said just the basics, right?

00:36:54 - Nick Taylor

Yeah. We don't need to build a blog or anything right now. This is really more just to get set up.

00:37:00 - Anthony Campolo

I do have a blog though, which is still coming together. This is not complete yet, so you're getting a sneak peek here. But this is built with Astro. This is something I've been working on for a little while, so if you do want to build a blog, Astro is pretty great for that.

00:37:18 - Nick Taylor

Yeah, it looks great. So once that's installed, again, like I was mentioning before, Astro is really neat. They have adapters for all kinds of platforms, like Netlify, Cloudflare, Vercel. Can't remember where else, but I'll drop a link to the integration guide so folks can see where you can deploy this to.

00:37:41 - Anthony Campolo

And this is interesting. You have strict, strictest, or relaxed, or no TypeScript.

00:37:48 - Nick Taylor

I guess I would go, I'm somebody who's done TypeScript for a long time. If you're doing a greenfield project, I would recommend strict, or I'd say strictest, but it doesn't really matter for what we're doing today.

00:38:03 - Anthony Campolo

You recommend the recommended.

00:38:06 - Nick Taylor

Yeah. Strictly good, or strict. It really doesn't matter because we're not really focusing on TypeScript today.

As a side note, if you are working in a TypeScript project or migrating to one, that's how you keep things loose in TypeScript until you've kind of made the migration, and then you slowly start tightening things up. Other folks have different opinions.

00:38:28 - Anthony Campolo

But let me just get set up here. I'll go ahead and actually get this onto a repo for people who are curious. I have this one massive GitHub CLI command that I use to.

00:38:50 - Nick Taylor

Yeah, that is pretty monster.

00:38:53 - Anthony Campolo

It's epic though, because what it does is it both lets you choose whether it's private or public. It will take your project and then set your remote and then push it and do the entire thing all at once. This is the proudest I've been. When I wrote this command I'm like, I'm going to use this for the rest of my life.

00:39:14 - Nick Taylor

Okay, cool. So once you got that up, let me know. Then we can add some adapters and we'll need to modify the Astro config.

00:39:22 - Anthony Campolo

All right, cool. So this should be pretty much good. So, yeah. Walk me through how to get the adapter set up and maybe say a little bit about what is an adapter and why would we need one.

00:39:35 - Nick Taylor

Yeah. So basically the adapters, from what I've seen, allow you for different deployment targets, like Netlify, Cloudflare, Vercel, or whatever. So I'm just going to go with the Netlify one. The focus isn't Netlify on this. It's just the one I'm familiar with.

00:39:53 - Anthony Campolo

What do you know.

00:39:54 - Nick Taylor

You can run npx astro add netlify.

00:40:03 - Anthony Campolo

Just like that.

00:40:03 - Nick Taylor

Yeah. And this is something I like about the actual project. They have amazing documentation as well, but it's really quick to just get this set up. I'm not joking when I say I started looking at this on Friday.

00:40:19 - Anthony Campolo

Well, what's funny is that for me, as someone coming from the Redwood world, this is table stakes. We've had commands like this for years to set up deploy. We have redwood setup deploy as our version of this. So when I started doing it, I'm like, okay, good. All frameworks should do this. This should just be the way things are.

00:40:42 - Nick Taylor

Cool, cool. All right, we're gonna add. We're also gonna add the npm install @astrojs/netlify, and we're going to need this for when we go to modify.

00:40:57 - Anthony Campolo

For us, actually.

00:40:59 - Nick Taylor

Oh, yeah. I think you're right. Sorry, that was me learning it on Friday.

00:41:03 - Anthony Campolo

Yeah. So.

00:41:03 - Nick Taylor

Yeah. No, sorry.

00:41:04 - Anthony Campolo

If we look here, we see that right here.

00:41:07 - Nick Taylor

Yeah. Yeah. So that's my bad. That was me learning on a Friday evening.

Okay, so now if you go to the astro.config.js there just under your .gitignore on the left there.

00:41:18 - Anthony Campolo

Yep.

00:41:20 - Nick Taylor

Oh, yeah. Fuzzy Bear is giving you a shout out.

00:41:22 - Anthony Campolo

Oh, I see.

00:41:23 - Nick Taylor

Okay, so we can see in here. All right. Already we're seeing. So if you want to do SSR in Astro, you have to have output server. It's already set there and we've got the adapter, Netlify.

00:41:38 - Anthony Campolo

That's interesting. So it looks like it assumes that we wanted SSR here.

00:41:44 - Nick Taylor

Yeah. Well, because, yeah, I guess maybe somebody from the Astro team can speak to it, but I think the fact that you're just adding an adapter, they must assume it's server. I don't know.

Okay, so we're set up there. Now if we just go to the command line, whether you're in iTerm or what is that, Dev, I don't know what you're in, but.

00:42:08 - Anthony Campolo

No, this is so. That's funny. Actually, I was using Warp for a while. It started randomly crashing. I'm not really sure why, so I kind of popped out.

Yeah, with adapters used for SSR deployment. So it looks like they assume if you're using one of these adapters, there's gonna be some sort of SSR involved.

But this is just the regular old terminal. Warp is awesome, and as soon as I stopped using it I'm just like, oh man, how do I get all this sweet functionality that Warp gave me? But yeah, this is just regular old terminal.

00:42:37 - Nick Taylor

Yeah, it makes sense with what Fuzzy Bear is saying, because if you were just doing an SSG, it would just create a build folder. Wherever you deploy, you just say, this is my directory where I'm deploying to. So you don't need an adapter, you're just literally generating the files. So that makes sense.

Oh, you got a raid coming in here.

00:42:55 - Anthony Campolo

Hello, Jen. Thank you for the raid.

00:42:59 - Nick Taylor

Nice.

00:42:59 - Anthony Campolo

How are y'all? How was your thing doing? Looks like you went way over. Usually would be done around ten, but looks like you had some Python fun going on.

See, normally we ship static files. Like, pop ups open.

00:43:15 - Nick Taylor

All right. So, yeah. At this point Astro's set up, and the deployment target is Netlify for serverless, not edge. But let's just start up the app. So let's just do like npm run dev.

Now this should load up. If you click on there, it's the default. If you open index.astro, this is what it will get rendered here. So there you go. Welcome to Astro.

Okay. Now the first thing I want to show here is to show that we're doing server-side rendering. If you do View Page Source, because typically if you're doing, I mean, I guess typically with a statically site-generated page too would all be there. But if you compare this to something like Create React App or whatever, where you have your index.html, which is it just kind of blows up in there and then your whole app loads up, you know, here you can see everything is server-side rendered.

00:44:13 - Anthony Campolo

Yeah. What's cool about this is this is actually fairly readable. So we have our head, we have some meta tags. We got some scripts here and then we got our actual page. Got our body, we got main. This is a good example of, sometimes when you look at what's actually generated from a JavaScript framework it's nonsense because it gets minified and it gets smushed down. But you can look at this HTML and understand what it's doing.

00:44:44 - Nick Taylor

Yeah. It could be also because I didn't check the build output. Because we're running in dev mode, they might not squish it up, because you're in dev mode, just so it's more readable.

So one thing I want to show is that we're actually running on server side. If you go into Visual Studio Code. I know when I speak to people, sometimes a lot of people still aren't familiar with the Node.js debugger, or if you're using Deno, it's still using V8, so it's essentially the same debugger.

00:45:16 - Anthony Campolo

Let me get my Astro extension going here.

00:45:20 - Nick Taylor

Yeah. Oh yeah. Get that IntelliSense going on in the Astro.

00:45:26 - Anthony Campolo

Yeah. So this is the actual page. This is what we're looking at right here. We have our index.astro file. And so Astro has their own specific file and a specific kind of syntax. So here we're pulling in these two components and they're both .astro files. And then we are rendering out what we got right here. So this is like a single-file component kind of thing. Got a layout, then we got our actual HTML, then we got our style tags.

00:45:58 - Nick Taylor

Yeah. So, as somebody new to Astro, I didn't really know how to put a breakpoint in here. So what I did is put it after line three, above line four. You want to still stay in that area? Yeah. So just, yeah, exactly.

So now we could do, like, a console.dir and just Astro, a capital A. This is like the object itself. Then after that, just press Enter and then type in the keyword debugger.

The only reason why I'm using this is for folks that might not be familiar with debugging in Node.js or JavaScript in general.

00:46:47 - Anthony Campolo

Right now, I don't know crap about debugging. I don't use it. I console log everything. So Nick is teaching me right now.

00:46:54 - Nick Taylor

So, like, I use logging a lot too. But when there's stuff where I don't understand what's going on, I like to step through the code to understand what's going on, or at least just kind of poke around.

So adding a debugger keyword is an explicit way to literally stop the program. You can do that. There's other ways you can add breakpoints, but because it's a .astro file, I didn't really know how to put a breakpoint in there because it won't pick it up because it's not a JavaScript file.

So what we're going to do now is, you can see it logging over there, but the debugger is not stopping. So what we're going to do is we're going to stop your, just Control+C in your terminal for a second. And we're going to go into the integrated terminal in Visual Studio Code. If you just want to make your VS Code a little taller.

00:47:42 - Anthony Campolo

Okay.

00:47:44 - Nick Taylor

And yeah. So if you do just Control+backtick, or just, just to get the integrated terminal showing.

00:47:53 - Anthony Campolo

Oh, like that.

00:47:55 - Nick Taylor

Or I can do it. [00:47:56] - Anthony Campolo I forget how you do Command+J.

00:47:58 - Nick Taylor

Okay.

00:47:59 - Anthony Campolo

Yeah. Okay.

00:47:59 - Nick Taylor

Now, we're not going to start the project from here. You could, but if you click on the down arrow just beside the plus beside the zsh at the top there of the terminal area, the terminal window on the far right. Yeah, there. But if you go to the down arrow beside the plus, there's something called the JavaScript Debug Terminal. So click that. It's going to launch another session here.

But what this does is it actually automatically attaches to the Node.js debugger for you. You don't have to do anything. Even if you're running npm stuff, it just connects.

So I just kind of want to show that we're actually stopping in server-side code. We're going to run the same thing again. So if you just do npm run dev and then when you go to hit the page. Okay, so here the program is stopped. Now it's going to look a little weird here because this is the transpiled code, which I'm assuming the compiler does.

[00:48:54] Again, like I was saying, I'm not sure how you can put breakpoints in normally unless you're in a JS file in the actual program or JSX.

00:49:03 - Anthony Campolo

So what am I looking at right now?

00:49:05 - Nick Taylor

Okay, so that index.astro file that we were in a second ago, like your other tab, this is what it gets compiled to. Or at least the JavaScript part. The markup probably gets pulled out in its own thing.

00:49:18 - Anthony Campolo

Okay. So right now this is what we would actually see if we were looking at view source kind of thing. This is what it's spitting out in terms of the actual generated JavaScript code.

00:49:32 - Nick Taylor

Yeah. There's another thing that ties into this, because normally when you're stepping through code, when I say stepping through code, I mean literally you can go line by line. There's a down arrow there that you see in the debug bar under the Astro SSR in the middle of VS Code at the top. Don't press it right now, but you could. Right in the middle at the top, literally in the middle of your VS Code window at the top, there's this little bar. Yeah.

So if you click the down arrow, it's going to go to the next line. And this is how you can step through code. You can look at things and understand. I honestly don't know how the Astro compiler works, but this is how it's generating the JavaScript.

Okay, side note, you don't always end up in the weeds of this compiled code like this. There's something called source maps.

[00:50:26] I know we're going kind of off topic of SSR for a second here, but typically, say you wrote a TypeScript file, it would compile down to something like this in JavaScript, but you could actually still step through your TypeScript file because there's this source map that says, when I'm in this line of the TypeScript file, I know where it is in that compiled JavaScript.

The only thing for me is I don't know how that works with an index file. So that's why we're in the actual code. Or maybe it doesn't. It's not supported. I don't know. But regardless, I just kind of wanted to do this, not to confuse people. It's really just to say this page, if you go to your web browser, you're going to see the page is not loaded yet. It's just going to be white, probably, or hanging wherever you have it open. Maybe it's not that one.

00:51:11 - Anthony Campolo

It is actually hanging. We see the... Oh yeah.

00:51:15 - Nick Taylor

Yeah, yeah.

00:51:15 - Anthony Campolo

It's actually hanging right here. Yeah.

00:51:18 - Nick Taylor

Yeah. So I just wanted to do this to show you that we are... Okay, there's TSX maps now. So Fuzzy Bear is saying there is some source map story.

But I just want to show you this because you can see in the browser itself the page is not loading because we've stopped the program, because we're in the middle of server-side rendering it.

00:51:36 - Anthony Campolo

Yeah. And you can see all around, you see actually SSR written here in the code. And then we see that it's kind of shipping HTML. There's HTML embedded in here. There's also all this JavaScript happening as well.

00:51:54 - Nick Taylor

Yeah. So the reason why I put the debugger there is, if you hover over that Astro... We'll take a small foray into this. If you look on the left, there's these variables on the left. There's Astro2. That's what the Astro object is. It's just called "two" because of the way it was compiled.

But I just want to show you that you have access to all these things in here. If there was cookies, you could see them. If there's a redirect params. So say there was a query string, like say you were loading a product for something. The param might be like SKU equals something.

00:52:29 - Anthony Campolo

And this is cool. This is useful for me as someone who's building my blog. Now I know that we use this URL here when we're generating your canonical URL for your blog post. It kind of uses this, pulls stuff out and sticks it in the head. And then it'll generate canonical URLs for you.

00:52:49 - Nick Taylor

Yeah. So you don't always have to debug things. Like I said, I typically only debug when I'm trying to understand something. Because console logs for me are great when I kind of know what's going on and I just want to see what's it spitting out.

But in this case, I'm still new to Astro, so I just want to see what's kind of going on. And so I was inspecting the Astro object and stuff and just kind of seeing how things are going.

But again, my main point was to show that the page isn't loading yet because we've actually paused it. So it's just to, I guess, kind of air quotes "prove" that this is server-side rendering.

So we're gonna let it continue. If you press the play button in that middle bar at the top there, the blue play button, it's going to finish. Yeah. And it looks like it's doing two passes maybe. I'm not sure why, but just press play again.

[00:53:36] That could be something to do with the development environment, I don't know. So now if you go back to your web page, you can see it's loaded.

00:53:44 - Anthony Campolo

Oops.

00:53:45 - Nick Taylor

Okay. It's because you requested the page again. So anyways, we can stop that there. If you go to the debugger at the top, hit the two red plugs in the middle there, and that'll just stop the debugger.

00:53:58 - Anthony Campolo

I finally got to use the debugger. So I was wondering, what was your take when you were here for the first time?

00:54:07 - Nick Taylor

I felt pretty comfortable, honestly. Fuzzy Bear, I mean, I've done a lot of debugging in Node and even, you know, to some degree, because for folks who aren't aware, at Netlify we use Deno for edge functions, which is kind of another runtime for JavaScript and TypeScript. But yeah, it's kind of neat.

00:54:28 - Anthony Campolo

You said we weren't going to deploy this, but I want to deploy this because I feel like it's going to take like five seconds. And I'm curious to see what happens because I already have it on a git repo. So let's hook this up and see what happens.

00:54:44 - Nick Taylor

But yeah, like I was saying, Fuzzy Bear. Is it Fuzzy Bear or Fuzzy? I don't...

00:54:51 - Anthony Campolo

Fuzzy Bear.

00:54:54 - Nick Taylor

Okay, Fuzzy Bear. Like I was saying, I literally just started messing around with Astro on Friday night, and I just felt super comfortable in it right away. And we haven't even got to it yet, but I want to talk about the integrations.

I'm pretty familiar with Preact and React, so I thought we could put in the integration for Preact and we can kind of show some Preact islands or islands in Astro, because this ties into the SSR story like I was saying before. Okay, hopefully this works. If this doesn't work, we can go do other stuff while that's working.

00:55:29 - Anthony Campolo

Yeah, while that's building, we can go ahead and go back into that. So we're going to add Preact. You said, should I keep this running in this terminal?

00:55:37 - Nick Taylor

No. You can just stop it. Yeah, there. You can stop. And you can get out of that terminal. You can just delete it, and you can go back to your regular one.

Side note, that is an easy way to start debugging in JavaScript or Node.js. You can even debug your browser in VS Code, but I don't want to get into all that right now. But you can also just explicitly run Node and say use --inspect-brk, which is a way to start the debugger and stop right away.

Okay. So we want to add Preact here. So what we're going to do is npm install @astrojs/preact. And yeah, there's a lot of stuff you can do in debugging too. You can see the stack trace. You can actually... Is that right?

00:56:34 - Anthony Campolo

@astrojs/preact.

00:56:37 - Nick Taylor

Oh yeah, sorry. That's my bad. Yeah. There's even a neat feature in the V8 debugger. At least I can't speak for other stuff, like JavaScriptCore in Bun and stuff. But you can actually rerun parts of the stack trace so you can go back in the code. Kind of like what time travel in Redux was for anybody familiar with Redux. But it doesn't always work. It's interesting, but that's a whole other topic though.

00:57:08 - Anthony Campolo

So yeah, let's go to the config. You can check out the VOD on Twitch for the next day or two, and I upload all these onto my YouTube account as well.

00:57:23 - Nick Taylor

Cool, cool. He's on the tubes. Yeah.

00:57:27 - Anthony Campolo

All right.

00:57:28 - Nick Taylor

Yeah. So let's just open up the Astro config file. Okay, so there's an adapter for Netlify there still, but we need to add the one for Preact. And it's not adapter, it's integration, I believe. I just gotta double check.

Yeah. So there's another property. Under the adapter, if you just add an integrations property. And that integrations property is going to be an array and it's going to be Preact as a function. No, just... yeah, yeah. And if it doesn't find it, just auto import it. If you delete the T and then type it again, the Preact there, it should autocomplete it, maybe auto import. If not, we can just explicitly do it.

Okay, it's not finding it. So now we just need to add a default import. So we're going to import Preact from, at the top there just under Netlify.

[00:58:33] And it's @astrojs/preact.

00:58:38 - Anthony Campolo

Like so.

00:58:40 - Nick Taylor

Cool. Yeah. All right. So that should be all good, and we can save that. Let's just start up the application again, and it still should just load what we saw before. Just the index.astro page rendered. Okay, we're all good.

00:58:55 - Anthony Campolo

That's all still good. Let's do this real quick, because I always like to do something like this. From AJC and the Web Devs.

00:59:11 - Nick Taylor

And the Web Devs. All right. I'm just going to check my work Slack real quickly to make sure nothing's blowing up. All right. Cool. We're okay in there. All right.

So okay, you see this? The page is still working as expected, but now we have access to Preact. And I've heard about this in Astro, but I really like that you can really just start building components out in whatever you're comfortable with.

I did a lot of Preact because that's what we use at dev.to. So what we can do is if you open up your folder view on the side there for a second. Under components, let's just create the components folder. Let's just create a new component. I don't know, let's just say let's call it Hello.jsx. And we'll actually import your Hello Web Dev. So go back into the index.astro.

[01:00:06] Let's cut out that paragraph.

01:00:08 - Anthony Campolo

Grab this right here.

01:00:10 - Nick Taylor

Yeah. And then we'll just do, I personally like named exports but do a default if you want. Whatever. Just export.

01:00:21 - Anthony Campolo

Export default.

01:00:25 - Nick Taylor

Yeah. And you can just do an arrow function and then you can just put the JSX you have there or return it. Yeah, you'll have to return it because you have the curly braces. Jason Lengstorf says...

01:00:44 - Anthony Campolo

Oh, sorry.

01:00:45 - Nick Taylor

Yeah. Put it just before the P on that line. Yeah, exactly. You can do that. Yeah. Okay. So that's good there. Now, if we go back to the index.astro...

01:01:02 - Anthony Campolo

Then we're going to import it.

01:01:04 - Nick Taylor

Yeah. So you can call it whatever. Hello makes sense. And then from components, so ../components and it should pop up there. Hello. Okay. Now you don't need to do the .jsx. It should be able to detect it.

Okay, so now in there, let's just add that Hello and let's save that. Yeah. Okay. Now it reloaded. It's not in the card component because the styling is missing. But okay, we can see we've already got that. So that's cool.

Let's create another component. Let's just call it Island for fun. It has nothing to do with islands architecture aside from it's going to be a demo of what an island is. So let's do another component. No, we don't even need to pass anything. We just want to show that it's interactive. So we're going to return a button with an onclick.

01:02:08 - Anthony Campolo

Like so.

01:02:10 - Nick Taylor

Cool. Yeah. And then in that button, let's just add some text like Subpial or AJC doing cool shit. I don't know, whatever you want to put. Okay. And then, yeah. So in the button we're going to add a prop there, onClick with a capital C, and then it's going to equal with parentheses. And then we can just have an arrow function in there. You'll need to use the parentheses because it's a proper function call.

01:02:38 - Anthony Campolo

Parentheses like so.

01:02:41 - Nick Taylor

Or this. Sorry, the squiggly one. I always forget what the squiggly ones are called, but Jason does. Yeah. So in there we're just going to return an arrow function that just says something like we'll do alert so we can visually see it. Yeah. Curly boys. Yeah.

01:03:03 - Anthony Campolo

Oh, like so.

01:03:08 - Nick Taylor

Yeah. And we can say YOLO or something. YOLO is my favorite word. Yeah.

01:03:16 - Anthony Campolo

Like so, or?

01:03:18 - Nick Taylor

Yeah, just in text and parentheses. Sorry, in quotes, not parentheses. I don't know why I have parentheses on the brain, but I do. Cool. So, all right. Alert. YOLO. It's just complaining because you're not returning anything, I think. Oh, you're missing the greater-than symbol after the equals. And your arrow function on line three there, just before the curly boy.

01:03:42 - Anthony Campolo

Greater than. Oh, yeah. Duh. There we go.

01:03:45 - Nick Taylor

Cool. Yeah. All right, so that's good. Now let's save that.

01:03:51 - Anthony Campolo

All right. And then I got to import this.

01:03:54 - Nick Taylor

Yeah, exactly.

01:03:56 - Anthony Campolo

Yep. This will be Island. Island and the island.

01:04:06 - Nick Taylor

Okay, so let's add it. Let's save it. Okay. You're going to click the button. Nothing's happening, right?

01:04:11 - Anthony Campolo

Correct.

01:04:12 - Nick Taylor

Okay, so now we're going to use this. I'm going to just drop a link to it, but Astro has something called directives. So you're going to add an attribute to the island component. It's going to be here.

01:04:26 - Anthony Campolo

We got this nice auto-complete here. So this is actually a real quick tangent here. Yeah. Over a year ago, Ben Holmes, who some people here know. He was building a framework called Slinkity, which was about adding in components to 11 D, and he and I actually spent a decent amount of time working on this framework. So I kept bugging him to actually put it out. And then once he did, I kind of felt a certain amount of responsibility over it.

So he and I were building almost an Astro competitor for a decent chunk of time. And this is where I learned about this: you have these client directives, which allow you to specify whether something is going to be loaded right away, whether it's going to be loaded once it enters the viewport, and all these different variants of when we actually want to load our JavaScript.

[01:05:28] And this is where we get fine-grained control over our islands.

01:05:33 - Nick Taylor

Yeah. No. And it's super neat. I haven't used them all yet, but a lot of them make sense. Like the client:visible is kind of like I'm guessing it uses IntersectionObserver or something as you get closer to it. I'm not sure how that decides.

01:05:45 - Anthony Campolo

When these are, we're using them.

01:05:47 - Nick Taylor

So we're going to use client:load, the second one there. Okay. And let's save that and the page. It refreshes so quickly, but you should be able to click it now. There you go. Okay. So that's great. We've got some client-side interactivity.

But what I want to show you now is we're going to view page source again. So if you click okay on there, let's make the web browser the full height here and look for Island. You're going to see there's these markup tags called Island. Yeah, that's in the styling. But if you continue along, if you look for like less-than Astro Island, this is where it gets interesting.

And it might be easier to actually copy this and paste it into VS Code as an HTML file just so we can look at it. Okay. And then just change the type at the bottom there where it says Java.

01:06:45 - Anthony Campolo

Yeah, yeah, yeah.

01:06:47 - Nick Taylor

Change it to HTML and then right click and then just say format document.

01:06:51 - Anthony Campolo

Yeah, I got you.

01:06:53 - Nick Taylor

All right.

01:06:54 - Anthony Campolo

Cool. Okay. So we got our head, we got style. And then we're looking for island here. So we got it.

01:07:00 - Nick Taylor

If we go down to the bottom, there's some JavaScript there that's related.

01:07:05 - Anthony Campolo

To here. Here we go.

01:07:06 - Nick Taylor

But this is what I want to show you.

01:07:08 - Anthony Campolo

Thanks for joining.

01:07:10 - Nick Taylor

Y'all. Hey, Nicky. Yeah. So the cool thing here is it's client-side interactive, but you have the button markup already rendered server-side, and it's wrapped in this Astro Island. I'm pretty sure you can do this because the web browser is pretty forgiving in terms of, because it's not a web component, it's literally a piece of DOM. Sorry. It's an HTML tag that the browser doesn't recognize. So basically it just says, oh, I guess you're like a div or a span. So that's why they can use that, I think.

But the interesting things about this, they have some meta information in there to properly map things. So the UID is probably related to that specific island instance maybe. And then you can see it's referencing, I guess, the file system. It's literally the folder to your island. It's a default export. There's a bunch of information in here, basically.

[01:08:07] Yeah.

01:08:07 - Anthony Campolo

And that's interesting because you got one, two, three, four, five, six of these. And yeah. So it's kind of giving us some prop information. It's giving us the actual location it's coming from. And looks like there's some sort of async/await going on here.

01:08:24 - Nick Taylor

Yeah. So the main thing I wanted to show here is that even though it's an interactive island, it's not like, if you think of Create React App, where you say build my component and all of a sudden the markup just appears on the page. This starts off with the markup server-side rendered, and then the island interactivity kicks in. And that's a huge difference.

Other frameworks do other things, like I know Qwik, which is another one. They use something called resumable, which I kind of understand the idea, but I haven't really delved into it.

01:09:01 - Anthony Campolo

Yeah, I've had them on FS jam. Resumable is about serializing the entire state of both your application and the framework so that you can basically stop and start whether you're on the server or on the client, and basically just take the state and then go. So it doesn't require having a hydration step because the hydration step, you have all this JavaScript that gets basically serialized and then gets thrown back to the browser, and the browser has to re-execute the JavaScript. It's different where it's all just serialized into HTML, so there's no work that has to be redone. It's very, very interesting.

01:09:42 - Nick Taylor

Yeah, yeah. And this is different from React with hydration. I'm assuming that, but by the way, we can check that out later. Okay. Oh, cool. Yeah. Nice.

So the thing with React, for example, is this hydration story, at least from what I've understood, is it's going to render server-side. And then when it loads, the component rerenders again over the existing markup and then the interactivity kicks in. If that's not correct, somebody please correct me in the chat. But that's how I've understood it.

And I think with the Astro story, it's like load the markup and then just run the JS. There's no, like, "is the markup that got rendered on the server the same as what's currently there?" And I think the reason is because Astro loads it server-side and doesn't do the check after to see if the markup differs from the component because that's not what it's trying to do.

[01:10:50] Anyways, but the main thing I wanted to show here was that we get this client-side interactivity that just works, and it gets server-side rendered, which is super neat.

01:11:02 - Anthony Campolo

Yeah. Awesome. Sorry. Go ahead.

01:11:08 - Nick Taylor

Yeah. No, go ahead.

01:11:10 - Anthony Campolo

I was going to say, I think this was the main stuff you wanted to demo, right?

01:11:16 - Nick Taylor

Yeah. And again, the other thing I'd just like to say is I literally just started messing with Astro on Friday, so I mean, I'm super comfortable live coding and stuff, but it was pretty straightforward to get up and running with this and lots of great docs too. And I joined the Discord.

01:11:42 - Anthony Campolo

And I love Astro. I've been a big fan of Astro for a while, and like I said, I actually decided to build my blog with Astro. This is after spending three years and trying out seven different frameworks. I wrote a tweet about this where I think I tried out Gatsby, Elder, SvelteKit, Eleventy, and there's at least one other. So it's like I've run the whole gamut of frameworks, and after trying all of those and then trying out Astro, I'm just like, yes, this is the one. This is what I wanted. It's like it does everything I wanted to do. I'm such a big fan.

And yeah, you got people here saying it's very approachable, docs are top tier, and then obviously we're the ones who are making it great. As Fuzzy says, it's all us. We did everything. Definitely not the team. No, the team did everything. Yeah.

01:12:37 - Nick Taylor

Yeah, yeah. And I really like, I think it was super smart that they support components however you want. I don't know how many people actually would write an app with a React component in a Svelte component. I don't think that's the use case. I think it's more like, hey, I'm a Svelte dev, but I want to start using, yeah.

01:12:57 - Anthony Campolo

You come at it with whatever feels comfortable for you. And so it's not about throwing five frameworks onto one page. It's about whatever framework you want to use, you can use. And I think that's really awesome.

And I just love the fact that you look at the framework world right now, and I think there's kind of like two opposing camps here. There's frameworks that want to say our framework's the way to go. Use our framework. It's the best. Every other framework is lame. This is the framework to use.

And then there's other ones like Astro that are like, hey, we want to make every framework usable. We want you to have the choice to use whatever framework you're comfortable with. And it's not about saying this framework is the best. All the other frameworks suck. It's about saying, hey, there's a lot of good choices out there these days. And I think this is very much like the Netlify model.

[01:13:45] I think Netlify has explicitly said we want to make Netlify work for every framework, and we don't want to just say, use this framework. This is the only framework we support. And I think that's awesome. And it's very healthy for the web. And I think it's more cooperative, less competition. I always say, cooperate, don't compete.

01:14:09 - Nick Taylor

Yeah, no, for sure. And I think it's great seeing the frameworks build off of each other too. Everybody ran with Vite when that came out, which came from Vue originally. But it's nice to see it's used in so many places now.

And like I was saying before, at the start of the stream, my coworker Ryan Carniato seems like a super cool dude. Every time I see him tweeting, it's like he's just trying to help something or spread some knowledge about things. It's not about Solid being the best, which maybe it is, I don't know, I haven't used it yet, but that's not the point of what he's doing. He's just really trying to make the web better, which I think that's really cool. Yeah. Fuzzy Bear says it pretty well: cooperation.

[01:14:58] Greater than competition, for sure.

01:15:01 - Anthony Campolo

Totally awesome, man. Anything else you want to hit on before we start closing it out here?

01:15:08 - Nick Taylor

No, not really. Just check out server-side rendering. There's a ton of frameworks that support it now, like Astro is obviously one of those. If you're interested in a Deno-based framework, Fresh is a new one too that I've dabbled in a bit. There's Enhance. There's Web C.

I interviewed my coworker Zach, who's from 11 fame. He's working on these web component-based kind of approaches.

01:15:40 - Anthony Campolo

A lot of these will be covered in the future. Actually, part of the reason why I started this stream is because I'm a big fan of new frameworks. I think it's really cool. There's a lot of new frameworks out there, and I've been bringing a lot of these people on to talk about the framework on FS jam, but with FS jam, it's like you talk about it, but you don't get to see code. You don't get to build something out. And so this is kind of meant to be somewhat of a companion to a lot of the FSJam episodes I've been doing.

So if you want to listen to it, just search for Astro. You can find a good episode where we talk to Fred about this. And the idea being with this stream is that we can start building stuff out with these projects. So a lot of the things you just mentioned will probably be ones that we'll cover into the future.

[01:16:30] And let me just drop your Twitter. So we got it online.

01:16:35 - Nick Taylor

Oh, thanks, man.

01:16:36 - Anthony Campolo

It's online. If you want to check out Nick, he's got a lot of great stuff and he's working at Netlify. So if you're someone who's interested in these types of projects, he's a great person to be in touch with. You also have your own stream. Is that also Nicky T online on Twitch?

01:16:52 - Nick Taylor

Yeah, it's all there. If you just go to my Twitter bio, it's live coding because I'm in Canada and the domain was surprisingly available, but it redirects to my Twitch. Yeah, exactly.

But yeah. No, thanks for having me on. It was a lot of fun. It's always fun because I'm usually interviewing people or I'm streaming on my own, so it's kind of nice to mix it up and be honest. Yeah. Yeah. For sure. Yeah. Yeah.

01:17:20 - Anthony Campolo

Yeah, definitely. Gotta get on Jen's stream. She will definitely be a hoot and a half for you to chat with. And feel free to join. Yeah, I've seen her in the open Discord.

01:17:29 - Nick Taylor

Even though I'm still a lurker in the open source Discord. I see Jen's in there too. But yeah, I think the only thing I'd say to kind of round things up is people do like to complain about a lot of things, but the tooling has never been better. Even though people might be complaining about current tooling, it's amazing.

Just thinking of hot module reloading, fast refresh, whatever. You know, like source maps, people building their own compilers so you can have stuff like an index Astro or like MDX or whatever. There's just, honestly, it's like, I feel like it's the best time to be a web dev right now. So yeah.

01:18:14 - Anthony Campolo

It really is. And as Fuzzy is saying here, not only is it a great time to be doing this, but there's also communities of people who are out there, willing to help you with this stuff. And this is really huge. Netlify has a Discord as well. So if you do hit roadblocks, it's like you're not just stuck out there by yourself.

It's like if you're using a tool like Astro and something just breaks, you have no idea why. Just go to the Discord. There's going to be an entire team of people who are willing to help and ready to be like, hey, here's what you're doing wrong. Here's what you can do differently. You know, that's awesome.

And that's where we can really come together and help each other out because it's like, I remember when I was first learning to code, it's really daunting to get into this stuff and stuff just breaks.

[01:18:58] You have no idea why you feel like you're just out without a paddle. But it's not like that. Actually, it's like there's a lot of people out there willing to help and can get you out further than you may think.

01:19:10 - Nick Taylor

No, for sure. I'll end with what Jason Miller, who created Preact, when I was working at dev two. I wasn't asking for help, but I just happened to post something where I was having some issue with Preact. I wasn't tagging him or anything. I was just saying, like, yeah, I'm working on this interesting issue. And I had a link to the forum repo where the issue was, and Jason, out of nowhere, just starts replying in my PR. Try this, try that, you know. And I think stuff like that's amazing.

You know, he cares about the project. And I mean, we follow each other now. But it was just really kind of him to, he didn't have to come into my PR and just say, like, you know, do this, do this. He wanted to. And I think what I'd leave people with is, like you said, there's community.

[01:20:03] But you'd be super surprised how many people really want to help you, whether it's on Twitter or in a Discord or some other form of community. So yeah, I'm a big fan of open source too. I've been working in it since 2020, so there's that. Be nice to maintainers, people.

01:20:19 - Anthony Campolo

Totally sorry, Travis, but we are about to sign off, so you've got to catch the VOD, unfortunately. But yeah, thank you everyone who was hanging out with us. This was a ton of fun. I really, really enjoyed doing these. And hopefully I'll get us back on to a more consistent weekly schedule.

But thank you, Nick, for being here. This is a really great demo, so thanks for putting this together. And yeah, as I said, this will be on my YouTube a little bit after this. And if you want to find me, I'm on AJC web dev on the internet. And yeah, I think we're going to close it out here.

01:20:54 - Nick Taylor

Cool. See everybody.

01:20:56 - Anthony Campolo

All right. Bye. Always bet on open source. That's right.