Supper Club × Rich Harris, Author of Svelte

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax. On today's Syntax supper club, we have the author of Svelte Rich Harrison to talk all things Svelte. And if you are new to Svelte, you don't know what it is, this will be a good one for you as well as if you are experienced with Svelte. My name is Scott Talinski. I'm a developer from Denver, Colorado. And with me, as always, is Wes Bos. Hey, everybody. Stoked Talk about spelt today. Yeah. Me too.

Welcome, Rich. How's it going, man? It's going great. How are you? We're doing good here. This is, Number 2 recording for us today, and the first one had, like, major lag.

We did some restarts. We, did some speed tests, and it's feeling a little bit better on this one So far so.

I just moved into a new house, like, a couple days ago, and I'm just in the bedroom right now while I'm working on the office. And I thought, oh, man. Like, I thought my speed test was doing great. But so I ran a Ethernet cable from the 2 rooms over to plug in here. And my wife's like, what are you doing? Just just trying to get it all going. And, yeah, it was It was bizarre, though. We were like we'd both ask a question at the exact same time. Or Yeah. That's a frustrating part about, a podcast when there's lag I guess that we step over each other, and then it doesn't we don't have that good back and forth. So excited that it's working now. This episode is sponsored by 2 amazing companies.

One of which is Gatsby, the fastest front end for the headless web, and the other is a light step incident Thoughts, intelligent on call scheduling, and escalation. More about those later on in the show. So, Rich, I think the the first little bit Maybe give us an introduction to who you are, what you do day to day, and then, then we can get into some Svelte stuff.

Sure. I mean, what I do day today is is spelled. Ever since I joined Vercel, last November, it is my full time job to work on open source, which is an amazing privilege.

Prior to that, I spent my entire career, Drifting in and out of newsrooms, got into open source as a way of doing journalism,

and I've been here ever since. Yeah. I I was I've been always following a lot of the the kind of features you'd been working on and and stuff in the past. It was always really, really cool stuff.

So Svelte is a framework for the web.

Do you wanna maybe give like, if if people are totally green to Svelte, they don't know what it is. Maybe they've heard of me or or Wes talk about it.

Can you maybe give a a, like, a Svelte one zero one for the uninformed?

Yeah. I I can try. To be honest, we probably need to Update our sales pitch a little bit because when it came out, it was this very novel thing. But now, the things that made it novel have been kind of incorporated into a lot of other frameworks.

And so we need to talk a little bit more about why it makes sense to use Svelte as opposed to one of the myriad other JavaScript frameworks that you can use.

In essence, it is a way of developing web applications more easily, using a declarative component format.

And what's different about Svelte is because we we fully lean into the idea that the code that you write and the code that you run do not need to be the same thing because we have a compiler in the middle, We can give you this very concise, very expressive language, essentially, for describing your user interface components.

And so the the the what it is is it is a framework for building web applications, and the way you would use it is that it makes you More productive. It's a really fun framework to use, and you can do stuff very quickly when you're using it. It's it's very enjoyable. Like, I would say, It's been a long time since I had that,

moment. And when I when I use something because it's like and it it probably the last time I had that was, Like Angular coming from jQuery to Angular, it's a oh, update. It just updates. Right? And like, oh, it just It just works like that. Oh, repeating like that? Okay. And not to say that's all is Angular. They're obviously very different, but, it's a very enjoyable framework to use.

I can see why, everyone's gone to it. I I should add to that because I'm I'm talking a lot about the developer experience of using Svelte, and I, you know, I I think it's really important to, you know, I I think web development should be fun. Like, we're we're in web development because we like building stuff on the web, and building stuff on the web should be more fun than building on other forms, and I I think that is very much what Svelte is about. But when you talk about this stuff, inevitably, someone on on Twitter, we'll we'll get angry at you because you're prioritizing the developer experience over the user experience. Totally. And what? So the whole point of Svelte, the reason that it came into being, the reason that we designed it the way that it's designed is that we believe that the developer and the user experience are not these kind of, poles on a spectrum. Like, you don't create a better developer experience at The cost of user experience.

Because we have this compiler centric mindset, we can have this really good developer experience Without compromising on user experience. So Svelte apps, they're really small.

They start up quickly.

They are very fast to Update when you have a lot of data changing very quickly.

And so the the whole idea is that you kinda get the best of both worlds. Nice. Yeah. It's it's funny. I came from, like I mean, before,

I mean, when I was building full stack applications, I was doing a lot of meatier stuff, and I think people got burnt a a little bit on meatier because they they felt The ease of that developer experience was super nice, but then it did come at a cost to the user experience at the end of the day, especially when it comes to scaling. But it felt so nice that everybody it's like, oh, this is great. Let let's let's, let's work in this, and then you'd get burned later down on the road. But, I I mean, I totally agree. It's it doesn't have to come at a cost. It just Occasionally has in the past, and maybe that's that's where they've picked up that, that feeling. I'm wondering a little bit about, like, Wes mentioned, you know, the the, like, the feeling of writing Svelte code.

Specifically, one of the things that makes me feel that way is, like, the templating language.

It it feels very much like templating languages that I know Wes and I have spent quite a bit of time with whether that is, like, Handlebars or anything like that. Can you talk maybe about the, like, the influence in the templating language? Like, where did you where did you, develop the templating language from, or what was, like, your main inspiration for that specifically? So you mentioned handlebars,

and that was a huge influence to me many years ago.

We used to have mustache, and we had handlebars, and there was kind of a Informal standard around this stuff.

Like in the early 2010s, you could not move on npm without bumping into Some implementation of a mustache variant.

And the idea was, like, people were just getting used to this idea that, instead of Doing this imperative DOM manipulation, you would have template fragments, and you would inject data into them. And in that way, you would declare to be build up your application.

The trouble was, well, there were 2 things. Number 1, the way that you would then get that instantiated template into your app was just by replacing a chunk of HTML.

And replacing a chunk of HTML meant removing the existing DOM and putting new DOM in. And that is an inefficient process. If you're changing lots of things all of the time, then that is, that is very wasteful compared to surgically updating the DOM. The second problem with template languages historically was that, they're kind of inflexible.

Inside your mustaches, you can't have arbitrary JavaScript expressions. You don't have access to a module system, Anything like that. And so because of all of those limitations, a lot of people gave up on templating as a concept and instead embraced, you know, the it's just JavaScript Mindset of of react and so on. But I had I had grown up with templates. I felt that they're a really natural way to write code.

And so rather than kind of throwing out that concept, Svelte took, the best bits of languages like handlebars And kind of brought them into the modern age where you can use JavaScript inside your template expressions, and you do have access to the module system.

And so I think, personally, that it's the the optimal, place to be to have a template system, but also have All of the power of JavaScript.

Some people disagree. They think that templates are a dead end, and that's fine.

You know, there's, there's room for a lot of different opinions on this. But, yeah, that's that's where it came from. It came from from that That world, I think handlebars is probably the single biggest influence. Yeah. I think

if if you come from the handlebars world, I think that Can feel not like obvious, but it can feel definitely inspired. And that and that feels great for those of us who have spent a lot of time in that in that world. But, especially, I think some people might even see this Svelte templating language and just assume that it is like that same sort of thing rather than having JavaScript expressions Or the the the lessons learned from maybe past, React based component or JSX stuff that now we have, some really advanced templating abilities, especially in you know, in in the Svelte one is is growing all the time. Recently, you you guys launched, like, the the const tag In in the Svelte templating language where you can essentially define a variable in the templating language.

And to me, that like, little things like that just make your life so much Better, I think, overall. Oh, was what would what would you use that for, the const tag? Well, so that that's if you have

If you're iterating over an an array of objects and you want to derive some some value from each of those objects, Like, you know, const full name equals object dot first name plus object. First name. Yeah. Like like, that sort of thing, it's useful for especially if you're gonna be using that multiple times inside the block. Oh, Oh, yeah. So you don't have to dip out to to your JavaScript. You can do it all inside of the template. That's pretty neat. Yeah. The other way you would do that, Wes, in the past would have been just creating a subcomponent like a child component,

and then you would have to do that computation in the child component or yeah. Today's episode is sponsored by Gatsby, the fastest Front end for the headless web. We've talked about Gatsby a whole bunch on this show. This makes the hardest parts of building a performance site easy with pre Fetching, lazy loading, and image optimization baked in. If you've never used the image tools within Gatsby, you are in for a treat Because they make things really super easy to build in plug ins that do like a blur load effect or an SVG load Effect to make your images seem lightning fast responsive, but also serve up the correct image size or serve up a progressively loading image so that thing loads so quickly. If you're building a headless content rich site, then Gatsby's GraphQL data layer allows you to source web content from anywhere using its Thousands of plug ins or you can easily write your own. Not only that, you can take your site to Gatsby Cloud, the only cloud Optimized for Gatsby with the fastest builds and reliable build previews.

So are you building a site where performance is of the utmost importance? You're gonna wanna check out Gatsby atgatsby.devforward/ syntax, and get your 1st site up in minutes And experience the speed of Gatsby.devforward/ syntax. Thank you so much for Gatsby for sponsoring.

I got a question about, immutability.

So one thing that is sort of, like, Ran into our heads in in React land is and I don't wanna talk too much about, like, a React versus Svelte, but We talk a lot about, like, everything must be immutable, and you wanna update a variable. You have to do this whole song and dance of setting, state, and and taking a Copy and overriding it and not reaching in. And, and then you go and just felt. And it's just like, well, you got a variable.

Mhmm. Just update that variable, and you're done. Like Like, what are what people like, what about immutability there? Like, what do you say to people that say that's that's,

there's an issue with immutability there? I think immutability is a very useful concept.

I think in general, the less you can have State being mutated in different parts of your application, the more predictably it's gonna behave and all of the rest of it. That said, there is a cost to immutability.

Every time you have to create a whole new object and copy your overall of the properties, there's a performance overhead to that.

And in many cases, when you're mutating things in a local, predictable way, you're not Introducing the kinds of problems that immutability is supposed to solve. And so by allowing you to mutate your objects, we're giving you the option to do things in a more performant way.

We do encourage immutability in certain places. Like, we, if you're, assigning like, I don't know. You're adding a new to do to the array of to dos or something. Like, it it is Often better to just create an entirely new array, but it's it's not something we force. Whereas, You know, in React land, you kind of have to do that because if you don't have immutable data, then you can't use concurrent features, for example.

So the because React is is leaning so much into this idea of concurrency, Immutability is is completely necessary. And and with that, you get all of the problems of, like, the performance overhead, and so then you have to start memorizing stuff and etcetera, etcetera, etcetera.

And so, like, in order to in order to to have this this one big overarching feature, like, you have to solve all of these kind of problems that fall out of it.

In Svelte, we we don't have, concurrent mode. That is arguably a limitation of the Svelte model, but, our position is that it's, And, essentially, an unnecessary feature that causes more problems than it solves. And so we allow you to treat Mutable data or immutable data, like, according to your own preferences and the needs of your application. Yeah. Nice.

What are the things that, like, when we we often, like, talk about when we talk about Svelte is that it's, like, compiled away or that it's a compiled, language.

Would you be able to maybe explain a little bit, like, what it What it means that Svelte is less of, a live shipping a library like React is where it's, you have a SALT file and that compiles to JavaScript.

Can you maybe explain a little bit about how how that process works to somebody who might not, maybe no like, they say, well, at the end of the day, we still you know, it still spits out library code. What's the difference there?

How how does that work, Essentially. Yeah. Sorry. Again, this is where this is a a comparison that makes more sense against React than against other frameworks because, like, A lot of frameworks actually do fairly similar things these days.

But in a React app, the the way that you update your page is you generate a new Snapshot of the virtual DOM either for your entire application or for some subtree of your application. Conceptually, you're, you know, you're rerendering the entire world, And then you're handing it off to React, which must then compare the the old stuff to the new stuff, and then figure out how we take The the virtual DOM, the declarative intention of what the patient look like and translate that into actions that update the real DOM. And that has a cost, Not just in terms of the the different process itself or in terms of rerunning your component code, but, you you know, you have to have the code that is capable of doing that. And And React doesn't know what kind of virtual DOM you're going to provide it with. It doesn't know, whether you're gonna be using This element or that element, this event handler, that event handler. So it has to be prepared for every eventuality, essentially.

And that means code. It means that you have to have the library code as part of your application.

Otherwise, you might have some virtual DOM that it just doesn't know what to do with.

And that is, that is not the case in, in Svelte and in other frameworks that have a similar approach because We essentially look at the code at build time, and we know which features of the framework you're using.

And so we only include Features the framework that you're using. So for example, if you don't have any SVG elements in your application, we don't include the code for generating SVG elements.

That's a very simple example that doesn't really have much of an impact on on bite size, but there are other examples that do have more of an impact on bite size.

And so that's what we mean when we talk about the framework being compiled away. Nice. I I always like to think about it as, like,

you can include more with Svelte because you don't have to ship everything. Right? You can include animation libraries at zero cost to the users who aren't Using those animation libraries. Right? As opposed to, you know, their if you bake in animations to react, all of a sudden, you have

A little bit more to that that library. Right? Yeah. What do what do you think about web components? Lot of people on the podcast are like, no. You don't need any of this. Web components are the answer. And to that, we always say, like like, well, then why are More people using web components and whatnot. What what are your thoughts about web components? I have so many thoughts. Alright. Let's hear them.

Yeah. Yeah. We we can talk a lot about that. I mean, depending on who you ask, a lot of people are using web components.

You know, the the charts are going up into the right, And it's it's very hard to know how that actually translates, in terms of, you know, kind of developer sentiment and so on because You have some very big sites like YouTube, which use web components. You have, the AMP framework uses web components, and those really skew the the usage metrics.

And so it it's very hard to tease this stuff apart. Whenever you see developer surveys about how we build web apps, you see the the the usage and the interest in web component frameworks is is weirdly low, suspiciously low compared to The numbers on NPM and the the numbers on, like, Google's stack counter and, like, all of that sort of thing. And so it's it's honestly it's hard to know How, how popular web components are. My own personal feelings about web components is that they are, they're kind of a a calcification of of early 2010 era best practices in web development, and they haven't really Survived the the developments of of the last 10 years. And that if you do use web components, you are opting into a set of limitations which you don't have if you use non custom HTML.

And so the big ones are around server side rendering, for example.

There is this thing called the Clarity Shadow DOM, which theoretically allows you to do server side rendering with web Web components.

But the way that you actually have to use it is extraordinarily convoluted.

And so we're we're in this situation where You can do everything that web components are supposed to let you do with existing frameworks and not a lot that you can't do with existing frameworks, but you opt into all of these These downsides.

I've I've written about this. Like, I've I've articulated why I don't personally see a lot of value in web components, But I, you know, I tend to find that whenever I do talk about this stuff online, I get just a a barrage of of abuse on the Internet because, for some reason, the the the defenders of the of this technology are Particularly ornery in a way that most adherence to different ways of building web apps are not.

I don't know why. Oh, that's good. Well, you you can go on as long as you want. We'll have we'll have some web component people on the podcast even it out as well then.

Yeah. Well, it's always funny to me, though, because this the experience, especially of authoring just like raw web components itself. I think if you've spent any time in in Svelte or React or Vueland, they're like, It it feels like a tremendous step back backwards authoring wise even.

So then, like, what what you have is the way to write web components becomes Maybe a layer on top of them that make the development experience a little bit nicer. You have wet lit and, Was solid or no. Not solid stencils. I think it's a stencil.

Yeah. So you have all these layers on top that try to ease some of that. Then at that point, it's like One echo all the way and use something even a little bit nicer. Yeah. I mean, the you the no one says that you should author web components by hand, like, Actually doing the class my thing extends HTML element,

because the the authoring experience is absolutely trash, and I think everyone agrees on that. But, you know, if you do have to opt into one of these opinionated frameworks where the the interop, benefits really kind of oversold, then it is hard to see what the actual benefit is. Yeah. Totally.

Can we talk about virtual DOM for a sec? A virtual DOM is a is a concept in specifically React and and other frameworks where, they maintain a virtual DOM, and then they can diff it. And they know the actual DOM, the actual elements on the page. They know exactly which elements to update. So Svelte just says, nah.

We're not gonna do that.

How come You don't need the virtual DOM, and how come other people do need the the virtual DOM? Are you are still, apps still as fast, when you're are you doing quite a bit of stuff? Well, they're they're faster. They're significantly faster.

The virtual DOM is It is is not a mechanism for making things fast. The virtual DOM is overhead.

It's it's a way of allowing you To build applications declaratively that is not desperately slow. I I talked earlier about how, in the beginning, template languages, they would let you generate some HTML from a template and some data. And then in order to update the page, you'd have to yank out the existing DOM and put in this This fresh HTML, which would get turned into DOM, and and that's like an that's an expensive process.

And because of that, no one actually does that. It's a complete Straw man. No one was really building applications that way, but then React came out and said, well, look. We have this virtual DOM mechanism, which allows us to just update the parts that changed. And so it's a similar idea. You have this declarative approach to to saying what is gonna be in the page.

Yeah. But then instead of replacing everything, you're just replacing the small parts.

The trouble is that in order to find out Which small parts have changed? Like, you need to do this whole virtual DOM diffing process. Mhmm. If you don't have that, if instead of saying, okay. Here's my div. And inside my div, I have a button. And inside my button, I have some text, and the text has changed. If instead of all that, you can just say, oh, the text and the button changed, well, then that's the only thing that you need you need to do. You don't need to go through this rigmarole of of of of reevaluating the entire application and comparing it against Something that that came before.

And the the reason that that Svelte can do that is because it's a compiler, because it can see your Source code. And because we're using templates, it's very easy to be like, oh, well, the div is always going to be there. Like, that that's not going anywhere. The button is always gonna be there. That's not in anywhere because it's not inside, like, an if block or anything like that. We can guarantee the continued existence of this button as long as the component continues to exist. But this text, that might change. And so what we turn that into, we turn that declarative code into imperative code that just updates the text when the state changes.

And that is a much more direct approach than, than the virtual DOM. I I should correct a misconception that I often hear about with virtual DOM though. The the performance problem, first of all, it's not catastrophic. Virtual DOM is acceptably fast for the vast majority of tasks. But when it is slow, it's not slow because of that diffing process. It's slow because in order to generate the virtual DOM, you need to reexecute your components for every single state change. And inside those components, you're calling functions, you're allocating memory to create, like, new arrays and stuff like maybe you're iterating over a bunch of items and then creating new virtual DOM inside all of those. Like, all of that mounts up, but it mounts up in this very subtle death by a 1000 paper cuts way, so it becomes pretty hard to And when you have a system that just issues that entire method instead of, in favor of just surgically updating the bits that did change, then You don't have that problem, and and things are much faster. And SALT is one way of doing that. There are others. Solid, for example, works around this problem in a completely different way. The what they have in common is they're not regenerating your entire application on every state change. Yeah. And and it it feels like they kind of like in React Well, the burden of performance then gets kind of passed to the developer who then has to institute, you know, memoization themselves and,

use callback and all these different, like, performance hooks that we have to then add to the code ourselves. And if you don't add them or you're not doing the performance best practices, you risk getting, like, a hit for that. So it's nice that you don't even have to think about that in in in Svelte World. That's been a a major performance increase in my life is just not having to even Think about memoization in that kind of way in the same way I used to in rehab. We need to put that on our Scott and I have a show in the notes right now that we've been working on. It's Called, like, do it for me or, like, why do I have to do this? And, like, that's a perfect point,

on there. You know? Like, it it's not necessarily like, look, oh, why do I have to do this? But it's It's a great one. It's how do you solve that problem? We just don't do it at all. You don't put that on your developers. Yeah. Don't put it on the developers. Yeah. I I like to think about the computer as as

being kind of like a a an intelligent butler. Like, you just tell it what you need, and it and it does it for you. Like, the idea is that The partnership between, the programmer and the computer should be such that the programmer is spending the bulk of their time on the creative aspects of web element. Mhmm. Not worrying about the plumbing, not worrying about the mechanics, just worrying about, you know, the architecture and the design.

And that is that is what humans are good at and the grunt work of figuring out, oh, did this thing change or not? Like, that is what

Computers are full. That's what computers are good at.

Yeah. I I often felt that way with CSS in the early days. People would always People always have these rules of, like, do this and don't do this and only animate these things. And it's just like, well, can't the computer figure that out for me? Like, why Am I memorizing these, like, obtuse rules for the best output? Can't the those obtuse rules be Output on a a computer that could replicate it? Exactly. This episode is also sponsored today by LightStep

response. The all in one incident response platform for DevOps and SREs.

LightStep incident response is built on the ServiceNow platform, which is used by over 6,000 companies.

You pay for the services you actually use, not the number of the people on your team, which is important Because you can scale your incident response team without adding to your bill. You get intelligent on call scheduling and escalations.

You can get the full context on your service health active alerts and who's on call. LightStep incident response immediately pinpoints issues And groups alerts with machine learning, reducing your time to respond. And this means less noise and more personalization for precise notifications where you can take control On declaring incidents automatically notifying the right teams, and you can get unified incident response by seamlessly orchestrating alerts An incident triage with on call scheduling across Slack, Teams, Zoom, desktop, and mobile. So what you'll want to do is head on over to light step.comforward/ syntax, and you'll get a free 30 day trial. Listeners of syntax will also Receive a free LightStep incident response t shirt after firing an alert or incident. So check it out. Are you in need of incident response? Check out lightstep.comforward/ syntax.

Here's a here's a interesting question.

What is your personal favorite thing about Svelte. Like, when you're working in Svelte, like, what what what's the thing that makes you be like, oh, man. This is this is awesome.

Oh, good question. In in in my position, I'm, like, very often creating new Test cases or simple demo apps to show someone a a concept or something.

I actually don't get to spend that much time working on big apps These days because I'm busy working on the framework itself, and it is really nice. Like, I I always get, like, A nice kind of warm fuzzy feeling on just how quick it is to create a new example or a new component, particularly with, Like, things like Sveltekit dot new, which fires up a Stackblitz, thing with a with a a SvelteKit app ready to go. Like, I can create workable examples with Svelte just incredibly fast, and I really enjoy that.

I guess I would be remiss if I didn't call out some of the the features that other frameworks tend not to include, things like scope styles, The animations, the transitions, things that allow you to add polish without needing to Sort of troll the ecosystem and make all of these decisions about which which packages you you're gonna invest your trust in. It's just kind of all all there, just set up, ready for you to use. I I much prefer that. We talk about that a lot where,

even even just guessing, like, what folder structure you need. Like, you you talk Lot of stuff in JavaScript land is just like, well, how do I do this? Well, literally any way you want, you can piece together any of these things Altogether, and you can choose your way. And a lot of developers go like, okay, but just tell me where to put my files and just tell me how to do my CSS. And, it's nice to have a little bit of choice here and there, but, man, is it nice when someone just at least for myself, I prefer magic, and I prefer somebody to tell me, how to do things. And it's really nice when, you get that without having being too constrained or too rigid. You know? Yeah. Con constraints are freeing. Constraints are freeing. That's a good way. Like, if you ever take a creative writing,

workshop or something like that, the the teacher isn't gonna be like, You know, here is here is a blank page. Write a story. They'll be like, okay. Yeah. Write a story about, like, A love triangle on a submarine or like something like that. They will come up with some sort of framework in which you have to be creative, and it's so much easier to do that.

And programmers often will bristle at that. The they'll bristle at the idea that their freedom is being constrained in some way, though, that they're that They're not able to go out and put together the, like, the best of breed of, like, all of the different possible libraries that they could use or or or build their own.

And so some sometimes you'll hear people say that, you know, the reason that React won is because it it kind of encouraged this this ecosystem of people, like, filling in all all the missing pieces, and I don't think that's why React won at all. I think React 1 in spite of that fact. Mhmm.

And it's also worth pointing out that when frameworks Do include a lot of this batches included stuff, and Vue is another example of a framework that provides you with a lot of tools to build stuff.

That doesn't preclude you from having used land solutions as well. It just means that you probably aren't gonna need to waste time going and looking for 1. Yeah. Yeah. Totally. So Did did React

win? And if so, why did React win? I know that's a bit of a loaded question. Or is is React, Like, I'm sure you talk to many people at companies that are switching from React to to Svelte.

Do you do you hear a lot of that? I definitely hear some of it.

Yeah.

One of the nice things about being, one of the nice things about working at the cell now is that, like, I actually get to hear from the sell customers who are who are looking at this stuff, whereas previously, I was in a little bit more of a bubble.