Ben: Hey, everyone, welcome to PodRocket. Today I'm here with Rich Harris, who's the creator of Svelte. How are you, Rich? Rich Harris: I'm good, thanks. How are you? Ben: I am doing well. It's been raining the past few days but excited for hopefully a decent weekend. And I'm excited to talk to you. I've been hearing a lot about Svelte over the past few years, but I honestly have not done a deep dive myself so I'm excited to learn about it from you. So maybe you could give us a quick introduction. What is Svelte? How does it help build great web apps? Rich Harris: Oh, man. You think that I'd be really good at giving an answer to this question by now, but I've yet to fully dial it in. Essentially, if you're familiar with front end frameworks, like React and Vue, then you'll be familiar with the basic idea of Svelte, which is that it makes building robust web applications easier, instead of imperatively manipulating the DOM with document.createElement and all of the things that are provided by the platform. It puts a declarative layer on top of that so that you can describe the output that you want, and then the framework's job is to translate that into the underlying DOM manipulations. Rich Harris: Where it differs from those frameworks is that it does as much of the work as possible at build time instead of a runtime. And what I mean by that is that rather than creating a structure like a virtual DOM which then has to be reconciled against what's already on the page, Svelte analyzes your code during your build step and converts it into, essentially, vanilla JavaScript or as close to possible as what you would write if you are writing your code by hand. Rich Harris: And so because of that, it's able to deliver a few important advantages. It generates typically very small code, which means that your application is going to load very quickly, and the updates, when you have a state change within your application, also take place very quickly, because it doesn't need to regenerate your entire application. It's just surgically updating the part of the page that's affected. Rich Harris: I should say at this point, because this is what I've been telling people about Svelte since it first came around in 2016, the landscape has actually shifted a little bit and other frameworks are, in many cases, becoming a little bit more Svelte like. So when I talk about these unique advantages, they're not so unique anymore. Svelte's selling point these days is really more about the developer experience it provides. Vue, in particular, has adopted a lot of these techniques and also has some of those bundle size and performance characteristics. But that's the basic gist. That's why Svelte exists, and the promise that it provides developers. Ben: And is there an ideal use case for Svelte? Would you say use Svelte for any type of web app on building, or does it tend to work better in maybe simpler or more your application where performance is maybe or bundle size is of more concern? When should people think about using Svelte? Rich Harris: Well, I should talk about where Svelte came from, because that indicates what it was initially designed for and what we initially thought of as being the sweet spot. I work as a graphics editor at the New York Times. I've been working in interactive journalism for most of my career. And Svelte was really designed to solve the problem that we had, which is we want to build these very highly-interactive applications. Typically, we're doing things like data visualization that involve large amounts of data, and we're using animations. We've got lots of interactivity, and we need to pack all that into a self-contained application that is going to sit inside a page that we don't otherwise control... like you have an article page that's rendered by your CMS and our content is going to go somewhere in there, and it's going to execute after all of your analytics code and all of your ads code. So there was this really important priority to make that code as fast and as small as possible. And so initially that's the problem that it was trying to solve fairly small, pretty well self-contained apps that had lots of rich interactivity. Rich Harris: But what we've found since making it open source is that once you've solved those problems, you've really solved a lot of the problems in web development, and we've found that it's applicable to sites of all shapes and sizes. We're currently working on an application framework on top of Svelte called SvelteKit, which we can talk about a little bit if you like, and that is designed to enable people to build everything from component libraries all the way up to giant ecommerce sites or whatever it is, and it's proven to be a very flexible idea so far. Ben: And in terms of performance, you mentioned that Svelte, one of the advantages is that bundle size is smaller since you're not shipping the full runtime along with your application code. You also mentioned that there's no virtual DOM. My understanding was that part of the reason why React uses a virtual DOM is so that when you have state changes that may change multiple different parts of the view, it's able to figure out what is the minimum amount of DOM changes that need to be made. How does Svelte, without using a virtual DOM, are you able to get those same performance gains a different way or maybe you could talk more about that? Rich Harris: So there's a lot of misconceptions about the virtual DOM, and some of it harks back to the very early marketing from inside React, although they've changed how they present this stuff a lot more in recent years; but nonetheless, some of these myths have persisted. Virtual DOM is essentially all overhead. The idea is that you're re-rendering your entire application but because it's a virtual DOM, you can do that performantly enough that the overhead doesn't really matter. Obviously, it's more efficient if, rather than saying, "Here's my app at T1. This is the virtual DOM, and here's my app T2," and then you traverse both of those trees and you find the minimal difference. "Okay, so we need to change the text inside this spam here." Clearly, it's more efficient if you can simply say, "Oh, we need to update the content inside this spam." And that's essentially what Svelte tries to do, to the extent possible. It's not going to re-render components unnecessarily if they haven't changed, and it has a much more granular update mechanism than re-rendering an entire component. Rich Harris: So the promise of virtual DOM was really that it enables this style of programming where you don't need to think about updates. And the only reason that people believe it's faster than manipulating the real DOM is because people compare it against this straw man, where instead of updating an entire application's virtual DOM, you update the real HTML... like you do app.innerHTML = and then you re-render everything, which is obviously a terrible idea for lots of reasons, partly because you're going to create a lot of garbage that then needs to be taken to the garbage collector, but also because it destroys any state that you have in your DOM loads. So really, it's less about performance, the virtual DOM, and it's more about providing this really nice declarative programming model. But it turns out that there are other ways to provide that same declarative programming model that don't involve that overhead, and that's what Svelte is all about. Ben: Tell me more about state, always one of the key things to figure out when you're building a web app. You have components state, you have global state. What is Svelte's approach to managing state? Rich Harris: So we have a two-pronged approach to state, and this is where Svelte becomes really opinionated and some people would describe this as magic. Most people really love it, but some people look at it and squint a little bit. They're like, "I'm not sure about that. That feels a little bit weird." What we do is we look at all of the assignments to state inside of your components, and every time you change something... For example, you might have a click handler that is attached to a button, and it increments a counter. You will do that in Svelte just by saying, count += 1, and you've declared that count variable by doing let count= 0. And Svelte intercepts that assignment. It wraps it an internal function called invalidate, which says to the system, "Oh by the way, this property of this component is dirty, and so at the end of the tick, we're going to need to update this component." Rich Harris: That contrasts with a lot of frameworks where... So React, for example, you have this useState hook where you call use state inside your component, and then it gives you both the value and a function to update that value. And it's a brilliant idea, it composes really nicely, but it involves a huge amount of boilerplate for the common case where you just have some component state and you want to update it. Rich Harris: On the other side, you have a state that lives outside components. And this might be your global store, like something representing your user object, or if you're doing some kind of medium application like you might have a global volume state for all of your audio players or something like that. Things like that live in what we call stores, and a store is just a very simple object that implements a specific contract. It has to have a subscribe method, and if it is a writable store as opposed to something that's read only, like your mouse position or your GPS coordinates or something, then it should also have a set method and an update method. And if you have an object that meets that contract... and Svelte out of the box has some helpers for creating these objects so it's very convenient... then, the component reactivity already recognizes that. If you reference the value of the store inside a component, then it will set up all of the subscriptions and crucially un-subscriptions to so that you don't experience memory leaks. Rich Harris: What's really cool about stores is that you can start to implement your own interfaces. So if you have, again, we'll use the example of a counter. If you have a store representing the value of a counter, you might not want to have the set property be... sorry, the set method be exposed because then people could use any old value. Perhaps you want an increment and a decrement, and you can do that while still adhering to the store contract. So this is very flexible way of modeling the data in your domain. Rich Harris: And it also lets you do some really fun stuff, like tween values. We have spring physics and tween values out of the box in Svelte, because we think that motion is really important feature of modern user interfaces. And you can do all that using Svelte's built-in state management. So it's actually pretty rare in Svelte that you need to use an external state management library, which is in contrast with a lot of other frameworks. Ben: Am I correct that you describe the process of, for a given component that references global state, you set up the subscriptions or the un-subscriptions, that's all done at compile time? Rich Harris: Yes. It identifies the fact that you're referencing a store value, and the compiler will essentially inject the boilerplate that you would have written if you were doing this stuff manually, and it does it in the optimal way. Ben: Got it. This is maybe just a hypothetical question, but could... One of the concerns, you mentioned this earlier a lot of people have with React is often writing a lot of boilerplate. Could some of those problems be solved with a compile step or better dev tooling that writes some of the boilerplate automatically, what it seems like you're doing under the hood with Svelte? Rich Harris: It's almost as if you saw the tweet that I did yesterday. I was very [crosstalk 00:12:47]- Ben: I actually didn't. Yeah. Rich Harris: Yeah, so I saw a tweet by Mike Shroff, who's a very well-known developer in front end world and is very knowledgeable about React and all of his competitors, and he expressed, not so much frustration but an observation that... If you're using React, you're already using compiler, because it's turning your JSX into regular JavaScript. And what he noticed was that the syntactical help would actually be better applied in many cases to hooks rather than the JSX, because you have all of this boilerplate, as you mentioned, and it feels like if you had a way of making those calls to hooks part of the language instead, then not only can you make things more concise, but you could also enforce the React rules of hooks more efficiently. At the moment, you have these lint rules that will tell you if you're using the use state hook incorrectly or whatever it may be, but you could actually force that at the language level. And so I tweeted a screenshot of what that might look like. Rich Harris: I don't know if that's on the cards in the future. I know the React team talk about a future in which they use compilers a little bit more extensively. But it's definitely fun to imagine ways that you can bring some of the developer experience that Svelte has been prioritizing and apply that to the React programming. I think there are definitely possibilities for frameworks to borrow each other's best ideas like that. We're still in a very frothy, innovative moment in the development of front end tools, and so I wouldn't rule out things like that in the future. But for now, you don't really get any of those benefits if you're using most React-based frameworks. Ben: So basically that's the idea that we could change the JavaScript language, because if you're already compiling, whether it's JSX, or you're compiling ES7, like future JavaScript features into current JavaScript, you are doing that compile step, so why not add some new features to the JavaScript language that are specifically tailored to what we commonly do and many of these frameworks or just React? Rich Harris: Yeah, so we've been going back and forth on this question for years now about on the one side you've got the sort of JavaScript purists who are like, "Everything should be just JavaScript, because then you get all of these benefits of... You get to use all of your existing knowledge, you get to use all of your existing tooling, you inherit all of the properties that JavaScript has like the module system and like the composition and all of these things." And there's definitely advantages to hewing as close to the platform as possible. Rich Harris: But then on the other side, you've got people... One of the things I say from time to time is that DSLs are actually a good thing. People on the other side, on the just JavaScript side, will be like, "I don't want to learn a domain specific language," because they've been bitten by domain specific languages in the past. But, actually, why wouldn't you want the language to be specific to the domain that you're solving. As long as the DSL doesn't decrease the amount of flexibility that you have, then other things being equal, it's probably a good thing. If it enables you to express the ideas in your application more concisely and more consistently, then it's probably a good thing. Rich Harris: And we had a bit of a realization in the Svelte world a couple of years ago when we took a step back and realized that we're not just building a framework, we're actually building a language. And it took us a while to have that realization, because the Svelte language is really only a very minimal superset of HTML, but it is nonetheless a new language. It has these very subtly different semantics in the JavaScript, and it adds stuff to HTML to enable you to have logic and loops. And we also tweak the meaning of the CSS in your components because, by default, style's declared inside a Svelte component are scoped to the markup inside that component. So we're already taking the things that you know and augmenting them. And by and large, people actually enjoy that. People have found that a really productive way to be, because you're taking your existing knowledge and you're augmenting it. Rich Harris: But it is fun to think about what happens if you take that idea of building a front end domain specific language and run with it as far as it'll go. There have been some really interesting experiments in that direction. Mint-lang is one such example. It's a language that is... It's essentially a language for building user interfaces that is also functional [inaudible 00:18:08] and blah blah blah. And I believe there are some other experiments along similar lines. And I'm kind of curious to see where all that goes in the future, and there's a lot of opportunities. Ben: And maybe it's a good segue to understanding how templating works in Svelte. So it sounds like you do have a DSL. You don't use JSX like React. So maybe can you tell us a bit more about how that works? Rich Harris: Yeah. So if you're building a Svelte component, you're going to be writing into a .Svelte file. And inside your Svelte file, you're essentially writing HTML. If you do the Svelte tutorial, svelte.dev/tutorial, then the first thing that you write is just an H1 tag into a blank file. And then as you start to add styles and behaviors to your component, you do those inside style and script tags. The thesis here is the HTML is the language of the web. JavaScript is not the language of the web. JavaScript is one of the three languages that are sort of contained within HTML, because HTML is designed to contain CSS and JavaScript, whereas a lot of frameworks go the other way. They're like, "JavaScript is the primary language and we're going to try and shoehorn HTML and, in some cases, CSS into JavaScript." Svelte takes this opposite view that you begin with HTML, and then you add JavaScript as necessary. Rich Harris: So you're writing inside this .Svelte file and inside your markup, you can add expressions inside curly braces, which look very much like JSX. If you're familiar with React, if you're familiar with the idea of having JavaScript expressions inside your template, then writing that seems very familiar. Rich Harris: Because it's a template language, we do have special constructs for ifs and loops, which enables you to express certain things in a way that is both very obvious to the author but is also beneficial to the compiler, because it can see okay this requires a certain code transformation and so on. Rich Harris: And as I mentioned, if you want to add styles to a component, you'll put them inside the style tag, and the compiler will look at that, it will analyze all of the styles, it will analyze all of the markup, and it will add classes to the selectors and to the markup such that the styles you write will only apply for that component, which is great for people who work on teams where there's a bunch of different people writing components and you don't run into that problem where, in order to prevent style conflict between one part of your app and another part of your app, you have to have these very broke name spacing conventions. Rich Harris: And then finally, of course, you have the script which defines the behavior of your component. That's where you add your life cycle hooks; you add your state; you declare the components props, which obviously determines what data can come into that component; and anything else that you need in order for the component to be the self-contained module of functionality. Ben: You mentioned earlier that some of the other frameworks react, or in particular Vue, have become more Svelte like over the years. Could you just tell us more about what you meant by that? Rich Harris: Yeah. So one example is how Svelte deals with its internal utilities, because in order to output more efficient code, it will... For example, the documen.createElement call, it's a lot to have that repeated every time you need to create an element, so it will wrap that with a function that's just called element. And it exposes that from its internal library. It has another one that is for creating SVG elements, because, as anyone who's worked with SVG at a lower level will know, you can't do document.createElement to create an SVG element. You have to do document.createElementNS and then paste in the SVG namespace which is HTTP://www.w3.org/2000/SVG, which is an absurd thing to have repeated in your code base. So we have this helper that does that for you. Rich Harris: If you're writing an application that involves SVG... say you're doing some DataViz something, which is a common use case for me personally, then that helper will be imported from the internal library. But if you're not using any SVG elements, you're only using HTML elements, then it will only import the element helper and not the SVG element helper. And because of that, because modern bundlers have this feature called tree shaking, where the bits of a library that aren't getting used will just get quietly discarded, that means that we don't need to include that part of the framework. It only includes the bits that it needs. And that's a small example. Rich Harris: There are other examples that are more complicated that involve us discarding big chunks of code. For example, the stuff around motion and transitions, that tends to be a little bit more involved. If you're not using it, it just doesn't get included. And those are the kinds of ideas that are now pretty commonplace in frameworks. Vue has an internal library, too, and nowadays it's using ahead of time compilation much more aggressively than in prior versions. And one of the things that it's doing is it's importing its helpers from a tree shakable internal library. Rich Harris: So these ideas, once one framework does them, other frameworks tend to quickly adapt, which is one of the nice things about working in a space where there's a lot of competition. Some people call it JavaScript fatigue or churn or whatever, but actually, we have this rising tide that lifts all boats equally, and I think some of these ideas are now basically par for the course. Ben: Could you tell us more about SvelteKit? Rich Harris: I can. So where to begin? We used to have this framework called Sapper, which was an application framework built on top of Svelte. And the idea with Sapper was that it provided you everything that you needed to build a full-blown application using Svelte components, and it was very largely inspired by Next.js, which is sort of the industry standard framework on top of React. What these frameworks give you is a pre-configured build setup, so you don't need to spend time chasing the webpack documentation or whatever it may be. They do automatic root level code splitting, so that you're not sending your entire application to the user as soon as they hit the first page. It gives you code organization principles. It gives you server rendering. It gives you a lot of things that enable you to be much more productive than you otherwise would. Rich Harris: We've realized maybe a year or so ago that Sapper wasn't quite evolving in the way that we wanted to, and at the same time, there have been a lot of developments in the front end space that we could take advantage of. There have been this big shift towards serverless platforms and edge compute. And there had also been some developments in bill tooling, particularly around the idea of unbundled web servers. They're these new tools called Snowpack and Vite, which essentially replace tools like webpack that a lot of people still use today, but a couple of years ago they were how you built web apps, and nowadays Snowpack and Vite are able to leverage browsers built-in module loaders to provide a slightly more efficient way of working, because rather than compiling your entire application, these things will only compile the bits of the application that the browser is requesting. So you get this instant startup and very fast workflow. Rich Harris: And so we started again. We ditched Sapper and started building a new thing and we called that SvelteKit. And like Sapper, it's a full stack application framework that lets you build fully server ended applications with all of the modern best practices, but it's also very flexible both in how you build your app... You can build a completely single-page app or you can build a completely JavaScript-free multi-page app or something in between, and you can vary it by page; but you can also deploy it to a bunch of different places if it's suitable... like you're building a very static content site, then you can bake it out of static HTML and then you can just throw that on GitHub pages or whatever it is. Rich Harris: But if you're doing something that's highly dynamic, then you can have a server component or you can have serverless functions or you can put it inside a Cloudflare Worker, and you can pre-render the parts of your application that are static and dynamically render the parts that are not. And it's really a way of addressing all of the problems, or as many of the problems as possible, that you encounter while building a modern web application. Rich Harris: One way that it differs from other frameworks... you can't do this with Next, I don't believe you can do this with Nuxt and all of the various other riffs on the same idea... is that SvelteKit is also a framework for building the components themselves. We had this realization that if you're building an application, you're going to have an internal component library. If you're building a component library, you're going to need an application to showcase it or at least test out the component library that you're building. And they're actually the same thing. If you're building an app or you're building a component library, it's the same thing. What's different is whether you're publishing the app or you're publishing the library. And so SvelteKit is designed to be this end-to-end solution for building anything Svelte related. We're not yet at a version 1.0, but it's shaping up nicely, and we should have some news on that front fairly soon hopefully. And it's going well. It's a pretty exciting project. Some people are using it in production, but it's not at 1.0 yet but we're close. Ben: Looking at just Svelte, what's on the roadmap there that maybe you're most excited about over the next year or so? Rich Harris: I mean, over the next year or so, a lot can happen. I'm almost reluctant to talk about some of these things, because a lot of it is speculative and we're not really sure where some of these ideas are going to land. But we have this long wish list of things that we want to do for Svelte 4.0 And beyond. Some of it is adopting some of the features that other frameworks have proven out, like streaming SSR and things like that. Some of it is around speeding up our own compiler, so that the feedback loop gets even tighter. Changing how the compiled output is generated such that if you have a very large application, you're paying only a very tiny incremental cost per component. We have some grand ideas about better ways to think about motion inside user interfaces and how that should be tied to the core of a framework as opposed to left to a UserLAnd solution. We have a great many ideas, and I don't want to give them all away. But there's a lot on our plate, and we're pretty excited to get stuck into it when we can. Ben: And then outside of the world of Svelte, what are you most excited about in the broader world of front end? Rich Harris: That's a good a question. I've actually been a little bit of a downer recently about web development in general, because things are getting so complicated these days, like platform itself is getting quite complicated. But I have been very excited to see some of the innovations around the way that we deploy our applications. Stuff like Cloudflare Workers is really changing the expectations that I think people have around the ease of deployment and the latency that users can expect and all of those things. Rich Harris: And, yeah, let me think. I mean, there's definitely still a lot of innovation happening in the front end framework space. I know you had Ryan on a few episodes back, talking about Solid. There's a ton of really good ideas in there that I think are also going to make their way into other frameworks. I've been excited to see people start to take the no JS idea seriously. We've got frameworks like Astro, which are really pushing the HTML first idea, which we're very on board with, even though Svelte is not that kind of framework. We can do server rendering that doesn't involve a client side hydration, but typically you will be hydrating your application with some client side code, so we don't share the no JS label with Astro. But people are really starting to think more deeply about how to provide the ultimate user experience, and I think that's going to result in a shift of expectations with the next wave of framework development that is going to be very beneficial to users. And so there's definitely good stuff happening. Ben: So we have a couple of questions from listeners. The first, and we kind of covered this a bit earlier in the show, but this is from Wes Bos, who's one of the hosts of the Syntax podcast. We were actually talking to them yesterday that I guess by the time this episode goes live, that episode will presumably have gone live. He asks, "What are your thoughts on the React ecosystem with React and Svelte being at two opposite ends of the spectrum, with one being so explicit and one being a bit of magic?" So I guess I'd asked you, "Do you think that's a fair categorization that Svelte errs into the bit of magic side of things, and is it an opposite of React, or how do you position, Svelte within this landscape of the popular frameworks?" Rich Harris: I mean, they definitely are very different frameworks in a lot of different ways. Svelte takes a lot of inspiration from React, certainly, things like the data flow and stuff like that. React sort of set the playing field for all of the frameworks that have come since 2013, and you can't build a framework and not be heavily influenced by React. But we do have very different ideas about a lot of things, and the virtual DOM is one such thing. That's reflective of a deeper philosophical difference which is quite nuanced and difficult to get into in the context of a podcast, but we see the jobs of framework in a slightly different light. Rich Harris: But in terms of the magic versus explicit, I don't know that that is such a real dichotomy. The differences that Svelte is doing the stuff at build time. It's changing your expectations of how JavaScript works, because it's intercepting assignments and turning those into reactive state changes. React is doing something similar. If you look at a React function and you don't know what's happening with hooks, then you would look at that code and you'd be very confused about what's happening, because the functions behave in ways that JavaScript functions generally don't. The fact that the return value of a function depends on how many times you've called that function and whether you've called the return value in the past and things like that, that's deeply weird, it's not how JavaScript works at all. You can implement it with JavaScript, but it's not how JavaScript works. They are violating expectations on a fairly fundamental level. The differences that they're doing it all at runtime instead of having all of that stuff happen behind the scenes at compile time. And I tend to think that focusing on whether the magic happens at build time or whether it happens at runtime is focusing on the wrong thing. All frameworks involve magic. Svelte is just trying to do the expensive bits of magic before that code gets to the user. That's the only real difference. Ben: Another listener asks, "Do you see Svelte as an underdog in the framework wars?" Are there framework wars? I'm not sure. I guess it can feel like that with there's only so many apps being built and there's a lot of frameworks out there, but do you see- Rich Harris: Yeah, but I- Ben: Yeah. Rich Harris: I dislike the framework wars framing generally, because what might not be obvious to a lot of people who are users of these frameworks as opposed to actively involved in the development of them, is that... The people who are building these frameworks, we often talk to each other. We by and large know each other. We get along. There's no animosity There's no warring whatsoever. We hang out in the same spaces and we share ideas with each other, and really we're all, I think, just trying to collectively advance the state of front end development by focusing on the little bits of innovation that we can contribute, and then gradually, all of that stuff filters through the ecosystem and gets shared more widely. And Svelte occupies a part of the landscape that is attracted to a certain kind of developer. React occupies a different part of the landscape. They're both completely fine solutions for the people who are choosing them, and they're not going to be right for everyone and that's fine. Rich Harris: So it's not like Svelte wants to be the new React or to take over React. We actually don't care if people who currently use React like Svelte or not. It's gratifying when we hear that people have been able to rewrite their apps in Svelte and they've had performance advantages and whatever or that they've had a better time developing it because the developer experiences is simpler with Svelte. It's nice to hear that, but what we really care about is making the best framework that we can, and mass adoption isn't necessarily our goal. Rich Harris: So are we the underdog? It depends on what you're looking at. There's three big frameworks, right? There's React, Angular and Vue. And if you had to pick a fourth framework, I think most people at this stage would probably say the fourth framework was Svelte. And so if underdog means that you're inside the top four instead of the top three, then absolutely are the underdog. At the same time, we have a pretty good mindshare at this point. A lot of people in the front end world have heard of Svelte. A lot of people talk about Svelte. There's a whole industry of people doing YouTube videos about Svelte. And I think calling ourselves underdog would be a disservice to the people who are actually laboring on open source projects without getting a whole lot of recognition. I think we have plenty recognition. And so, I wouldn't claim the underdog label for ourselves by any stretch, but nor are we in any way mainstream. Ben: Well, Rich, it's been great having you on. It's been great learning about Svelte. Definitely going to check it out. For folks out there who want to learn more, website is svelte.dev, right? Rich Harris: That's right. Ben: And super robust community of GitHub contributors as well, so I imagine if anyone wants to contribute, you're open to contributors. How does that work? Rich Harris: Yeah. I mean, come on by and take a look at the issue list. We do have a little bit of a backlog at the moment. We need to try and work on some of our open PRs. But you're right, we have a very active community. We also have a Discord server where a lot of people hang out. Svelte.dev/chat will take you there. And we have the Svelte Society Twitter account, which is where a lot of news gets shared about what's happening in the Svelte world, so twitter.com/sveltesociety, which is technically unaffiliated with the Svelte project, but it's our friends who are running that so they're very on top of everything that's happening in the Svelte world. Ben: Great. Well, thanks again, Rich. Rich Harris: Thank you. Brian: Thanks for listening to PodRocket. Find us at PodRocketPod on Twitter or you could always email, even though that's not a popular option. It's Brian@logrocket.