Paul:
Hi there, and welcome to PodRocket. I'm your host Paul, and today we're joined with Rachel Smith, who, according to her LinkedIn, is literally the worst developer, and she writes awful code and has a terrible attitude. Which you can go find for yourself. I highly recommend you don't go look at her LinkedIn. But jokes aside, Rachel Smith is a developer over at CodePen. We're going to be talking about islands today in web development. Welcome to the podcast, Rachel.

Rachel Smith:
Thank you for having me. Thank you so much.

Paul:
I'm excited for this one because I don't know much about the whole island mentality. It's weird, I want to say old school web developer now. Because all these new things are coming out, but it's like that's how it's been. Can you tell us, really quick, what is an island? Why are we talking about ... using this verbiage?

Rachel Smith:
Yeah. Myself, I don't claim to be an expert on this at all, myself, because I'm not a developer advocate. I'm just a developer observing the world. So, it's not really my job to keep on top of this stuff. Which is why when I kept seeing the word islands architecture and islands coming up, I was like, "Well, what does that mean?" I was a bit confused. So, when I went and looked it up, it seemed like the description of islands and island is ... or islands architecture is when you render most of your website with HTML, and then you just add interactivity in these islands with JavaScript. Which is strange to me because I thought, "Isn't that just like ..." As someone who was developing websites, I think I started 12 years ago, I was like, "That's just what we used to do before single page apps came along." So, I was a bit confused why we had a whole term for it, at first.
I think the reason there is a term is because of the proliferation of single page apps. When you've been around a while, it might not be clear to you that a lot of people coming into front-end development in the last five years have only had exposure to single page apps. So, they haven't had the experience of ... It sounds crazy, but they haven't had the experience of building a website with HTML, and then just layering in some JavaScript to make it interactive. The all JavaScript approach is the only thing they know. I think that's why we have islands now. This term of islands is to bring back this concept of, "We don't need to build the whole entire app or website with JavaScript, should use HTML in the first place."

Paul:
Island's made intuitive sense to me because I'm one of those people that you're talking about.

Rachel Smith:
Right. Yeah.

Paul:
Right? You've probably been doing websites way longer than I have. I've used React, some Vue. But, if you are using an island, do you use a framework, similar? Are there frameworks that lend themselves really well to the island way of doing things? Or is it brought back to how I did example websites when I started web development with those pockets of JavaScript?

Rachel Smith:
Yeah, it's interesting because I think that, from what I've seen, the concept of an island, it could be achieved by using jQuery, for example. That's the first thing I thought of when I read the description of an island. It sounded just like ... I used to build WordPress websites, for example. WordPress would render out all the HTML, that would be set aside. And then if you wanted to add something, like AJAX to ... interactive to the site, you would use jQuery to do that. You would create an island, I guess, by selecting some of the HTML that's being rendered, and then manipulating it with JavaScript. That satisfies the idea of an island.
But I think the reason the terms come about is because a lot of these newer frameworks are putting in their description, "Oh, we support islands." I think that's to distinguish them from your single page app type frameworks, like React and Vue, where it's not one piece of the site is built with JavaScript, it's the entire view is built with JavaScript. So, they use this, "Oh, we use islands architecture to try and differentiate themselves from that." I think with the newer frameworks, it's a little bit more sophisticated, I guess, than just serving some HTML, adding a bit of jQuery.
One I use, for example, that says they support this island architecture is Astro. I use that for my website. Comparing the developer experience of using that versus the way I used to build sites 10, 12 years ago, it's wildly different. It's got all the nice developer conveniences that we've come to expect with modern frameworks, but the output is similar to what you would've built back then when you were serving some HTML, and then you're adding some JavaScript to make it interactive.

Paul:
Do you think that we run a risk of overcomplicating what should be fundamentally a basic idea of just shooting some HTML, and be like, "Hey, do ..." What if Facebook they made into an island architecture? Oh, God. There are going to be so many islands, it would just be a continent. So, there's a line, there has to be aligned somewhere, right?

Rachel Smith:
Yeah. That's funny. I really think the term island, it's a marketing term. Because it's not a new concept, it's an old concept. I don't want to go as far as saying ... Because a lot of people who sort of come to this stuff with the attitude of like, "Oh, we're just going back to 10 years ago. We've made no progress, we're just going in a big loop." But it's like, that's not true, because I feel like anyone who's saying it's just it was 10 years ago maybe wasn't building websites back then, because the experience of building a website is completely different now. We haven't gone in a 10 year loop and ended back where we started. We are light years ahead of where we were 10 years ago, as far as how quickly we can build websites and how we can have componentry and design systems, and all this stuff that just was not a thing back then.
But the term island is a marketing term because the idea of it itself has existed long before SPA. So, it's just a term that you need to differentiate yourself from a single page application framework. You're like, "What's a cool term that we can use, that when developers understand what it is, they can go, 'Oh, this framework is not like React. It serves HTML first and then it adds ... layers some JavaScript on top.'" It's a marketing term. So, yeah, it is confusing. I didn't understand it at first. I had to go look it up. But I guess that's what we do in development. We're always wrapping our heads around the new made-up terms. Even like the acronym SPA, 10 years ago didn't exist. Or MPAs, as they call them now, were just websites back then. But now we call them MPAs. CodePen is an MPA, but it was just a website before React existed. Yeah, the terms are made up to, I think, wrap our heads around the differences between these tools and technologies. But yeah, it can be certainly confusing.

Paul:
Helping us wrap our heads around the differences in these paradigms and technologies sounds like a very good way to bucket what we're observing happening. Maybe it's being overdone a bit, which can give it the marketing...

Rachel Smith:
Yeah. It's marketing and it's developers. We just love to complicate things and come up with, "Yeah, make everything a special term or a special concept because we're so clever. We all love to be clever and come up with our own terminology for stuff." There's a lot going on there.

Paul:
Over at CodePen, do you folks practice island architecture in the way that the CodePen website is built, or is that all traditional React?

Rachel Smith:
Originally, our Rails app was islands, I guess. Because before we rebuilt a lot of it in React, it was a Rails app. You had Rails render all the HTML. And then we would make certain pieces of it work with jQuery. Actually, the CodePen editor itself still works that way because we haven't updated that editor in ... We've improved on it, but we haven't rebuilt the bones of that editor since it was first built. I think, I don't know, maybe eight years ago it was feature complete in a lot of sense. So, that app is still Rails rendered, and then there's a whole lot of jQuery going on, powering it. You could say each little piece of that app is an island, in a sense, because it's like the HTML was rendered by the server, and then every bit of the app that needs to be interactive, so the panes you're typing into, the drop downs, the settings, all that stuff, they're all islands because they're all using jQuery to make them work.
But the CodePen homepage, for example, we rebuilt that in React. I think it was about ... it would've been not long after I started. So, maybe four years ago, four and a half years ago, we rebuilt that in React. And now, that is just ... CodePen's like a multi-page app, but then you have sort of single page apps within the multi-page app. So, you load the homepage, and then the homepage, which lets you choose between your following tab or your trending tab, and these different tabs, that could be considered a single page app, because that whole thing is rendered in React. So, if you don't have JavaScript turned on in your browser, you just get a blank page on CodePen. With a message to say, "You need JavaScript to run this website." So, it's not an island because ... It doesn't use islands because, if we were to approach it with an islands approach, we would render that page out as much as possible with HTML, and then just add the ability to change ... move through the grids with JavaScript.
The reason we went that way is because there was no real option to get all the niceties of React, like the componentry, hot reloading while you're in Dev, all these conveniences of building with React. When we were redoing that homepage, these other frameworks, like Svelte and SvelteKit and Astro and stuff, they didn't exist. So, that was the only option.
I think looking forward, if we ever get the time to, there's a million things to be done in CodePen and only seven people work there, but if we ever get the time, I imagine a world where we would try and move back to the island architecture for the rest of the site. Because it's not great that you can't see any of it without JavaScript. CodePen, we could somewhat justify the need to have JavaScript because, I mean, people write pens that use JavaScript. if you don't have JavaScript turned on, a lot of CodePen's going to be broken for you anyway, in terms of the demos.
The complaint people make, a lot of websites on the web are not CodePen. There's no reason you need to have JavaScript turned on, and yet, the site will not work because you haven't got it turned on. That's one of the heavy criticisms about single page apps and their frameworks is you're really screwing people who don't want to have JavaScript. When, in a lot of cases, it's not really necessary to do that.

Paul:
Almost wasteful maybe, because you're just sending a lot more stuff that you might not need to. We had a guest on last week, which ... Speaking of which, if you're enjoying the podcast and you want to hear more about web dev topics, developer topics in general, we have them coming out every week. So, please tune in and check out some of our previous episodes. One of which I'm about to mention.
We spoke with... I guess he was talking about the cost of actually sending information over the wire. It's kind of crazy. Once you get to, well, your app is, let's say, 200 megabytes, which is huge. I acknowledge that. But let's say you're sending 200 megabytes and you send it a couple thousand times, it's going to cost you hundreds of trees worth of CO2 to send that, actually move those bits around. I think I've noticed some other frameworks or projects coming out that have an environmental ethos almost. They're like, "Hey, this is better because, yeah, it's faster, but who cares because everything's so fast, we just want to save the trees." That's always respectable because I don't need it faster anymore. Personally, I'm fine. We have high speed internet, at least where I live. So, I'm happy.
But yeah, in saving space, maybe you could have more space used with islands. Is that possible? Let's say you had islands and in each island you repacked pieces of JavaScript or of library that you could use distributed throughout those separated functional pieces. Is that a risk or am I thinking about it in an incorrect way?

Rachel Smith:
That's an interesting question. I think, yeah, you could ... I haven't gone too far into thinking about optimizations beyond the level of ... Theoretically, using islands architecture is already a big optimization over having a big bundle present to be able to even render your massive amount of JavaScript to make the page. If you're just serving HTML and then ... Just, it's way less JavaScript just adding the JavaScript on top in these islands.
But yeah, I think you could go further to optimize your ... I guess your island bundles and how to cache them in such a way that they're only being downloaded once. Yeah, I haven't gone that far myself because I've only dabbled in this new islands architecture in my own website. There's very little interactivity going on in my website. I've got a canvas animation on the homepage, which ... That's one thing I really like about islands is before I became a mom and got too busy to do side project coding, I used to do a lot of animation work. That stuff has always been kind of tricky within React. Really, when you want to animate, especially with a canvas, you just want to hook into the canvas element and you want to do stuff with it.

Paul:
Yeah, just give me full control.

Rachel Smith:
Yeah, exactly, with some JavaScript. When you're dealing with a traditional website, and that canvas element is just sitting in the dom ready to go, there's no virtual dom, there's no re-rendering, all this stuff. It makes it a lot easier to do that sort of thing with islands architecture than it is within Vue or React.

Paul:
Do you feel like you've been brought home a little bit in your development approach because of that access to the basics again?

Rachel Smith:
Yeah, in that aspect. When I first used Astro, I was like, "Oh, my God, yes." Because one of the reasons I've haven't been doing a lot of animation is because I've been largely a React developer for the last five years. I just find doing any animation work in React just sucks the fun right out of it. But now, with Astro, I'm back to my roots of just like, "Okay, I have a canvas element. I have some JavaScript. I can do whatever I wish with it," and that's been really nice. So yeah, it'll be good to add more of that stuff to my site when I have time. Or just do more animation stuff within Astro. It's exciting.

Paul:
Because of the emphatic, cathartic "yes" when you finally got into Astro and made an animation, would you recommend that being ... like if I wanted to try making an island? I like animating things. I'm probably nowhere near what you do. I go up, down, bigger, and smaller. But let's say I wanted to make the ball bouncing around, would downloading Astro and maybe trying to do something with a canvas be a great way to start trying out an island architecture?

Rachel Smith:
Yeah. I think it's interesting ... Astro is interesting because you could bring your React, you could bring your Svelte. I think it supports a few other sort of frameworks. So, you could do some islands with React, but then you could also just do some with just bare bones JavaScript. My animation stuff is just ... it's just a Astro component file. And then they just let you put a script tag in there, and it's just client side JavaScript. Yeah.
What's nice about it is it's kind of like where people like using CodePen because they can get a pen, and they've got HTML, CSS, JavaScript. You can just make a demo quite quickly. There's no build processes or anything getting in your way. I mean, Astro is still a build process and there's still things that could potentially get in your way there, but it does feel very sort bare bones, close to the metal. "Oh, I just want to make a page that has some animation in it. It just needs some CSS and some JavaScript, or some HTML elements." Astro won't get in the way. You're not having to jump through a bunch of hoops to just do a very simple thing. So, I would recommend it. It's a cool library.
There are others out there. I haven't tried them because I just simply do not have the time. So, I just picked one and it works. I like it. So yeah. If anyone's going to build their personal site, I would recommend picking one of these frameworks. Even if you are a React developer, you can still bring your React knowledge to a project like Astro. But then, I mean, most people's personal websites are a portfolio of some kind or a blog. You don't need that to be a single page application. Most of the things you're doing can just be satisfied with HTML. So, I think picking up one of these islands architecture frameworks makes sense, from that perspective.

Paul:
Yeah, the personal page sounds like a good low-hanging fruit to experiment with. Because also, it's zero risk. I find personal pages are also a good way to try new stuff out, because you feel creative, you get the barriers removed so you can mess around for real.

Rachel Smith:
We love to stress over our personal websites. Be like, "Oh, I hate the design. I hate this and that." But really, people barely see it. The traffic... Unless you are Chris Coyier or something, the number of people coming to your personal website is pretty low. So, it's fine, you can just try different things.

Paul:
Yeah, you need to take a step back and do the, "Sir, this is a Wendy's."

Rachel Smith:
Yeah, exactly. To yourself.

Paul:
To yourself.

Rachel Smith:
Yeah.

Paul:
For somebody like me, who ... I've read about islands. I've read your blog posts, which we can also link under this podcast for anybody that wants to check it out, that Rachel wrote. If I want to start orienting my mind in a stronger way around how you might have developed 10 years ago, would you say there is a YouTuber or another set of blog posts, or another writer that is really good to read or listen to? Or would you just say, "Listen, if you've done web development, just go try it. You'll start to see where things work and where things don't work"?

Rachel Smith:
Yeah. I'm trying to think of someone who's ... I can't think of his name. Do you recall the name of the creator of Svelte?

Paul:
Yeah, Richard Harris.

Rachel Smith:
He is a really interesting person to follow. He's pushed this sort of idea of reducing the amount of JavaScript that you ship on a site. I don't know if Svelte actually claims to be islands. But it's sort of along the mindset, at least, of you don't need to have these hulking big JavaScript apps to make content. I think he's a really interesting one to follow. He has really good ideas. I've just seen a few of his talks and stuff. There's a really interesting one about multi-page apps versus single page apps. He sort of thinks there's a middle path. Which, I think, if you're someone who's only built single page apps in your career, that's a really interesting person to follow because he sort of pushes people to think beyond, "I'll just render everything in JavaScript." Yeah.
If you are someone who's only done single page apps, I think it's just ... It's interesting, because for someone like me who did multi-page apps or websites first, I always think of single page apps as the weird thing to do. But for a lot of people, who've only started developing in the last five years, might find this multi-page app idea strange. I guess it's just you have to shift your mindset to, "How much of this website could I just do in HTML? How much of it really needs to be JavaScript?" You sort of take that approach. So, you render as much as you can as HTML, and then anything that requires some interactivity, you bring the JavaScript in.
It's a bit different because once you are doing things that way, you have to think about how you would deal with state and connect islands. That might be a thing that comes up. So, it's a little funky to get your head around when you're so used to just an app, and having state proliferate all through the app and all through the components, and every piece of information on the page. That's why we all went to single page apps in the first place because we felt like we needed that for a lot of situations.
Just try it out. For me, I did multi-page apps or websites first. I found React extremely weird when I first started using it. It was quite a funky thing to wrap my head around. Now I've been using it for years and years. It's like, "Whatever, I'm used to it now." I feel like you could just have that same thought process going the other way. But it just takes practice. Just try it out. That's always been my motto. I'm not really a, "Oh, I'm going to learn and learn tutorials and do stuff." I would just jump in and start doing things, and I would recommend people to just try it out.

Paul:
A lot of people who we have on the podcast are similar, people who make a lot of things. So, that's a sign.

Rachel Smith:
Yeah, I think people who are especially prolific, like my boss, Chris Coyier, is one of the most prolific people I know on the web. The amount of content he has created is just next level. That's because he just does not wait. He just starts. I even see this at work. I'm even a little bit more like, "Oh, I should research this and I should find that out." I sort of dilly-dally a little bit before I get into things. He just starts. He just starts making it and doing it. That is why he is so prolific on the internet. So, it's definitely an attitude you need to bring if you want to create a lot.

Paul:
Hey, Nike had it since day zero, "Just do it." Alrighty. Well, we're kind of running up on time. Rachel, if people wanted to follow more about you, are you writing anywhere else that we can point folks to?

Rachel Smith:
At the moment, I'm just updating my website. That's rachsmith.com. You can follow me on Twitter if you like. I quit Twitter for two years and I've just come back recently. I am wondering if that's the right decision. But at the moment, I'm there hanging out. @rachsmithtweets on Twitter. That's pretty much me. Oh, yeah, come check out CodePen. If you haven't used it before, definitely come and check it out. It's a really fun place where you can make code demos and see other people's code demos. If you want to get your work out in the world, it's an excellent place to do it because we get millions of people using CodePen, looking at the homepage. So, if you want to get your work on the homepage and get some eyeballs on your work that way, it's an excellent way to do it. So, check out CodePen.

Paul:
It's the YouTube of code, don't sleep on it. It's good stuff. All right, Rachel, thank you so much for your time.

Rachel Smith:
Thank you. Thank you very much for having me.