Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you doing?

Chris Coyier: I'm doing excellently. Thanks, Dave. Super feeling good. Kind of did a kind of accidental fast this week, so I just feel--

Dave: Oh...

Chris: I have a black coffee here. I'm not even a black coffee guy. I'm a big guy. I put sugar and crap in my coffee. That's who I am.

Dave: Mm-hmm. Mm-hmm, mm-hmm.

Chris: But not when you're fasting. Everything tastes good at the end of it.

Dave: Oh...

Chris: You're like, "Have you ever had a blueberry? My God! It's bursting with flavor!"

[Laughter]

Chris: It's incredible!

Dave: Uh, have you had water, but like you dunk a strawberry in there five times?

Chris: Yeah. [Laughter]

Dave: Dude, it's the best!

Chris: I love Dave's fun water. Fun water is back!

Dave: Fun water is back, baby!

Chris: Maybe it never left.

You know what I want to talk about this week?

Dave: Sure.

Chris: All kinds of little interesting things to do here, but I just got a little sidetracked not work-wise but just brain-wise on website rendering - a little bit.

Dave: Mm-hmm. Mm-hmm, mm-hmm.

Chris: I thought I'd maybe bring you on this mind journey a little bit.

Dave: Yeah, bring me on. Bring me around.

Chris: There are a couple of reasons to do it. One is if this is new to you in any way, you're a beginner-ish listener, it might be nice to conceptually understand all these different ways that a website might render. And it affects the tools we use. And it affects the hosting we use, which I suppose is another kind of tool but it's different than a software product. It's hardware and software as a service and stuff, too.

I think they're all kind of interrelated in an interesting way. Plus, there's drama. You know? So...

00:02:00

Dave: Yeah, well, I was going to say it's an interesting time, right? Just at the meta-level, React is getting server components.

Chris: Exactly. Fascinating.

Dave: That came out in the last version.

Chris: Yep.

Dave: React 19 will support Web components. That's also kind of interesting for me. It changes the story a bit. There are also other components or frameworks like 11ty and Astro and Enhance.

Chris: They all factor into this story. But it all seems like they evolve naturally, like some developer was in the shower - or something - and was like, "Eureka! I have a cooler way to handle how this framework should work," and they write a blog post about it - or something. The world says, "Eureka! You're right!" and these use this technology.

Is it really that simple? I would say no, it's not. All these things are... Not to take anything away from some genius developer - or whatever - but they tend to happen because other technology changes. You know? One little domino falls, so another domino falls. Or what the world has an appetite for is different at the time.

Dave: Mm-hmm.

Chris: What hosting providers are capable of providing is different. Here's just one example of that.

There was a long period. It might come up, and I don't want to memory lane this too long. But it might come up as a developer.

Generally, websites were just powered by Web servers that had available to them backend languages. You'd almost always choose some host that had PHP available or Python or Ruby or something. You might pick the host because they specialized in some kind of backend language.

There really wasn't hosts that just were dedicated to just static file hosting. You could use them as a static file host. But that was... I don't know if it was a waste, but people just didn't do that that much.

That's simplistic. There were text pattern and things like that that did lean into that. But that was your choice. You had backend languages available if you wanted them.

Dave: You had iPower Web that came with PHP 3.

Chris: Damn right you did.

Dave: And that's what you used.

Chris: Yeah.

Dave: CPanel 2.

Chris: Because it was available.

Dave: Yeah.

Chris: It seemed practical. There was a lot of technology that leveraged that being available. It seemed to a lot of people that it just made sense, and it did. There was really no big problem with that.

00:04:30

Dave: There's sort of like the personal journey for, I think, most developers at this time where you and I both got started was, "I'm going to write an HTML webpage in Angel Fire - or something," and you spend nights and weekends typing out a page one by one. Then you're like, "I want to do a second page. Oh, boy. Can this be easier?" You know?

Chris: Oh, you're speaking my language, Dave. Yes.

Dave: You copy/paste a billion lines of files, and then you're like, "That was not... This is a nightmare to maintain," so we got into these server-side languages which had the include functionality. Right?

Chris: We did.

Dave: That was the big piece, right?

Chris: My God. I feel like the evolution... We're still not done with includes. The entire [laughter] Web design and development is driven by the desire to include things inside of other things.

Dave: Yeah.

Chris: And I don't know that we've still figured out the perfect way that we want to do it.

Dave: Yeah.

Chris: I just think it's hilarious. There's probably a whole philosophical talk that could go around that.

Dave: We keep chasing that dragon. We're chasing that dragon.

Chris: We are.

Dave: [Laughter] Yeah.

Chris: And so when that happens, though, did change at one time. I think it's fair to say that the Jamstack revolution -- which we could argue is now kind of over - or something -- did change things, though. We can look at Netlify and point to them. But then that expanded and stuff.

There was a time where it was like, "We're going to give you a static place to host files. It does not have a server. It doesn't have one. It's not available. You can't use one. The only thing that you can put here is static files, and that's what gets rendered by a website."

There was a bit of a revolution that happened. And you were on it because Jekyll was a part of it and 11ty is part of it and Astro is a part of it.

Dave: Well, and like Gatsby and all these things.

Chris: Gatsby, absolutely.

Dave: When you realize, you're like, "Dude, everything I've written is either in HTML, CSS, or JavaScript file," you CDN everything and be the fastest person on the Internet.

Chris: There were very compelling reasons to do this. I think it was DX-driven (more than user stuff) because it's just what you got out of doing it that way was so delicious. I think a big part of it was deployment from Git repos--

Dave: Mm-hmm.

Chris: --that people just loved that and that became an industry standard. But anyway, let's pause. Yeah, go ahead.

00:07:00

Dave: Well, I feel like, too, at this time there was also a baby current -- which maybe this will come back later -- of offline first, too, right? This whole idea, like, "I'm going to build these JavaScript apps, and I'm going to send them to the client. And then AppCache -- or whatever comes after it (PWAs or whatever) --

Chris: Mm-hmm.

Dave: --is going to cache that on the device so that that's ready now next time. I think service workers were kind of coming out around Jamstack, too. It just seemed like I'm going to put all these files on somebody's computer (phone), and then that's going to take over. It's going to be so fast. I think that was sort of the idea, right? I'm going to put all this--

Chris: Yeah. Maybe there's an undercurrent there. I don't know if that was a major thing, but then frameworks did take advantage of that. I think Next, to this day, ships with some kind of, like, "Don't worry about that. We'll do that for you. And believe me; you're going to want it."

Dave: Yeah.

Chris: But as a pause here. So, imagine where we were and then during this Jamstack thing. It got us thinking about, "Okay, how is my website rendered then? Is it server-side rendered or client-side rendered?"

We got thinking about that because the Jamstack approach could do it either way. If you're Dave and you're making daverupert.com and it's a blog post, you can server-side render it (but by virtue of having the entire website produced as static files and then you deploy them). That is server-side rendering.

Then JavaScript frameworks started their come up-ins. You could, even on one of these static-only hosts, do client-side rendering.

Dave: Mm-hmm.

Chris: Your React site that is built from a bundle of componentry, and not just React. Any JavaScript framework that has just kind of JavaScript, client-side components could be done this way. And they were both compatible with the Jamstack approach. They were both able to be deployed on static hosting.

We just got it in our mind, client-side rendering and server-side rendering, and they were different. But they both had advantages. Yadda-yadda. We've talked about that kind of thing a many time.

Dave: Mm-hmm. Mm-hmm.

Chris: A lot of people were... SSR are now in a renaissance of, like, that is the way. And it became the way because it's generally faster. It's generally SEO-friendlier. And technology has evolved to the point where it doesn't ask that much of us anymore (as developers). A lot of products just do it by default (and that's fine).

Dave: Mm-hmm.

Chris: Let's not get too much into that, but there's a fork on the side of server-side rendering. There are multiple ways to do server-side rendering.

The way daverupert.com is done, those files are already built, so they're just delivered.

Dave: I prebuild on my computer, and I send them up. Then actually, I think Netlify runs Jekyll, stitches it all together--

Chris: Right.

Dave: --into a dist folder, and that's what you get when you go to my website.

00:10:03

Chris: That's what you get. That's static rendering, but there's another. As part of server-side rendering, it can be dynamically done, too. There are ways this would have it. How this happened, I think, is interesting.

First of all, a host like Netlify will say, "Hey, we know that you're going to want servers sometimes. And we're a growing company and we need to invent new features that you're going to want anyway."

This was many years ago, but they were like, "One of those features could be, well, we'll give you a server, too. We'll do it by way of cloud functions."

Dave: Mm-hmm.

Chris: It was very cool and interesting. We all kind of clapped our hands - and I still do. Nothing disparaging here. What a neat idea. We're going to make the DX really nice around running a cloud function that's a server.

Now there are little ways, especially for client-side rendered apps, that they could hit a route, get some data back, and do kind of data-powered client-side rendered apps was very useful to them. But then the SSR people, as it were, get involved and say, "Ah, I could hit that route server-side, dynamically render a page," so it'd be like building daverupert.com, only it's not already built. It's building these pages what you might call on demand.

Dave: Yeah.

Chris: It's saying, "Ah, okay. I'm going to go build this blog post page server-side and then deliver it. I'm going to do it really fast and then deliver it to them." It still is server-side rendering. That's still server-side rendering. Even though it just happened on the fly like that, it can still work in that way.

Dave: Yeah, and so is that edge functions in your brain, this idea of, like, I could put index - or whatever - latest vibe check 25.js on there - or something - and then when you hit that, it runs the serverless function right before it, or the edge handler, edge function--

Chris: Yep.

Dave: --and it says, like, "Okay, are there any new comments here? I'm going to hit the database real quick. If there are new comments, I'm going to just, boom, chuck that HTML in there."

Chris: Exactly.

Dave: Or build the whole page. It could do parts or it could do the same thing and then send that down. Then it's cached on a CDN.

Chris: It's because these cloud functions existed or, as you called them, edge functions. To me, that edge word just means, "Does it run distributedly or not?" It's like that's cool and interesting, but not that. Either way, it's running on and happening on the server.

Dave: Yeah. In my brain it's like, "Does it intercept a call to a known route?"

Chris: I see. Yes.

Dave: Yeah.

Chris: Right, instead of rendering first and then going back and doing another trip to get the data. Yeah, does it intercept the route? Yeah, but then we saw... 11ty is like, "This is actually really cool. We're going to have a server-less," I guess it's a plugin in their world, "that allows this to happen." What that means is that, hey, for example, you might not have to build your whole site. We'll let certain pages or all the pages just be generated by the server on the fly when it needs to.

Astro has server-side rendering that's done in this way. Next.js famously, they can do it kind of all the different ways.

Dave: Mm-hmm.

Chris: They'll prerender what they can. They'll SSR what needs to be. It's a React thing, so they're happy to do client-side rendering as well. A real strength of that as a software thing.

We're just mentioning a few big players. I'm sure there are lots of players in this world.

Dave: It's been a hot minute since I've used Next - a.k.a. never.

Chris: Mm-hmm.

Dave: [Laughter] But does it auto sort of interpolate? Does it sort of auto-guess what strategy you should be using here?

Chris: Uh...

Dave: Or is it like a folder name called--

Chris: It depends on the era of Next that you're talking about.

Dave: Oh, okay. [Laughter] Okay.

Chris: Kind of... Yes. If you want it to only produce static output only, you're going to have to intervene and tell it to only do that. But it shouldn't be too difficult to do that. But it's a setting that you'd have to set.

Dave: You kind of know if your build time is taking 90 minutes. [Laughter]

Chris: Sure.

Dave: You're like, "I probably need their dynamic builder. I shouldn't be doing the aall-static builder." Right?

Chris: Yeah. Stop doing that. Yeah, and I think we could do that.

Dave: That was part of the introduction of these sort of -- what are you calling it -- on-demand builder sort of things was, I have a Jekyll site for every product at macys.com and it's taking 90 minutes to 2 hours to build my website. Right?

00:14:43

Chris: Yes! That was part of the story was to reduce the build time at all.

Dave: Mm-hmm.

Chris: You'd then have to inform what builds and deploys your site to not pre-build pages.

Dave: Yeah. Yeah, yeah.

Chris: Ideally, you do. But yeah, like you were saying. If you're macys.com and you want... I think that story was a little blown out. How many companies are actually in that compared to products generally? That's a big aside kind of thing.

That is interesting, though. When a site then becomes dynamically rendered, does it go to the CDN or not is also an interesting fork.

Dave: Mm-hmm.

Chris: You tend to be like, "If you're Macy's, yeah, sure. This page for this stepper exercise machine is now one person has visited it, so now it's cached on the CDN. The next person gets it really fast." That's great.

But some dynamic content like that isn't able to be cached that way because it has... I don't know. It says, "Welcome, Dave Rupert," in the header. You can't cache that.

Dave: Or "Sold out!" like Ticketmaster.

Chris: Sold out. Sure.

Dave: Yeah.

Chris: Right, so you'd say... So, the temptation then is, like, just don't cache it. It's not that expensive to generate a page like this, especially if you're Macy's or whatever. Who cares.

Dave: Mm-hmm.

Chris: Just server-side render it every time, which doesn't that sound like 100 years ago? Doesn't that sound like how we originally did websites? We just generated the stuff on the server and sent it back down. A little bit full circle there.

Dave: Well, and the challenge there was the "dig effect," right? If you had a surge in traffic from Hacker News - or whatever - your WordPress is falling over because you're hitting the database every single time.

Chris: It is. Yeah.

Dave: I think that was another, like, "Ooh... Jamstack solves that," or "I'll never have that problem. I'll never get a call on the weekend about the server dying because the server can't die. It's just files." You know?

Chris: It can't, and that equation changed, too.

Dave: Yeah.

Chris: The dig effect was real.

Dave: Yeah.

Chris: We lived through that. Then it just went away. It was one of those weird things in this industry we're in that you just never see that anymore.

I did wonder about that a few months back, and a bunch of people weighed in. I think the predominant answer basically was CDNs.

Dave: Or saving servers, yeah.

Chris: They are. Yeah.

Dave: Yeah.

Chris: They're just not getting hit. The servers are just better. They're cached better. It just seems to be the Fastly and the Cloudflare of the world are saving us from that in the future. Okay? So, that's something.

But then it's like all we ever talked about server-wise was the cloud functions that hosts started to offer. Those take a variety of different flavors across different hosts to the point where if you're a popular tool (like Astro, 11th, or whatever), it became kind of your onus then to build adapters that worked for the different hosts because they all kind of worked in different ways.

That's kind of fine but, man, is that increasing the mote around these tools, in a way, because it's like, "Man, I want to make a static site generator but I don't want to write eight adapters."

Dave: Mm-hmm.

Chris: That sucks. You know?

Dave: AWS, Lambdas, Azure functions, blah-blah-blah.

Chris: Yeah.

Dave: Yeah.

00:18:10

Chris: Yeah, right. Anyway, then to circle to the earlier thing you mentioned about React offering server components now, interestingly it's like they kind of do but it's just Next.

Dave: [Laughter]

Chris: I find that so strange but there's really... I think there are a couple of little--

Dave: React (*Next) offers this--

Chris: Yeah.

Dave: Yeah, yeah, yeah.

Chris: If you wanted to spend your entire next week using React server components but not use Next, I don't even know where you'd start. There's not even really docs for it.

Dave: Mm-hmm.

Chris: It doesn't seem like it's available to the rest of us - in a way. But anyway, it's in there.

Dave: Well, what about does Remix factor in there?

Chris: They don't support them. I don't think so.

Dave: Okay. Wow. Okay.

Chris: Maybe they're going to, but I don't know. Now I feel like I put my foot in my mouth.

You know when podcasters say, "Oh, no! Everybody is going to email us"? Go ahead and email us. We get ten emails a week. I think I could handle it.

Dave: No. I only get emails about having... "You should have my boss on your podcast." Anyone can--

Chris: Right.

Dave: [Laughter]

Chris: Anything other than that would be great. Those are flying in.

Dave: It'd be great. Yeah, we're cool on those, everybody.

[Laughter]

Chris: Hilarious. But why abstract this with a Lambda call? I feel like that's the final play where I'll end this is that I think Vercel possibly has that as a way, but they are more pushed towards there's just a Node server sitting there. It's not a cloud function. When you host your next site, you just have Node.

Dave: Yeah.

Chris: You don't have to bother with the abstraction of, like, better put my AWS keys in there - or whatever - however it expresses itself at that particular host. It's easier if there's just a Node server there.

Now React itself is being like, "We have--" It's almost an expectation with React server components. There has to be a server sitting there. I just feel like that's so interesting how there's... Think of all those players, all those evolutions of the tools and the hosts and the expectations of what's going on to get us here. We're kind of back at, like, "Servers are good, and you just should probably have one."

00:20:40

Dave: Gosh. Do you think that factors into the lost decade of JavaScript conversation? [Laughter] Because we did. It was like, "Servers." "No! Everybody, compile it locally. It's Jamstack, static sites." You know? But it can be JS-driven static sites.

"Oh, no! Now we've got to do serverless little baby servers that spin up and render your thing."

Chris: Yeah.

Dave: "Oh, no!" Guess what. We're all just doing a big server again.

Chris: Yeah. See. You surmised my last ten minutes in one second, so good job.

Dave: But then should we all go back to PHP? You know what I mean? Symphony, Laravel, they've gotten very good over the last ten years just slinging PHP.

Chris: Well, then the problem is there are all these spokes. You forget. When you talk that way, you're like, "Have you forgotten about the CDN spoke?"

Dave: Mm-hmm.

Chris: Because CDNs are pretty clutch, right? You can't have a PHP file at the edge. Not really.

Dave: Mm-hmm.

Chris: I think you can if you're Facebook - or whatever - but you can't if you're Dave Rupert, LLC.

Dave: Right. Right. It's not the easiest, right?

Chris: So, it's tricky. It's not that it's gone full circle. But it kind of has. You can still do any of these approaches.

I am hesitant, by the way, about the lost decade thing. It is fun to think about in kind of like a sad, "Why did we screw this up?" way. But it's like I don't think things are as simple as that.

The Web, another way to look at it is we just had a kickass decade, just incredible. The Web is way better than it ever way. It's way more capable. Way more people use it to do way more bigger, interesting things. To just wave your hand and say it was a lost decade is like, nah, it's not what happened.

Dave: Yeah.

Chris: [Laughter]

Dave: We wasted a lot of human cycles of energy--

Chris: I mean, sure, yeah.

Dave: --rebuilding crap over and over and over. But yeah, it did. There is some very powerful, interesting tech out there.

Chris: Well, that's my rendering story. All kinds of things plug into that overall story.

00:23:03

Dave: Well, yeah. I see there was a blog post recently about Astro, the future of server islands.

Chris: Yeah. We're recording a little ahead of time, so this is brand new for us. But this might air a week or two later - maybe more.

Dave: Yeah.

Chris: But yeah. What do you think of this?

Dave: Well, you know I'm going to mis-describe it, but Ginger in the D-d-d-d-discord was like, "It's HTML imports," because it's basically lazy loaded, deferred server rendering. You know? Which is like HTML imports where HTML that loads a little bit later from the server.

Chris: It looks like it handles it for you so you don't have to write a little fetch or something to go get it.

Dave: Yeah.

Chris: You've used an attribute on an element as you're building the site. Because you've told it, "This is a server component and I'd like you to defer the loading of it," that somewhere, somehow, some JavaScript is getting created that goes and gets it later. It literally says it does a fetch for it.

Dave: HTMX. Yeah, HTMX in your data, which is probably perfect for the whole comment scenario, right?

Chris: [Laughter] It is.

Dave: I have my statically rendered blog post, and then I have a server defer for comments. Right? Those don't need to be hyper-interactive.

Chris: Yeah. Good thing you knew that, though. It is kind of interesting. It puts the performance onus on you.

Dave: Mm-hmm.

Chris: You have to be like, "Oh, this is slow, so I'm going to defer it." It also puts the, like, "Well, what's going to happen to reflow then and all this?" Also, why isn't it HTML streaming?

Dave: Hmm...

Chris: Wasn't that supposed to be the--? That's some old-school technology that allows an incomplete HTML document to arrive.

Dave: Mm-hmm.

Chris: Then more bytes to arrive in the browser. This isn't even new technology. It knows how to put it in.

Dave: Yeah. Yeah, I mean it should be. Yeah.

Chris: I mean maybe there's a good reason why it isn't. But it's like... I don't begrudge Astro for this either. I love Astro. This actually looks really smart and cool and what a good API. But it's on them to market it in such a way that sounds like, "Woo doggie!" You know?

Dave: "I'm so fast." Yeah, right. Yeah.

Chris: Maybe that'll be my job someday. I don't know. I'm happy to do that, but it is like, "Okay, so it's a directive that turns into a fetch call later and a server that supports that kind of thing."

Speaking of needing a server. This absolutely needs a server. You know?

00:25:34

Dave: Right> Well, I was thinking about our offer to sell out the podcast for $100,000. Fred, you're welcome to just, you know, pony up the cash and get the ShopTalk content machine, and I think we offered slandering of competitor services. So, we will also slander competitors.

Chris: Ooh... yeah. There's a premium....

Dave: Yeah, yeah.

Chris: Yep.

[Laughter]

Dave: But--

Chris: Very valuable.

Dave: Yeah, I don't know. Yeah, streaming would be cool. Just go [tongue roll]... chuck it in because the browser is actually pretty good at that. I don't know.

It's good at, like, the whole page. I don't know how it does. I guess that's how the whole AI chatbot is going to work. They just stream in a response, right? Just keep chucking it in somewhere.

Chris: I don't know. I bet that's... However that's coded, I'm sure it's horrible. [Laughter]

Dave: I was just going to say I think islands as an architecture is also pretty interesting. That wasn't... We've had the serverless. But then this whole just islands thing where you treat everything. You try to server render whatever you can, and then you have these interactive islands just hanging out. That's kind of been a dream with, like, micro front-ends and all this weird stuff over the years.

Chris: Is the point of them that--? Is it an island even if you don't defer it? Or is the point of an island that they lazy load? Is lazy loading a separate thing that you wouldn't associate with? it's not a tenant of the island architecture.

To be perfectly honest, I don't really get it. I don't understand an island. After all this time, I still don't totally understand what they mean by "an island."

Dave: I feel like if you sliced up your page into iframes like CodePen's editor, right? You're familiar. You've got an HTML window, a CSS window, and a JavaScript window. Those are all kind of in that Flexbox thing that resizes them, right?

Chris: Mm-hmm. Mm-hmm.

Dave: Then you have another island, which would be the iframe that renders the code output. Right? That's kind of an extreme example. But then you have other things like your account would be an island. That data is going to come in a little bit later when you type pen.new into the browser, right?

Even that HTML and CSS and JavaScript doesn't have to show up on load. It can stream in as it comes from some API somewhere. Those little pieces can be, like, instead of one big page that paints all at once, those can be dynamic little pieces.

Chris: Oh, so it's the time delayed painting?

Dave: Yeah. I think if anything is lazy, loading lazy literally, or you're saying, "On DOM ready, go do this," I think that's a good candidate for an island. You try to render whatever you can, but then these little interactive islands -- and interactive is the keyword there, too -- where if it has a click handler or if it has a button, it's a good candidate for an island because you're going to bind behaviors to that later.

Chris: Yeah. Maybe it's the scoped bindingness of it that makes it that. But I still admit it doesn't quite land for me all the way because a lot of what you'll see a graphic of islands, you'll just be like, "Oh, here's this page," and 80% of it is filled with these green boxes that can be prerendered. Then there are two red boxes, and the two red boxes are islands. And they have interactive JavaScript in them. That, conceptually, I'm like, "Yeah, I get it," but anything can do that.

Whatever, dude. That's how my old jQuery sites worked. I render the page and then some jQuery would control what's happening in one of the red boxes. Some other jQuery would control what's in one of the other red boxes.

Dave: Right, right.

Chris: Was that an island or not?

Dave: Potentially. I mean I think, because it all loads in one big beefcake and one big HTML file, it's maybe less. Maybe you want to offer some progressively enhanced content. But I think, potentially, that was.

Chris: It's just a better name for it. We didn't really name it, then. That's just how the world worked.

Dave: Yeah. I think Katie Sylor-Miller named it.

Chris: Oh, yeah. Nice.

Dave: But I think it was sort of like, "Here's how we offer interactivity happens here in this place," and encourages you to prerender whatever you can always.

Chris: Yeah.

Dave: Yeah, I mean I think it's just sort of a different way to think about an application, just rather than, like, "I'm going to hit. I'm going to put div.app on the page and just render shit." [Laughter] You know?

Chris: Yeah.

Dave: Render all of God, and it's all going to be bound and chained together by some reactive controller, provider up at the top, and then everything is going to change every time that changes. Instead of doing that, you just have the interactive bits are only interactive.

Actually, Web components -- not to toot my own course at frontendmasters.com, which you can subscribe to and pay for and do -- I get $1 from it.

[Laughter]

Dave: No, I get a little more.

Web components, the server rendering story is weird with declarative Shadow DOM, but they are kind of an island. They run on DOM load. You can kind of... There are ways to chain things together, but you can think of a Web component as an island because it does take normal HTML in a slot and then enhances it to some degree and makes it whatever you're intending, so whatever. Google-map would then load in a Google Map. That's an island unto itself. It lives sort of by itself. It has little to no interaction with the rest of the page - something like that.

00:32:00

Chris: Yeah. Well, here. That was a good segue. I'm going to do a user question. I'm honestly really interested in this, too. I think it's come up before, but we're going to do it fresh.

Tom B.H. writes in. He works at an agency building sites for all kinds of clients. "I'm really keen to start turning elements we use all the time into reusable components, and I'm wondering if Web components could be the right approach."

Okay? That's the setup, but there are two specific questions. "For elements like navigation, is there a perf hit because the element has to render after the component loads, or is this kind of thinking a hangover from using client-side JavaScript frameworks?"

Let's start there. I am fascinated by this. Certainly, any of us could do this immediately. We could turn our nav tag at the top of our HTML into a my nav. Then you'd have a Web component of your navigation. And the idea would be that - I don't know. I guess I'll stop there because aren't there different ways that you could build that component that would just work differently?

Dave: Oh, Chris! You're foreshadowing a blog post I'm writing [laughter] called, "SSR: You've Got Options." Scenario one is you say my nav and nothing inside of it.

Chris: That's it. There's nothing. There are no guts in there. That means JavaScript has to run and fill it all out, which almost for sure will have content shift.

Dave: It will. You'll have a cumulative layout shift, and it will only load after the JavaScript shows up and can execute.

Chris: Most people would slap your wrist for that, would they not?

Dave: You are going to get in trouble. Jeremy Keith will come to your house personally.

Chris: [Laughter]

Dave: He won't hit you. He's not threatening. But he will look disappointed. You know what I mean?

Chris: Yeah.

Dave: Maybe say the classic dad line, like, "I wish you hadn't done that." Something like that.

[Laughter]

Dave: Or "I'm not mad. I'm just disappointed." You know?

Chris: Yeah. Yeah.

Dave: You know.

Chris: Right. Right, right, right.

Dave: That's phase one.

Chris: Somebody else would come in there and say, "You know what you should put in the my nav tag is all your navigation. You put it in there." Then you're like, "Well, then why was that useful?" [Laughter]

Dave: Totally. And I hear that question and I honor that question and I really respect that question. That's fair. Why did you do that?

I think what is where Web components are really going to shine is if you have behaviors that you're trying to maintain like - I don't know - ARIA roles like role=banner - or something.

Chris: Mm-hmm.

Dave: That you don't think some - whatever - kid in Oregon who is working on your website, your boss's cousin, is going to understand. That's a really good thing. Or maybe you are shipping just the main navigation links. Then you're dropdowns are a whole separate thing.

If you think of a dropdown behavior, you can do a details element and get pretty far nowadays. But if that's a behavior you're trying to preserve, there's a lot that goes into it. Edge to edge, where does it start, where does it anchor, where does it do all this? that's a really good place for a Web component. But that hybrid model where you say "my nav" and then you chuck some DOM in there, some Light DOM -- that's what that's called. You chuck some Light DOM in there and render it.

Chris: Yes. Okay. It can do... It could be just because you brought your own Light DOM, let's say you did put the HTML for the navigation in there, it could still help you with a variety of anything that you needed to do with JavaScript and that HTML. That's coming along for the ride.

Dave: Mm-hmm.

Chris: Your styling is likely coming along for the ride there. It can do some stuff for you even if it remains your responsibility to actually put the navigation in there.

00:36:08

Dave: Yeah, and so then there's a third heat here that is declarative Shadow DOM, which is, I say "my nav," and then inside there, I don't write the HTML. I say "template ShadowRoot mode open." That's a template tag. Then I write all my nav in there and all the template code that's going to come along.

Then the browser is basically going to say, "Oh, that's a ShadowRoot mode? I know what to do with that."

Chris: Oh...

Dave: "I'm going to just make a Web component here. The JavaScript is coming later." Okay?

Chris: I see. A slight tweak on bringing your own Light DOM. You could also bring your own Shadow DOM if you want.

Dave: You can bring your own Shadow DOM, which, in this situation we're talking about here, I would probably just do the Light DOM. But in a situation with a Web component, you have slots. You have title, slot name equals title, slot name equals image, and you can kind of reorganize the component as you go.

You may have a component that's more like that that you want to do kind of a hybrid of Shadow DOM templates, and you want to do Light DOM fallbacks and stuff like that. You have kind of this--

Chris: Yeah.

Dave: --option to build that up. Now you're saying... I know what you're saying. You're saying, "Oh, if I'm doing this all by myself, I should just write the Light DOM and not even use a Web component." I probably agree there, actually. But there are components like... or frameworks like Fast, which is the one I'm working on now, and Lit. They offer SSR, which goes, scans your component, and tries to generate out (based on your props and whatever) the ShadowRoot.

Chris: And it does this with... A) that's amazing. I didn't even really know that. I was wondering; can you spin up a Puppeteer or something that renders the component, grabs what it finds, and then puts it in a little declarative chunk? Can something else do this for me?

00:38:19

Dave: There is stuff that can do that for you. It does have a tooling cost, right?

Chris: Sure.

Dave: Sort of like a "How are you going to get this out?" cost. Frameworks like Enhance, which I should say has a really cool thing where it's like using WASM to do this, like you have to kind of write special enhance components, but it'll say, "Oh, if there's no interactivity here, boom, I'm going straight to, like, I'm going to just spit this out as HTML." It kind of has this fast track to spit that out. That's pretty cool.

11ty is sort of the same thing. It has that WebC flavor.

Chris: But in both cases, they're not just any old Web component. They're their specific brand.

Dave: It's kind of like their brand of Web component. I would put Astro files kid of in the same category there.

Chris: Sure.

Dave: But it's very Web component inspired - if that makes sense.

Chris: Mm-hmm.

Dave: In that framework situation.

Chris: It's funny. At this point, if you really want SSR, you're picking some tool thing, a branded tool. The tool doesn't seem to exist that will take any Web component and help you SSR it.

Dave: Yeah.

Chris: That doesn't seem to be there yet.

Dave: Yeah, and there is... There's a repeating cost, too, like if you were doing list items and you had a card component or something like that. You're going to write all that Shadow DOM template code in your Light DOM all by hand. Probably not. You want a tool to do that, like some sort of bundling tool.

Chris: Yeah, Next.js. You want to be really cool? During your build process, why don't you spin up that Web component, figure out what it does, and build a little declarative DOM thing for me for the output? That'd be nice.

00:40:05

Dave: Yeah. What's kind of neat about these tools, which again I need to put in my little post, is that shadow template. If you have a template, an actual template, in your Web component, like a render function in a Lit component, it'll override the template. So, you can build out a skeleton screen with your little fake text sort of deal.

Chris: Oh, right.

Dave: If you wanted to do something like that, or you know, "Hey--"

Chris: They don't have to match, in other words. They could be different.

Dave: Yeah. Yeah, the emoji reaction piece just isn't coming. I'm just going to draw an oval with a happy face emoji. Then they'll fill in later. That's an option as well.

All this to say you have options when rendering Web components server-side. There is sort of a proposal for this whole idea of declarative custom elements that's being worked on in the Web component working group. That's... I don't know where it's at, actually. I've heard mixed reviews. I've heard somebody being like, "We're doing it." But the declarative custom element idea is just how we bring this more... If I just say "my nav," how can I just make it my nav and not really use JavaScript? How does it find the template and figure out what it's supposed to do?

Chris: Oh, wow. Yeah. I had never really thought of that, but there's starting to be more target stuff happening in HTML, right?

Dave: Mm-hmm.

Chris: The way popovers work, how you can target a popover and it can reference... The button can open it or close it.

Dave: It's called reference target now is what it's--

Chris: Oh, well, there you go.

Dave: Yeah. [Laughter] But yeah, and that's also in this cross-root ARIA thing, like, how do I chuck ARIA down into a Web component to associate a form label and form input inside my component?

Chris: Mm-hmm.

Dave: That's sort of like a separate spec. But when you get into this declarative custom element spec, you sort of very quickly... I think Justin Gagnani, who has been on the show. Very quickly, I think you get into a situation where you need templating natively in HTML, like a way for if statements and for loops (at a minimum).

Just because you're like, "Hey, I'm going to go... I want to render this component with some posts. But if there's no post, just say no posts. But if there are posts, then render all the posts." Right?

Chris: Hmm...

Dave: I think that's sort of--

Chris: Even an iterative thing. That's cool.

Dave: Yeah. Yeah. How do you do that? I don't... I'm sure that has to be JavaScript at some point because where is it getting the posts from. But maybe that's the other question is, like, can it just...? If I have a global post variable somewhere, can it use that, or can it use this new signals thing to pull from a signal or something like that, so yeah.

Dave: Hmm...

00:43:12

Dave: Who knows, man. I think that's all kind of future stuff, five to ten-year timelines, probably. Just that idea. Eventually - I don't know - Web components... This was a show about rendering and then we get into Web component rendering, which is, I think, valid. I don't know. That's what I'm doing it for work, so that's fine.

Chris: Oh, absolutely.

Dave: But I think it's going to change this ultimate story of where do you render things and how do you render things. It can make it more HTML, more server-side, whereas we've been kind of relying on framework side, which maybe that's another. Maybe that's the thing that's not in your story. But we have framework-side rendering right now. How do we get it into more just server rendering, HTML rendering?

Chris: Mm-hmm.

Dave: That's a blog post: framework side rendering. I need to write that.

Chris: Yeah, perhaps.

Dave: Okay. That's a really good one. That's a really good one because, so Vue, Nuxt, right? I use Nuxt for Luro, and I turned on SSR because I was like, "Heck yeah. I have a Node server." I started out doing this--

Chris: Nuxt has SSR, too? Like Node kind?

Dave: Yeah, yeah, so I started out with serverless. It was just like make it easy on myself. Everything goes and hits a serverless function and kind of renders out, right? Slowly, that became a bottleneck, so we added a server. The server is doing fine. It's rendering server-side pages.

Chris: Yeah.

Dave: Well, literally, I thought it was rendering DOM, Chris, for years - a year and a half, two years. I finally look in the browser and it's not.

Chris: It's coming down as JSON?

Dave: It's just JSON.

Chris: Ew.

Dave: In a body tag, and it's fast because the components are there, too, or the page component loads. The JSON is there, so it skips the fetch call, the async fetch call, right? I was so disappointed. I just was like, "That's not server-side. That's just like skipping a line of code," which is to the tune of 500, 600 milliseconds.

Chris: Yeah. Your SSR should be more meaningful than that. Yeah, it should be like--

Dave: Yeah.

Chris: "You should produce HTML that the page uses.

Dave: And you figure out how to overwrite that when all your real stuff comes in, right?

Chris: Well, especially when the reason I'm doing this might be because Google, because Googlebot, or whatever. I want this to be readable.

Dave: Nuxt, whatever, it's a challenge. I'm not going to throw anyone under the bus there.

Chris: Yeah.

Dave: But I was personally disappointed in that strategy. I thought it was doing something more sophisticated in the HTML. But it was not, and so that was just... I don't know. I think if I could turn back time, I would probably rewrite the thing in Rails. [Laughter] That would probably save me so much time and effort.

Chris: Yeah.

Dave: But DHH is weird, so that's another problem.

[Laughter]

Chris: Dude, I still pick software to this day. There's one crazy at the top. I tend to be like, "Nah."

Dave: Yeah.

Chris: Even though... I feel like it's a little hypocritical because there's always a secret crazy.

Dave: There's always.

Chris: I always ... all these companies that I like, I'm like, "I don't know anything about your board of directors. Do you think one of them is--?" We wouldn't see eye to eye.

Dave: Oh...

Chris: Yes, but they've made the smart choice to not say anything.

Dave: There's always a super Republican somewhere near the top.

[Laughter]

Dave: Not to get political.

Chris: Sorry, everyone. Sorry. Sorry, folks. Yeah.

Dave: But just in the sense of, like, there's always somebody you're going to disagree with in the chain of events.

Chris: Yeah. I'm sure I could find some people I disagree with on both sides.

Dave: I'm an equal opportunity discriminator.

Chris: Disliker. Yeah.

Dave: Yeah. [Laughter]

00:47:28

Chris: I had one little note here--speaking of all these frameworks and stuff--when a major version changes, and nobody knows better than you living through the Nuxt. I don't even know what happened there but it didn't seem great.

Imagine you're on... I have to just talk from my own perspective because I use Next. I still use it at work, right? I've been using Next.

Dave: Yeah.

Chris: Literally today, I've got a branch upgrading. For a while, we were on Next 12. That might be a little old to some people. Sorry, folks. When we started, that's just what it was. Then we were really busy working on stuff and didn't make upgrading a big priority. Right?

But then Next 13 came along. We didn't upgrade to it. Now Next 14 is here. Now we're two versions behind. But when you're using a framework like that, those are meta frameworks, of course. The actual framework is React. We're also on React 16 or 17 or something. The newest one.

Dave: Probably, yeah, 16.

Chris: It was 18, right?

Dave: Yeah.

Chris: First, we do that. That's in. We're just releasing it today. Big deal. Nobody will notice anything, right? But it has stuff in it. It has new stuff in it that sometimes the meta-framework needs.

Plus, why upgrade two things at once? We're adults now. We'll upgrade one and then we'll upgrade the other. That's how adults operate - just so you know.

Dave: They try to, yes.

Chris: Yeah. [Laughter] Well, one of the reasons... I don't even care that much. This is not... I'm even a nerd. I even like talking and thinking about this stuff. But when I'm working on software for the users in my app, I don't care what version we're on. It really doesn't matter to me. It's not a top priority thing. I want to work on a feature. I want to work on performance. I want to work on something that matters - not just a version.

But it comes into play because you go to look anything up and you can't fricken' find what you need. We're upgrading specifically, at least one of the major factors, because the docs suck for the old version. I can't find what I need to look up for these older versions that are not that old.

Dave: Wow. Yeah, yeah.

Chris: It really is frustrating to me that we're making technological choices based on the unavailability of slightly older docs.

Dave: Hmm... Chris, could I interest you in Web components? They rarely change.

[Laughter]

Dave: They change once a decade.

[Laughter]

Dave: No. Yeah. Yeah, you go to the docs, and it's like, "Oh, of course, you use the use spatula effect," and you're like, "What's use spatula?" [Laughter] I don't know how to use spatula.

Chris: Oh, then I type it in because I like to let it auto-complete in VS Code and be like, "Oh, it's not even auto-completing because it's not available in this."

Dave: Yeah. Yeah.

Chris: A classic one in my Next land is there's a nice one that I really wish we had called "use search params," I think it's called.

Dave: Hmm... Yeah. Yeah. Yeah.

Chris: Just grab the query parameters from the URL. Well, it's not in Next 12. Can't have it.

Dave: Ugh!

Chris: So, you've got to use query instead, which is some router thing that's built into Next. That's fine. It's just not as convenient. Or it can't quite do what we need to at all, and this is crazy. This isn't all over the app, but there are moments where we have to use React router, which isn't... That's not what Next has. They have their own thing, and they don't play together super good.

All I just need is this one little hook. You'd think changing versions is no big deal. But of course, it is.

Dave: Yeah. Oh, yeah.

Chris: The way that Next 14 deploys, it's just different because of, partially, it's just assumption that a Node server is there. There's one there for our Next 12, but it's just different.

There's just stuff. I can't even articulate it exactly. There's 100% change that this version is going to cost us at least a couple of days. Yeah?

Dave: Oh, I mean you're talking major versions. I think even in point versions. It's like that token machine, the token tower game that you play.

Chris: Yeah! Hell yeah.

Dave: Even a point release is just putting a token in there.

Chris: [Laughter]

Dave: And it's either all going to come crashing down--

Chris: Right, right.

Dave: --or maybe you're fine. And then a feature release is like 20 tokens, right?

Chris: Yeah.

Dave: Then a big one is like 500 tokens.

Chris: Mm-hmm.

Dave: It's not easy.

00:51:49

Chris: I feel you. It is this. It is this. Well, I have one link in here that I realize you don't speak for all of Microsoft. It's going to come up a lot, I think, going forward.

It was interesting that they announced at the end of May with a blog post that said an even faster Microsoft Edge. It said, "We're rearchitecting some of how the browser works," a little bit closer to the metal UI choices, and now the browser itself is quite a lot faster.

It took me a while to wrap my head around what was going on. Is it faster for websites? They're like, "No, it's faster to just open the browser. To use the browser is faster because the UI that builds the UI of the browser itself is faster.

Dave: Yeah.

Chris: I somehow have never thought about that. I don't know.

Dave: Yeah, no.

Chris: It better be fast.

Dave: This is kind of more like Alice Russel's domain.

Chris: Mm-hmm.

Dave: But notably, the project I'm working on is being consumed by Edge, so the code I'm writing is going into Edge and impacting that UI, so that's cool.

Chris: Wow.

Dave: Yeah, so Edge is a consumer of my project.

Chris: Interestingly, it was built with React, originally.

Dave: It was built with React originally. This is sort of answers the question of, like, why don't we just put React in the browser? Because it is in the browser currently.

Chris: Yes.

[Laughter]

Dave: It's maybe not the fastest. But they switched over a couple of setting screens or, it looks like in this post, they did the one, like the insights. I have it right here but I forget what it's called. Browser Essentials, it's called Browser Essentials, and it basically tells you how many ads got blocked, how many sites got scanned, and stuff like that.

Chris: Yeah.

Dave: Sleeping tabs, memory savings, and stuff like that. They say Interviewer: his blog post it's 42% faster now with this kind of refactor in the UI. But notably, it's 76% faster for SSDs with less than 8 gigs of RAM or devices without SSDs and less than 8 gigs of RAM, which is a lot of computers, a lot of PCs.

Our Macs all have SSDs and 9,000 gigs of RAM, but you've just got to think of this kind of global perspective for Edge and how it's operating. That's pretty significant. The video tells the story on this blog post. It's the difference between five seconds and one second. Which one do you want?

[Laughter]

Dave: Do you know what I mean?

Chris: To me, even that feels wild. I'm opening a panel in a browser; it should not take one second. One second, that's insane. It should be zero seconds. [Laughter] I don't know.

Dave: Yeah. Yeah.

Chris: I somehow think of native app UI, like it is, as being C or something, like low-level stuff. [Laughter] Why is there any delay at all to open a panel?

Dave: The secret is HTML is really... and JavaScript. I'll put--

Chris: Yeah.

Dave: HTML is a really good UI language, and CSS is really great for styling. Writing all that stuff in CSS, C++ and Lua or whatever you're using, is not Rust, is not that great. Writing your own UI...

Chris: I can see that. But isn't it--? It's a Windows app, right? Don't they have that crap as primitives already?

Dave: Yeah, they have .net and XAML and zool and all this stuff, but I think it's basically, when it's under the hood settings, it's easier to use Web tech because it has a renderer inside of it, a Web renderer.

Chris: That's true.

Dave: There's probably nothing faster than that.

Chris: Some kind of cool dog fooding happening there, too. I like that part.

Dave: Anyway, yeah, I can't obviously... I don't know much beyond what's in the blog post.

Chris: It sounds like some good choices being made, though. I've seen more and more people using it. A little turnaround, I feel like.

Now you used Edge for a long time.

Dave: Yeah.

Chris: I feel like it got weird for a minute, but now it's back.

Dave: I'm back on Edge. It did get weird. It got a lot of features added. I have hammered mine to basically be Arc. [Laughter] I've been working--

Chris: Oh, really? You've got the left sidebar even?

Dave: Yeah. I'm like left sidebar. Killed the Windows Essentials sidebar thing. I've hammered it down to be about as Arc-y as possible.

Chris: Nice. Yeah. I've heard some good things about the dev tools in there, too. They kind of tend to roll first with some cool features.

Dave: The dev tools are actually cool. It's maybe a smidge more handsome than the Chrome defaults and what's in Arc.

Chris: Mm-hmm.

Dave: There are some themes you can add and stuff like that. But I like it. I think it's very... It works for me, I guess, is what I want to say. But I don't know. I do miss... There are features of Arc I miss.

I've got to get going. I realized it was a hard stop.

There are features of Arc I miss copying the URL. God, it's so needed. The automatic picture-in-picture video, oh, that's so good. Then I think I had one more, but I forget it now.

Chris: Yeah, command-shift-C, people. I use it 500 times a day.

Dave: Command-shift-C.

Chris: Oh, my god.

Dave: Oh, man. All it does is open up the Web inspector console for me, and that's so disappointing. [Laughter]

Chris: Boo!

Dave: Boo!

Chris: You have to write a little extension.

Dave: I might have to write Arcify...

[Laughter]

Dave: Chrome extension .exe. Anyway.

Chris: Alrighty.

Dave: All right. I do have a hard stop. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Mastadon in the place and join us in the D-d-d-d-discord, patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Oh... ShopTalkShow.com.