Rich Harris: There's a ton of innovation happening in front end frameworks at the moment. We've got things like react server components, which are this kind of fundamentally new paradigm, and there's a lot of really good energy in the space at the moment. Noel: Hello, and welcome to Pod Rocket. I'm Noel, and joining us today is Rich Harris. Rich is the creator of Svelte. He's joined us on the podcast before. I'm really excited to talk to him today. How's it going, Rich? Welcome back. Rich Harris: Great to be back. Thanks for having me. Noel: We've got a lot to talk about, especially with Svelte and stuff, but before we get into that, I want to talk a little bit about Svelte and Vercel and that relationship, and that merge, how that's felt for you, if you're excited about it, if there's been any problems. How does that look? Rich Harris: It's been great and it's been, I think, let me see. I joined in November '21, so 15 months at this point. I've got my feet under the desk, and it's pretty much everything that I hoped it would be. I joined Vercel from the New York Times with a remit to work on Svelte and SvelteKit full-time. There was a lot of conversation about what that was actually going to mean in practice, where I'd truly be able to spend my days working on open source, because that's kind of a dream job. That's exactly how it's transpired. It's been really great, because I get to work on a project that I care deeply about full-time, but I'm also in Slack channels with some of the best engineers on the planet, a lot of the people who work on Next JS, so we can talk about ideas. A lot of that stuff feeds from Vercel back into Svelte, but it also goes the other way a little bit, because I'm there almost as a privileged user of Vercel systems. We get to test out new Vercel features before anyone else and we get to give feedback on how they work. It's been this really great mutually beneficial relationship. I love working there. Noel: Nice, nice. That's awesome. Has that new relationship changed how you think about things and prioritize? For better or worse, has it impacted that workflow much? Rich Harris: It absolutely has. For many years, was just an evenings and weekends project for all of us, and that's still the case for a lot of contributors. We have this pretty wide contributor base, including a core team of people who work on a mostly volunteer basis. That's great. We managed to get the project to a pretty decent state on that basis, but it does kind of prohibit you a little bit from thinking big picture thoughts about the architecture of a project. Having the ability to think, I've got 40 hours this week to work on this project, what do we want to get done at the end of that 40 hours has definitely been a step change in not just the development velocity, which is kind of obvious, but also the kind of scope and the ambition of what we want to take on. That has really accelerated since Simon Holthausen joined Vercel as well, so he is another full-time Vercel employee working on Svelte, there's two of us. Having two people in that state, we have regular meetings on what we want to work on together. It's kind of forced us to be a little bit more organized and professional in how we schedule our time, and how we communicate the things that we're working on, and so on. It's been very good. We probably should have had that professionalizing influence much sooner. This is I guess how real software projects have developed. Noel: Nice. Yeah, very cool. It has that kind of capacity to work just dedicated on this full-time. Has that contributed to the release of SvelteKit 1.0, you think? Would that have taken longer had you not had that kind of support? Rich Harris: It would either have taken much, much longer, or perhaps not even happened at all, or we would've drawn a line in the sand much sooner and said, "Well, this is what you get." It would've been a much less good framework. Some of the biggest changes came towards the end of the 1.0 release cycle. We were making some very substantial changes to how the router was designed, and how data loading was designed. I don't know if we would've had the capacity to do those, and so we would've probably just shipped something that was done but much less good. It's hard to know what would've happened in that alternate universe, but I'm glad that we live in this one. Noel: Sure. You mentioned a couple of the features of SvelteKit, but let's kind of contextualize a little bit for people who aren't in the ecosystem, don't know what's going on. Maybe what is SvelteKit in relation to Svelte, and how does it compare to some of the other front end, I'm hesitant to use the word frameworks or libraries, but it was like React and Angular? Yeah. Rich Harris: None of these words really have a agreed upon definition, so you have to sort of start from back tax. Noel: Correct. Rich Harris: I guess we should begin by saying what Svelte is. Noel: Sure. Rich Harris: We call it a component framework, or some people call these things view frameworks or view libraries. Equivalence would be things like React and View and Solid, and it basically solves the same problem, of allowing you to build little snippets of your app in a declarative way, that combine the markup, and the styles, and the behavior, and the sort of cohesive unit that can then be composed into a larger application. What the front end community has spent the last few years discovering is that that really isn't enough to build an app. You have your component framework, but then how do you do rooting? How do you do data loading? How do you handle environment variables? How do you handle server side rendering? How do you configure your bundler to do code splitting? All of these other things. When you're trying to solve these problems all at the same time, what people found is that you end up with these horrific homegrown solutions, or you end up with something very simplistic that doesn't offer features like server side rendering, which is bad for robustness and accessibility and performance and all those things. What we've been working on collectively, and not just the Svelte team, but the frontline community as a whole over the last few years, is building application frameworks that allow you to solve all of those questions, essentially. On the Svelte team, we started this journey in 2017 with a project called Sapper. That was the application framework for Svelte, and that trundled on for a little bit until a couple of years later. We realized that it wasn't really going in the direction that we wanted an application framework to go in, and so we began this project called SvelteKit. We worked on it for a couple of years. We had the stable release in December just gone. This is really our answer to the question, how do you build an application with Svelte that has all of the modern best practices, is optimized for performance and SEO and accessibility, and robustness, is really easy to develop, is really fast, and allows you to do all of the things that you're used to being able to do with modern web tech? We're pretty proud of how it turned out. It's just the beginning. This is not the final vision. We still have a huge amount of things on our roadmap, but we think that it is the best way to build web applications today. Noel: Nice. You kind of mentioned a lot there, and I think it can get tricky, especially for newer devs when they're kind of trying to discern between templating, or tooling used to create a new app, like the Create React app equivalent, like a command you use to spin up an app, versus more of a server side component that's helping optimize in performance. Where does Svelte get kind of fallen there? Does it expand both? Is it really more about the making routing work for server side rendering? Is it handling a little bit of all of that? Rich Harris: It's essentially a direct analog to Next in the View ecosystem. Next is maybe describe it as an SSR framework for view, although it can do a lot more than just SSR, and SvelteKit is the same thing, but for Svelte. The most salient difference is the SvelteKit and Svelte are built by the same people. It's the same core team working on both. Noel: Yeah. Rich Harris: We have this very sort of cohesive idea of where both projects are going simultaneously, but they really have the same set of capabilities, I think you. Mentioned Create React app, which is it's essentially a single page app framework, even the React team are now trying to get rid of. It kind of codifies a lot of bad practices. If you're building a React app, then you probably really should be using something like Next or Astro, but if you're using SvelteKit, you can do a Create React app style application just by disabling service side rendering. Server side rendering is a featureless SvelteKit. You can disable it. Pre-rendering is a feature of SvelteKit. This allows you to generate pages of HTML at build time so that they can be served with maximum performance, but you can disable it. You can do dynamic server side rendering instead. All of these things, they kind of make it difficult to pigeonhole SvelteKit, because there is no sort of category that it slots neatly into. Essentially, whatever kind of web application you are building, or even an application that just uses web technologies, like something that you might find in an Electron app, or a Tari app, or a smart TV app or something like that, SvelteKit is our kind of official way to build an application with Svelte. Noel: What else does SvelteKit offer other than the SSR? What are the big selling points? Rich Harris: Probably the most obvious feature when you start building SvelteKit app is this idea of file system based routing, which isn't a new idea. This is something that people have been using to build apps for a long time, but this is our take on the idea of file system based routing. For people who haven't used it, what that means is that the structure of your application and the structure of your project are one and the same. Inside your roots folder, if you have a directory called about, then that will contain your about page. If you have a directory called blog slash, and then in square brackets, the word slug, that is the route that will power your blog slash my first article, blog slash my second article and so on, are all parameterized. It gives you this way of organizing your code base that is really easy and intuitive to navigate. If you know your way around the application, you know your way around the code base and vice versa. Then it connects that to a data loading system. Just now, I mentioned that you might have a blog slash bracket slug directory, where you need a way to get data into that page. SvelteKit gives you a way of running a function that will load that data with knowledge of what that slug parameter should be. You can communicate with your database, or with an external CMS, or wherever your data lives, and you can get that into your component so that you can generate some HTML. That is the heart of what Vercel is. It's a combined solution for doing your routing and your data loading. Where it differs a little bit from more traditional app frameworks, and also some newer frameworks that are kind of harkening back to the old days, like Astro, is that in addition to doing the routing on the server side, it will have a client side router. As soon as your application starts, if you click around the app, then those navigations will be done purely client side with the history API, instead of forcing you to go all the way back to the server to get a whole new page, and then reloading an entire document. You get the best of both worlds. You get this very fast startup time, really good perceived performance, really good SEO, all of the other things that you get with traditional server side rendering. From that point forward, your application behaves much more like a native app, with instant transitions, and persistent state, and all of those other things. Noel: Nice. Yeah, I think we kind of lose sight now in this world where we put everything back on the server because it's fast, and you get all these nice performance benefits. It's like, well, there is nicety to, we put stuff natively for a reason. It's snappy, it feels good. I think that that does kind of get lost in the conversation a little bit sometimes. Rich Harris: It does, and I think the Lighthouse is largely to blame for that, because for such a long time, Lighthouse and Co Web Vitals and all of these other things, they're very heavily focused on the initial page load experience. In reality, the main things that people interact with on the web, and I'm not talking about the long tail of content sites, but the things that people actually use day to day, you have these long lived sessions where you are navigating around the app a lot. If you have to go back to the server for each new piece of HTML, then you are really suffering needlessly. You are harming performance for no good reason. The correct way to build almost every web app is to have service side rendering, and then client side navigation from that point forward. Noel: Yeah. Yeah, exactly. It depends on the typical use case for the app, right? Content sites, recipe websites, for example, the initial page load's probably what matters, but only interactive heavy app, it's like, well, it's nice when the initial page load's snappy, but we still want to have it feel good as you navigate this heavy app. Lots of pages, lots of navigation. There's something to be said for a framework, a paradigm, maybe, that handles both of those nicely. The developer experience is nice because you can be like, "Well, I can do pretty well on that initial load, but also when I'm working on the heavy use side, we still have all those niceties there." Let's talk a little bit more about the dev experience. Is there anything in SvelteKit in particular versus Svelte that makes it easier to develop work on apps? Rich Harris: Yeah, Svelte by itself really takes the developer experience very seriously. Our whole [inaudible 00:12:47] is to try and deliver the best possible developer experience without compromising on user experience. We have essentially a component language, which is a superset of HTML, and it makes it very easy to express concepts quite concisely. We typically find that component built in Svelte is 30 or 40% smaller than the equivalent component built in React, for example, because we have this compiler that is able to, how's the best way to describe it? It will instrument your code, because it understands your intent, and it will translate that into something that the browser understands. The developer experience that SvelteKit adds on top of Svelte really largely comes from Vite, which is a development server and bundling tool that's been around for a couple of years. Now, SvelteKit, I think was the first major adopter of it outside the View ecosystem. It provides you with this instantaneous startup, not like the bad old days, where you would have to wait for Webpack to bundle your entire app before you could load anything. It will create everything instantly, and it has hot module reloading built into the core, and a lot of other features which make it really nice to use. It has things like type script built in. You don't need to configure that, and all of the other stuff that you sort of take for granted in a modern web code base, Vite just handles for you. SvelteKit is able to capitalize on that. We just get all of that for free, which is really nice. Noel: Nice. Have you guys been pretty satisfied with that decision to go to Vite early? Rich Harris: Absolutely. Yeah. It wasn't an easy decision to make. We initially started out with something other than Vite. We started with a project called Snowpack. It was quite a disruptive thing early on in our development cycle to say, "Well, Vite 2 has just come out and it looks like it solves our problems a little bit better, but it's still this kind of unknown quantity." After a bit of research and kicking the tires, we decided that it was worth placing a bet on. It really has paid off, because in case you haven't noticed, Vite has taken over web development completely. It's a hugely successful project which has contributors from this very broad cross-section of the front end ecosystem, including the Svelte core team. There's overlap between the Svelte core team and the core team. We have this very kind of conversational and collaborative relationship with the Vite team, which has worked out really well for us. Noel: We have several episodes on Vite. Listeners can go find them. There's a bunch of information. We're all about it. Rich Harris: Yeah. Noel: Every time I can be using it for local dev in particular, the quick feedback experience is kind of surreal almost. It's so nice. How about when it comes to deployment, getting your app out the door? Is there any improvement there over what you could do natively with Svelte? Are there a few more concerns because you have this potential kind of server running that will be in charge of some stuff as well? Does it add any roadblocks to deployment? Rich Harris: The server absolutely adds complication. If you're just using Svelte by itself, then you're probably building a single indexed HTML file with a JavaScript bundle. You could just dump that anywhere. That's nice and easy, but obviously you lose out on all of the important stuff. When we were building SvelteKit in the beginning, it was a continuation of the predecessor that I referred to earlier, Sapper. Sapper's stance on this was you either deploy a node server, and we will build a node server for you, or we are going to generate pages of static HTML, and that was basically what people were doing in the late 2010s. It kind of made sense. Nowadays, you've got this plethora of different development environments, and even different deployment environments, and also different run times that are being used on those environments. You have CloudFlare workers, you have Dino, you have Bun now, and then obviously, you have Node on Lambda. Vercel, we have serverless and edge functions. Serverless is essentially an abstraction on top of Lambda, and Edge function's essentially an abstraction on top of CloudFlare workers. Those are two separate run times. All of this stuff, if you are left to deal with that yourself as an application developer, then you have a lot of things to worry about, and obviously your app is not going to be very portable once you've built something for a particular environment. One of the first things that we did when we started working on SvelteKit was we created this concept of adapters. The idea is that SvelteKit will build a production version of your app, and then an adapter will take it and essentially make it compatible with whatever deployment target you choose. We have official support for Vercel, Netlifly, CloudFlare pages, CloudFlare workers, data static is a thing that will turn it into static HTML files if your app is suitable for that. We can also generate a node server. The community has provided adapters for Burn and Dino and Azure and various other services. Basically, wherever you are deploying it, all you need to do is MPM install the adapter in question, add it to your Svelte config, and you're ready. You don't need to worry about the peculiarities of all of these different environments. It's just taken care of for you. Noel: Is the API over which those adapters are operating, is that bug prone? Are there ever errors there? Is there quite a bit of work that goes into making sure that the adapters are behaving nicely? Rich Harris: Yes. This is one of the places where there's definitely some moving parts. The adapter API itself is quite simple, but different platforms have different quirks in how these things work. For example, on CloudFlare pages, every request goes through a worker, but on other platforms, if you have static files, then they are served before any function is invoked. Little subtle differences like that can result in slightly different behaviors the adapters need to account for. Yes, we do definitely get issues on the adapters, but they're usually pretty quick to fix, because the adapter API itself is fairly straightforward. It's so nice that we're able to do it at the level of an adapter that we don't have to start trying to work around all of these quirks in the framework core. It means that we can be working on these things in a kind of separate channel, and we're not worried about making, breaking changes, because it's not in the framework itself. I'm so happy that we made that decision earlier on. It's a decision that a lot of other frameworks have since adopted. Astro has the same concept of adapters, and it's basically how things work now. I can't imagine doing it any other way. Noel: Do you guys have a testing around those adapters, automated tests or anything that run either against core or the tests, or is it kind of manual? Rich Harris: That's a good question. We should, and we don't. It's been near but not at the top of our to-do list for a while now. We have a demo application, the thing that you get when you type MPM create Svelte at latest on your command line, it will generate a demo application for you. What I would like to see us do is add some end-to-end tests inside that application. When we do create a SvelteKit app, it's really easy to add end-to-end tests and also unit tests via a playwright and B test. It just kind of configures that for you. If we were to use that to create some tests that were run on all of the deployed apps on each of these adapters, then that would give us a little bit more confidence than just waiting for our users to report that something is broken. Even with two of us working full-time on SvelteKit, there really aren't enough hours in the day. That will probably stay near but not at the top of our to-do list for a little while longer. Noel: Yeah. That seems totally reasonable. I think maybe just to clarify here, when there are errors like this, you don't have production apps that are down. This is just in the build pipeline, this is just the deployment process? Rich Harris: Usually. You can end up with runtime errors, maybe if there's a typo somewhere, you'll get the wrong cache headers, something like that. Noel: Sure. Rich Harris: There's definitely the potential for runtime errors, but what piece of software is free of that? Noel: Cool. Let's talk a little bit about at least the, I don't know if the onboarding experience is the right term, but people trying to get into Svelte or SvelteKit. I know when I was messing around, I think it was Svelte.dev, kind of very impressive to me, super easy to go in and mess around. Can we talk a little bit about the technology driving that? Who's been doing most of that work? Rich Harris: Yes, so this is one of the things that people really loved about Svelte back in the day was we had this interaction tutorial that's on the web, and it guides you through the process of building a component, and building multiple components, and stitching them together, and shows you all of the features that Svelte has in this kind of sandboxy environment, where it's very easy to learn stuff. The way that that works is we have a code mirror editor on the page in a web worker, we have Roller with Svelte, basically bundling your app on every keystroke, and injecting it into an eye frame, which works really nicely. This is very fast to startup thing. It's very responsive because it's all happening in your browser on a web worker. There is a limitation to that approach, which is that you can't run anything that requires Node. Because SvelteKit uses Vite and Vite requires Node, that means that you can't run SvelteKit using this approach. When we were starting work on SvelteKit, we were thinking, how can we offer a similar kind of interactive tutorial experience that we already have on Svelte, but the SvelteKit? The answer came, I forget when it was released exactly, but there's a company called Stack Blitz that developed a technology called WebContainers. WebContainers is essentially node compiled to WAZM running inside your browser, using a service worker to create a server, that you then put inside an eye frame. It is this complete mad science Rube Goldberg thing, but it works. It allows you to run SvelteKit inside the browser, even though it's a node-based command line interface. We've built a tutorial on Learn.Svelte.dev that actually uses SvelteKit and it's split into four sections. There's two sections on Svelte and two sections on SvelteKit. You're actually looking at an entire SvelteKit project. We've got a file editor and all of that stuff. Because it's running Vite, again, inside a web container, inside your browser, you get all of the hot module reloading, all of that stuff. All of the service side rendering is basically a complete SvelteKit developer experience, but running inside your browser. That was a really fun thing to build. We weren't sure if we were going to be able to pull it off, but the Stack Blitz people, we worked quite closely with them, and they did an incredible job. It's at the point now where I think the content is about 80% complete. You can pretty much use it to learn SvelteKit without having to install anything. You don't even need to run a command on your command line. You can just do it inside learn.Svelte.dev. I'm really excited about that. I've got to get a few more bits of content done, as I say, and a few bits of polish here and there. I, for one, think that this is the future of how we learn frameworks is having this stuff actually usable inside a browser. Don't make people install stuff, don't make people download stuff. Just take them there and give them a sandbox to play in. Yeah, that's been super fun. Noel: Yeah, absolutely. Again, I implore people to check it out. You can do it over your lunch hour. Just go give it a look. It's very slick. We got Stack Blitz episodes, talking about some of the cool tech behind WebContainers too, if people want to check those out. There's some really cool stuff happening in this space. How about the roadmap, the future? What are you guys excited about working on next? Rich Harris: Oh, there's a whole bunch of stuff. We've just released a couple of really neat features. Released a feature called Snapshots, which has been quite popular. This allows you to associate state with a history entry, which is something that you sort of get for free with browsers. If you're developing a multi-page app, you lack some control when you do it. Essentially, if you navigate back through your history, then rather than reloading a page from a server, it will reload it from something called the BF cache, which is the back forward cache, or sometimes the Blazingly Fast cash. In addition to the content of the page, it will repopulate any form fields. It will scroll to the same position that you're at before, all those sorts of things. Apps that use client side routing, like SvelteKit and Next and Remix and Astro, not Astro, but all of these other things, Next is what I was thinking of, historically, you don't get an equivalent of BF cache and Snapshots is that thing. It allows you to associate state that you control with a history entry so that you can, for example, you're filling out a form, and then you click on the terms and conditions link, and then you go back, and it hasn't destroyed at your form input. That's a feature that we just launched and that's been really well received. Another feature that we just launched is Granular root configuration. I mentioned earlier that you can deploy your app to any environment. Maybe that's Netlify, maybe it's CloudFlare pages, maybe it's Vercel, but some of these platforms offer multiple different environments that you could target. On Vercel, you can deploy your app as serverless functions, or as edge functions, or as static pages. That works pretty well, but if you're building a larger thing, then you might find that some parts of your app run best at the edge. Noel: Right. Rich Harris: They want the codes to actually execute close to the user if possible. Then you might have other bits of code that either they need a node run time, they need to run on a Lambda or they should run physically close to where your data lives. Those should be serverless functions, rather than edge functions. The feature that we shipped last week allows you to configure on a route by route basis, or a sub tree by sub tree basis, where the different parts of your app should be deployed. You get control over the runtime, over the region. If you are deploying to a Lambda, you get control over the memory that's allocated to that Lambda, the maximum duration that it should be allowed to run, all of that sort of thing. That's really cool, because it allows works deploying to those platforms to take full advantage of the platform features. In the Vercel case, there's a feature called Incremental Static Regeneration, which is sort of cache control on steroids. It makes it really easy to have statically generated content, so maximum performance, but which is driven by either an expiration interval, or you actively saying, "This page now needs to be regenerated," and then it will regenerate it, and push it out to the edge of the network, all within under a second, which means that you get the best possible combination of performance and dynamic content. That's something that we're a couple of days from having support for in SvelteKit. Noel: Nice. Rich Harris: That's going to be really great. There's so much stuff. We're looking at data streaming mechanism this week. We're looking at some more sophisticated control over rooting. We want to be able to have history driven modals and things like that. There's so much stuff that I'm kind of blanking on parts of it right now, but we've got a lot. Noel: Yeah, yeah. Again, I feel like a lot of the stuff you're describing kind of harkens back to what we were talking about before, like the different shapes of web traffic, and how there's different concerns on very read-heavy applications that you care about every millisecond of that initial load, versus interaction heavy stuff. It's cool to hear that you guys are thinking about those different use cases and how one must rely upon the tools of the hosting platforms. It's a point of friction a lot of the time when you're trying to make these frameworks that are nice to develop in work well with all the features of those platforms. I think that is a noble goal to be working towards. That's cool to hear. If we can zoom out a bit more, is there anything kind of more broad or more generic in this space, like the future of front end dev work? I'm hesitant to use the word frameworks, because it means different things. Is there anything in this space that you're looking forward to or excited about? Rich Harris: There's a ton of innovation happening in front end frameworks at the moment. We've got things like React server components, which are this kind of fundamentally new paradigm. There's a lot of really good energy in the space at the moment. A lot of it is slightly narrowly focused on performance, and I think that the performance questions are obviously important, but they're the sorts of things that this is different trade offs and things are going to get shaken out over time. Noel: Right. Rich Harris: I think the more interesting stuff to me is what innovations we're going to see in developer experience over the next few years. I don't have any answers to these questions, but obviously, everyone's very excited about what artificial intelligence is going to mean for programmers. What is an AI powered front end framework look like, for example? In the more near term, I'm excited that people are starting to think more deeply about the realtime experience. We've got stuff like Replicache and Party Kit is a new product that hasn't actually been launched yet, but it's something that I'm very excited about, stuff that's going to make it really easy to add collaborative realtime data to applications. Historically, that's been an afterthought, I think, but maybe we're going to start to see frameworks think deeply about how to integrate that into their architectures. There's a lot of stuff I think that's reasons to be hopeful and optimistic about front end engineering at the moment. Noel: Yeah. I think to your point as well of performance, there's a lot of focus on it right now. I always wonder if that is a justification devs use, because they want to use the cool new stuff and it's like, "Oh, well, it's easy for me to say we got to switch everything if I can say we'll have 10% better performance." Rich Harris: What's the thing I'm thinking of? Good Hearts Law, I think, where the minute something becomes a target, it seems to be useful measure. Because it's something that's so easy to quantify, time to interactive, it's a number. It's a very simple number that you can understand. People quite rightly focused very heavily on these things, but maybe the best representation of someone's experience of using the web. Actually, when you look at the main culprits of poor performance on the web, it's generally stuff that is outside the control of the technologies that people are using to build those sites. It's stuff like third party ads and analytics, all of these other things, which coincidentally, are the biggest contributors to layout shift, and annoying pop-ups, and banners and all of that stuff. People do focus on performance because it's an easy thing to focus on. I would love to see slightly more broad and considered view of what being a user of the web should look like in 2023. Noel: Yeah. Rich Harris: We're trying to do our bit by trying to promote the kind of best practices that we think are important. We haven't talked about how SvelteKit handles performance interactions and stuff like that, for example, but trying to essentially bake best practices into the framework itself, so that it's as easy to do the right thing, if not easier, than it is to do the wrong thing Noel: When you're just inherently encouraging people not to reach for additional like JavaScript libraries and stuff, and you can just do it, and it's performant, and nice, and kind of the way the web was intended to work may be a strong term, but the way it natively works, everyone ends up in a better place for it at the end of the day. Rich Harris: Yeah. Noel: Is there anything else you want to point listeners to? Again, we talked about a lot. Anything else you want to mention? Rich Harris: If you're interested in building web apps with cool new tech, then come to kit.Svelte.dev. We have a Discord channel for the people who will help you get oriented, Svelte.dev/chat. We have biannual conferences. We have a virtual conference, I think the next one's coming up in May perhaps, and then an in-person one later this year. It's just a really fun community. Everyone's really friendly. Come on by. Noel: That's awesome. Thank you so much for coming online and chatting with me. It's been a pleasure. Rich Harris: Yeah, thank you.