An internet radio show about the internet starring Dave Rupert and Chris Coyier.

Subscribe on iTunes or RSS

Twitter:

349 Talking Svelte with Rich Harris

00:57:16 Download

Guests

Rich Harris

Web // Twitter

Graphics editor at New York Times, investigations team. Open sourceror.

Show Description

We're talking about Svelte with Rich Harris - what does it add to HTML? Does bundle size matter? How does Svelte handle routing? And who's using Svelte? Be sure to listen for a preview link to Svelte v3!

Show Sponsors

Interested in sponsoring?

Time Jumps

Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--my good mic is broke--Rupert. [Laughter] With me is Chris Coyier.

Chris Coyier: Hey! Oh, I'm sure you sound fine, Dave.

We are--I don't know--halfway through, at this point, our idea for a mini-series of exploring the modern JavaScript landscape side of frontend development, in a way. We talked to lots of great people that we really consider leaders of that movement in that world of JavaScript.

This week is no exception. We have Rich Harris on. Hey, Rich. How are you?

Rich Harris: [Inaudible response]

Chris: Fantastic.

Dave: Good.

Chris: Rich, one of the big projects you work on is called Svelte. I've confirmed with Rich that I pronounced it correctly too. It's not "sa-veel-tae" or "sa-velt" or any kind of weird thing.

Dave: "Sa-vee-chae."

Chris: It's a real word. It means light, lean, and trim, right?

Rich: That's it. It means lissome, slender, graceful, all the things that you want to have of a JavaScript framework.

Chris: Fantastic. Can you tell us who you are, where you are, what you do? Then I'd love to talk about Svelte a bunch especially because you're on the heels of a 3.0 release. But maybe a little bit about you first.

Rich: Sure. I'm a graphics editor at The New York Times. My background is in journalism, and I came into JavaScript as a way of doing more interactive and data-driven journalism.

What I do here at The Times is I make a lot of interactive graphics and charts. I built internal reporting tools. I do all that in the context of the investigative team here The Times working on stories primarily around technology, algorithms, and topics like that.

Chris: Okay. I don't know. An article is coming out. You know that because you're in the newsroom and it needs some data vis amazingness to it. You're the guy, sometimes, or are on a team that does that type of work.

Rich: I'm part of the team. There's a group within the investigative unit comprised of me, Michael Keller, who is a reporter who has a deep background in data visualization and things like that.

Chris: Yeah.

Rich: Michael and Valentino-DeVries, who is one of the best reporters I've ever met, and my editor, Gabriel Dance. The four of us, we work together on stories, trying to use our overlapping skills to bring to bear on some of these stories, trying to make them -- we get a lot of these stories that are kind of abstract, a little difficult to understand, talking about privacy issues and stuff like that. In combination, the thinking is that we can do slightly different forms of reporting and make some of those issues slightly more vivid to a lay audience.

Chris: Right. A paragraph is one way to explain something, but a chart is another. I'm sure there are many other interesting ways to kind of get a point across, right? The Times is really good at that, right? I'm sure it must be a fun place to work because of that commitment to that.

Rich: It absolutely has a strong commitment. It's one of the newsrooms that made a big investment in doing digital journalism back when a lot of other news organizations were still figuring out this whole Internet thing. It's built this really deep bench of graphics editors, people who have backgrounds in journalism but also bring skills from areas like cartography, data visualization, virtual reality now, augmented reality, all of these different fields combined into a graphics department that can build some of the things that you're talking about.

Chris: I always think so much of, like, newsrooms plus data vis equals D3. [Laughter]

Rich: Yeah, well, D3 came out of The New York Times graphics department. It was created by Mike Bostock. It originated as an economic research project, but it was at The Times that it became the sort of de facto toolkit to building data visualization on the Web.

Chris: Is it still? What do you do? Do you reach for it sometimes or reach for other things? Are you agnostic in your tooling?

Rich: I have a slightly more nuanced relationship with D3. D3 is still very much the de facto package that the people reach for when they're building data visualizations. Back when D3 came out, it was very container Web development, and D3 was this sort of all-encompassing thing that did all of the complicated stuff around generating paths for charts with the correct type of smoothing or projecting, geodata with this suite of different projections. Then they would also be responsible for the DOM manipulation that takes place at the end of that process.

Nowadays, the landscape has shifted a little bit. You tend to have frameworks that do the DOM manipulation for you. Where D3 fits in for me is as this sort of grab bag of tools that I can use to do all of the really painful mathematical academic stuff that is just way too complicated for a single-brained man like me to do myself. But then it doesn't do the DOM manipulation. I take the output of D3 and I hand it to Svelte and Svelte is responsible for actually displaying the data onto the screen.

Chris: Yeah, that seems -- D3 has some basic DOM stuff in it. You just don't use any of that. You're just like, "No, you do the thing where you draw the arc. But once you're done with that, I'll take it and do my virtual DOMing or whatever I'm going to do with it."

Rich: Exactly. We've seen people do that with other frameworks too. There are a lot of articles and talks and presentations out there showing how you can use D3 with React, for example. An advantage of keeping that separation is that you can do things like server-side rendering with D3, which D3 has a DOM manipulation framework.

Obviously, it doesn't let you do it the same way because you need a DOM. If you're just using it as a path generator, for example, then you can generate SVGs on the server side. If they don't even have any interactivity, then you don't need to ship that JavaScript to the client. For me, that is the sweet spot. That's the best of both worlds.

Chris: I hadn't even thought of that. That's pretty cool that, by removing it from the DOM, you can still -- you've still got to render it. I don't know. It's above my head, so I better not drill into it too far.

You've mentioned React and Svelte. Now, we all know what React is, but maybe less people know what Svelte is. It's going to be your--

Rich: [Laughter] That is definitely true.

Chris: [Laughter] It's your brainchild, I think. I don't know. Why don't you tell us about it without me making any assumptions? What the heck is Svelte?

Rich: All right, let me try and do this. At a very high level, Svelte is a way of building Web applications. The idea is, it will build Web applications that are smaller and faster than applications built with the frameworks that you're used to.

The way that it's able to do that is by taking a very different approach to the process of building an app instead of being this sort of ball of JavaScript that interprets your code in the browser. In other words, you give it a virtual DOM and then it kind of figures out how to translate that into something that appears on the screen. What Svelte does is it takes your component and compiles them into vanilla JavaScript at build time.

All of the heavy lifting that would normally be done in the browser is done as part of your build step. What that means is the JavaScript that you need to search the browser is much smaller and it's typically much faster.

Chris: Interesting, so there's a heavy build step to this, which there isn't maybe in other frameworks, which is maybe spiritually connected to server-side rendering, in a way. When frameworks find out that, gosh, if we do a bunch of work ahead of time and ship that in a lower level language, there are performance benefits to it. You're saying you write in this -- I don't know. It's not a language to itself, right? It does compile down into something else?

Rich: It compiles. You can say that it is a language. We can sort of get into the nuance around that. That whole idea of trying to shift work out of the browser whether it's in the form of server-side rendering or something else, that's exactly what Svelte is all about because a lot of frameworks, the way that they will sell themselves to you is, we're going to make all of this simpler. We're going to make your code simpler.

The reality is, the work still has to happen somewhere. Either the work and the complexity sits in your code base or in your head, it sits in an external library or framework, or it can sit in your build process. One of those three options is better for users because it results in bug-free applications, but it also doesn't mean that you're serving a lot of JavaScript that has to do a lot of work when users are trying to use your application.

Dave: Is that built out of your experience, like with The New York Times? I mean I imagine you probably have numbers on how many seconds a user is going to wait for a page to load, right?

Rich: Svelte actually started before The New York Times. It was something that began at The Guardian U.S., which is where I was before. I came to The Times, but it's born out of a similar set of frustrations that I had with the existing tools.

It's actually a successor of a sort to an earlier project that I did called Ractive, which was part of the sort of 2012, 2013 era of frameworks. It got used in a few places like it's been used inside Apple, Amazon, a major Wall Street bank, and places like that. It never sort of cracked mainstream awareness, but it was very heavily used by us at The Guardian.

At the time, I sort of realized that I was part of the problem that it was seeing with JavaScript load because even though Ractive was kind of this pretty easy to pick up and use framework, and it was pretty performant because of how it was implemented, it was getting a little on the chunky side. And so, I kind of took a step back and started trying to imagine ways that we could do the same things that we were doing already with a similar kind of developer experience, but without shipping unnecessary JavaScript to the user. The compiler approach is your biggest way to deal with that problem.

Chris: The mental model is still components, yeah?

Rich: Very much so, yeah.

Chris: Very much so, so you make a component. Component.html and component.javascript, right? It is kind of a language to itself? I mean it looks like it, as you look at this a little bit.

There are unusual things in the HTML. The HTML isn't valid or whatever by itself, right? There's weird stuff like curly brackets around LI elements that form loops and stuff.

It's HTML, but it's your version of HTML that's intended to be compiled out. Then it by itself doesn't do anything either. You also need component.js to--I don't know--feed it the data that it needs, right?

Rich: Not quite; the second part, not quite. A component is a completely self-contained thing. It does start out as HTML. Valid HTML is also valid Svelte. The thinking there is I'll built out of HTML. HTML inherently can already contain file tags and script tags. If you're trying to co-locate files … behavior, it makes much more sense to do it in the context of an HTML environment than to try and force HTML and CSS into JavaScript. That might be a slightly controversial opinion, but it is a correct one. [Laughter]

Dave: Eh!

Rich: And--

[Laughter]

Dave: It makes sense. We just had somebody from the Web component land talking about HTML modules, which is importing. There's a new proposal to import HTML into JavaScript. But it's technically not something you can do right now, right?

Rich: Right. With that starting point, we add the missing bits in HTML that allow it to be a data-driven language. Then the style and the script, in combination with that, form a self-contained component that you can then import into a JavaScript module and use as a standalone thing. It's just an instance of a -- well, not an instance. It is a JavaScript class at that point.

Chris: The compiled output is a class?

Rich: The compiled output is a JavaScript class, yes. You would do input widget from ./widget.file and then you give it a DOM element to render to, and that's your application. At that point, it's sort of self-contained. It's got its own lifecycle. It's got its own state management.

At that point, you can interact with it from the outside, but you don't necessarily need to. You don't need an additional library to render that. It's all baked into the component itself.

Chris: Yeah, okay. What you load on the page, there is no Svelte.js on the client because it's a class by that point and you don't need anything.

Rich: Exactly. Yeah.

Chris: Wow, that's pretty cool. You don't ship any lib. It's a compiled lib. That's cool.

Rich: There is this internal library, which contains some helpers for constructing DOM elements and stuff in a way that's more minifiable than doing document.createElement all over the place. Those implementation details are basically hidden from you as the compiled author.

Chris: [Laughter] It is all still JavaScript, in a way, but you kind of alluded to it being server side rendering friendly, though, in a way, or it optionally can be?

Rich: What I've described so far is the client-side version of the cell component. When you compile your component, it turns it into this JavaScript class that I described. Then you can use that in the context of a client-side app.

You can also generate a server-side rendering friendly version of that component, which is completely different because it's trying to accomplish a very different job. Instead of creating a tree, which has this long life, you are just generating a string of HTML. Those are two very different things.

When you compile it with, we say, the generate SSR option, then what you have is a JavaScript object with a random method. Then you feed it some data and it will just return an HTML string. The way that it's compiled, it's able to do that server-side rendering blindingly fast, so much faster than you could possibly do by serializing a tree that came out of a language that was supposed to work in an ordinary browser.

Chris: Do you find yourself using that a lot because of the end result of maybe something you had to do at the time isn't particularly interact, it's just whatever?

Dave: Yeah. Your AWS costs are going to be lower, essentially--

Chris: [Laughter]

Rich: --as a result of doing this. Because of some of the intricacies of the project template that we use for graphics at The Times, which really aren't worth going into, I haven't got around to setting up server-side rendering for stock components for graphics that we do here at the moment, but there is a companion framework to Svelte called Sapper, which is, in the same way that React has Next and Gatsby, Svelte has Sapper, which is this app level framework that does your server-side rendering, serves some static HTML to the client, and then the client kind of seamlessly hydrates that with a client-side version of the same application. And so, you get the benefit of the extremely fast, initial load.

Chris: Yeah.

Rich: With all of the progressive enhancement built in. Then, for subsequent navigations, you get this app like client-side immediate application.

Chris: Don't they call that hydration or whatever, right?

Rich: Right.

Chris: You get the server side rendering and it grows up to be a JavaScript app, if it can. That's great! So cool!

You pushed; really and philosophically, intentionally pushed as much as you can to the build step.

Rich: Yeah.

Chris: That's the guiding principle here, almost.

Rich: That is the guide. Well, we need to write down our guiding principles. That is one of them. Yeah.

Chris: [Laughter]

Rich: Complexity cannot be created or destroyed; it can only be transmuted from one form into another. To the greatest extent possible, we want to push that complexity into a build step so that it exists in one place and doesn't burden all of the users.

Chris: It's nice that that's step one, or at least it's in the guiding principles somewhere rather than, "Let's make this great DOM library and then figure out a way to push it into a build step if we can," as a secondary afterthought kind of thing or something to be left to third parties.

Rich: Yeah, although, I think the idea has caught on a lot more. It was pretty novel, I think, back in 2017. Was it? I think it was 2017. Yeah, 2017, when we did the first version of Svelte. Maybe it was 2016. Crikey.

Chris: It's still pretty new.

Rich: It is still pretty new, and these things have a pretty long, long way before they sort of break into the mainstream awareness, I've found. It's still very much a … with the JavaScript frameworks. But even still, I think the idea of trying to do as much work ahead of time as you possibly can is something that is kind of standard nowadays in framework design.

Angular has a pretty good concept of ahead of time compilation. They're building this new rendering engine called Ivy, which is, dare I say, slightly Svelte-ish.

Glimmer, from the Ember team, compiles handlebar templates to a very efficient bi-code format, which is another take on a similar idea. That's very interesting.

There are a couple of other frameworks like Marko from eBay is doing some of this stuff. The next version of View is going to be doing some slightly more sophisticated stuff that built on, if I understood their roadmap correctly.

Svelte is not the only framework doing this at the moment, although it's still possibly the purest expression of idea since it is compiling to self-contained vanilla JavaScript.

[Banjo music]

Chris Enns: This episode is sponsored by Netlify.com. Netlify is static Web hosting without limits. You can start with a drop-dead simple deployment workflow and then go further with dynamic tools you can manage right in your dashboard. They've got everything you need to deploy your project because you shouldn't have to be an architect expert to build and deploy a feature rich site.

When you're ready to push your site live, you can deploy your site an ultra-redundant, global application delivery network that's purpose-built for serving pages and assets quickly and consistently. You can automate deployments using Netlify's built-in continuous deployment that automatically runs your build commands and deploys the results whenever you push to your Git repository.

If you want to add a custom domain, you can buy a custom domain through Netlify or add a domain you already own. Manage GNS zones and records using Netlify's DNS hosting. Of course, HTTPS is automatic. Your site will automatically be secured with a free TLS certificate from Let's Encrypt. No clicks necessary.

Any time you want to preview your changes, you can see what they'll look like in production using Deploy Previews. Get a unique, permanent URL whenever you submit a pull request. It's posted as a commit status for easy collaboration.

You can deploy AWS Lambda functions without configuring API gateways, coordinating deployments, or setting up an AWS account. Your functions are version controlled, built, and deployed along with the rest of your Netlify site. The Netlify API gateway automatically handles service discovery. Plus, your functions benefit from the power of Deploy Previews and rollbacks.

You can also manage signups, logins, password recovery, and more all without rolling your own authentication service. Register and authenticate visitors to your site so you can gate content, enable CMS functionality, make authenticated calls to outside services, and more. You can securely integrate with any service that understands JSON Web Tokens.

In the past, forms on static sites were always a pain, but you can manage forms and submissions without any server-side code or JavaScript on Netlify. Just code an HTML form into any page on your site, add a Netlify attribute to the form tag, and you will receive submissions in your Netlify dashboard. HTML files are parsed directly at deploy time, so there's no need for you to make an API call or include extra JavaScript on your site.

Of course, you can bring all your favorite tools to Netlify, whether you're creating your own customizations, extending your workflow with open source projects, or integrating best in class microservices. Netlify's highly extensible APIs lets you add as little or as much tooling as you need. Netlify has got pricing for every project, so visit Netlify.com and deploy your site to global infrastructure in sections. Our thanks to Netlify for sponsoring this episode.

[Banjo music]

Dave: This is actually educational for me because, not to throw another framework under the bus, I sort of wrote a React thing, a component, and then I ran it through Babel Webpack and did all that work. In my brain I'm like, "Yeah, I did it. I compiled it. You see?" But I think the level which you're talking about compiling and the level at which my little Webpack script worked are kind of different, right?

You're kind of saying, "We don't just--" Maybe my React app is still trying to negotiate JSX on the fly. Is that right, the templating? Yours kind of bakes out all the JavaScript to build the template….

Chris: Your component is useless unless there's React and React DOM loaded on the page, whereas the Svelte component needs nothing.

Rich: That's it. The JSX, the JavaScript transformation is reversible. People talk about JSX as syntactic sugar and that's all it is. It turns your

Dave: Sure.

Rich: The transformation that's happening there is actually very slight. There is a project by the creator of Webpack, Tobias Koppers, called Rawact, which is kind of an attempt to do with JSX what Svelte does with its components. It's definitely one to watch but, overall, I think React is the framework that is going to have the hardest time reacting [laughter] -- reacting: I didn't mean to do that -- responding to this shift in the framework ecosystem.

Dave: Just because, like Chris was saying, to render a React app, you need all of React and React DOM on the page. But your goal is to kind of compile away the framework, right?

Rich: Exactly. If you start from that point, then you will design the framework in such a way that it can be straightforwardly compiled.

Svelte components, I don't want to give the impression that this is sort of constraining what you can do as a component author the template syntax of the Svelte component is designed with compilation in mind, whereas JSX, because it is just JavaScript, as they like to remind us, it's very, very difficult to compile that in a completely optimal way.

Dave: Right, because at some point you're writing HTML and an HTML parser is a hard thing to write but it has to kind of like switch modes, right? It has to. "Okay, now I do JavaScript here and end it here." Yeah.

Rich: Yeah, the fundamental problem is that inside the curly brackets in a piece of JSX, you could have literally any JavaScript expression whatsoever. It's extraordinarily difficult for a compiler to look at that and say, "Oh, we know what the range of possibilities are at this moment."

Instead, you're sort of forced to have the virtual DOM and you're forced to have a virtual DOM reconciliation mechanism. That's where a lot of the cost lies.

Dave: You said Svelte ships with like a very minimal sort of helper library. I guess, what's inside of that? I see some component methods in your docs, like component.get, component.set, component.on, component….

Rich: You're looking at the V2 docs.

Dave: Oh, really? I'm way too ahead.

Rich: [Laughter] Yes.

Dave: Is V3 different?

Rich: V3 is kind of a ground-up rethink of the experience of authoring a Web application. It's very different to V2 in a sort of regrettable Angular 1 to Angular 2 type break. We're actually recommending that people don't start their applications with Svelte V2 at the moment because, in hopefully a week or two depending on how much free time I can carve out, it's going to change. V3 has a different API.

But in terms of the earlier question, quickly, it's actually not that minimal, the internal library. What it is, it's tree shapeable. The component will only import the little bits of code that it needs to do its job. You can have a component that does very little work and it will only import the very tiny helpers that it needs for that. But if you have a component that needs to do, for example, rich transitions between states, then it might need to import some more stuff.

The framework is very featureful. It has a lot of stuff, but you don't pay for those features. They sort of decouple the feature set from the bundle size in a way that has historically been quite difficult for frameworks to do.

Chris: That's pretty interesting.

Dave: Yeah. It seems like next level. [Laughter] You've worked on compilers before. I know you've worked with Rollup and things like that. That's more like a packer, I suppose. You just kind of understand how this all works and this translates. Is that kind of what you're leveraging?

Rich: [Laughter] I sort of stumble around in the dark until things work is my development process. You're right that I've kind of dabbled in this space before. I created the module bundler called Rollup, which, essentially, what it does is it concatenates JavaScript modules. But in order to do that, it needs to understand the contents of those modules to quite a deep level. And so, I've spent a lot of time with tools like Acorn turning JavaScript into abstract syntax trees and then traversing over those trees and doing various forms of strategic analysis.

I also wrote an ES6 to ES5 compiler a while back called Buble, which is a sort of cheeky take on Babel just because I didn't like the way that Babel sort of forced me to do things. This isn't entirely new territory for me. I would say that the experience of working on those two projects gave me the sort of baseline of knowledge and the confidence that something like Svelte would be possible.

Dave: Wow. If somebody was making in those blog posts where they're like, "Let's compare the frameworks. React is 30 kilobytes and Svelte is 150." They measure the bundle size or whatever. For you, that's completely inaccurate because your framework tries to compile away from existence, right?

Rich: It is kind of a different question, but I would say that it's a meaningless comparison to draw in the first place. You can't compare the size of React with the size of Ember, for example, because Ember is doing a ton of stuff that React is not doing. The same is true for React and Preact. They look similar, but these things have kind of overlapping goals and responsibilities, but it's always going to be an apples-to-oranges comparison.

What you really need to do is look at the size of an application that uses these things. That's difficult because you're not going to have many situations where you have the exact same application that's been built with different frameworks. It is a little bit difficult to compare and contrast these things. I think a lot of it needs to be based on understanding what they're trying to do and making a qualitative judgement about which framework is right for your needs.

There is one attempt to compare these things side-by-side called The Real World Project. I don't know if you're familiar with that.

Dave: Yeah, I mean I've heard of it, I would say, but is it kind of like the next level of the Todo app sort of thing?

Rich: That's the intention, yeah. It's supposed to be the succession to TodoMVC, which doesn't really give you a very good idea of what using these frameworks is like day-to-day. It's a basic media clone, and it's been implemented in lots of different frameworks like React, obviously, React with Redux, React with MobX, Elm, View.

Chris: That sounds really interesting because that's what I wanted to ask you about. Can we approach this, for better or worse, from a developer ergonomic standpoint?

Let's say, in your app, I want to render a /movies page and I need /movies/theavengers or whatever. I need a little routing, right? Does Svelte even go there at all or are you saying, "Well, we compile down to HTML so, if you want routing, you have movies.html and then you put a folder called movie. Inside of movie it renders avengers.html. There's your routing," or is there JavaScript? Do you have a routing situation?

Dave: Svelte itself is completely agnostic as to what kind of routing message you prefer, so I can't put a … it's routing, and that's that.

Chris: Uh, sir!

[Laughter]

Rich: If you're looking for an official Svelte reader, then it is Sapper, and Sapper has a similar approach to Next and Nut in that, exactly as you say, you have a fold structure that contains these components and, as part of the build step, Sapper will look at the contents of your folder. It will understand the shape of your application and the different routes that the user could reach, and it will build a read manifest based on those. Then at turn time, it will pick the right component based on the current route. It will dynamically import it so that you get code splitting and all of that stuff for free. Then it will render the right page.

Chris: Hmm.

Rich: That is -- we do have--

Chris: So, it's an add-on. That's as close as you get to an official thing. Otherwise, do it….

Rich: Exactly, yeah.

Chris: You clearly have some state management. That looks pretty covered pretty well. You have a state or a set kind of API and it takes an object.

Rich: This is one of the things that's really different about V3. In fact, this is kind of the motivation for the big….

Chris: Okay, because everybody needs state. If we're going to make these components, that's another thing we agree on is we all need state, right?

Rich: Everybody needs state and Svelte has a slightly different take on this question to other frameworks. I'm going to struggle to describe this in the context of a podcast because I really need to show you some code. Basically, what we've done is, and tell me if this is a gibberish way of describing it, we've taken state management and reactivity out of the component API and we've moved it into the language itself.

Inside a component, you're going to have some state. You just declare them as variables. If you're building a counter component, you have let count equal zero. Then you'll have an event handler that is maybe triggered when someone clicks a button that increments that variable, whereas in Svelte 2 you would call a method on the component to change that state, whereas in View you would have this.count+=1, whereas in React with hooks you would have set count count+1.

In Svelte 3, you just do count+=1. You literally just assign it to the variable and the compiler instruments that with a call that tells Svelte that a state change has taken place and it tells it which piece of state has changed. It tracks which changes have occurred and, through that, it knows exactly which parts of the DOM it needs to re-render.

Chris: Hmm. Any variable that you declare in a component is kind of like local state to that. It's like localized to that.

Rich: Yes. Some of those variables aren't used in the template, so they don't get that reactive treatment applied. It's smart about what it does that to.

Chris: Oh, I see.

Rich: But, basically, the idea is that, historically, one of the big problems that frameworks are trying to solve is how do we tell the computer that this state has changed so that it knows that it needs to update the view? View kind of figured out years ago that we had a really good way of telling the computer that some state has changed. It's called an assignment. You just to this dot whatever equals new thing.

The difference with View is that it has to have this class instance and it has to have accesses or, in View version 3, proxies which capture that assignment. Because … compile time, we just reassign free variables and it has the same effect. The result is this wonderfully boilerplate free, very expressive way of writing things. When you compare a component written in, say, React with hooks versus the same component written in Svelte, the Svelte component is always drastically smaller. The ratio of code that expresses the programmers intent to code that only exists for the benefit of the framework is way higher.

Chris: Yeah, that makes sense.

Dave: Wow. Can I workshop some names for this? Hookless.

Rich: [Laughter]

Dave: I'll call this hookless state.

Chris: Mm-hmm.

Rich: We call it reactive assignments, internally. That was the name of the RFC that began all this. Reactive assignments is sort of the catchall for the way that Svelte thinks about reactivity and reactive programming.

Dave: It's cool. It's reactive out of the box. I didn't have to set anything else up. Your compiler is intelligent enough to understand, I want this to update. I've included it in the view. [Laughter] So, if it updates at any point, just re-render the view?

Rich: Exactly. It'll do all of the batching and scheduling and stuff.

Chris: The way state is used is, like -- I mean there are millions of ways. Let's say there's a tabs component. It's active tab two, so the second tab has a class of "is active" on it, or whatever. It will do all that stuff, right? You've changed an integer to two, but then something re-evaluates. "Well, if that happens to be two, then I need to change this active string name," or whatever.

Rich: Yeah.

Chris: It'll just do all that.

Rich: It takes all that stuff of the list of things that you as the component author need to worry about.

Chris: Okay. I do think of state, generally, in two ways, although it may be Svelte just changes the way you're supposed to think about these things. One of them is, okay, it's a tabs component, so which tab is active is a kind of piece of local state, but maybe the tabs, like there's a fifth tab if you happen to be logged in and that logged in state happens at a different level. This component just assumes that it knows about the logged in state, but it has no responsibility for setting it to it, but it does need to react to it. Do you have to think about those things differently, like global and local state?

Rich: There are two ways that you can have state that exists between components. One way is, as in any other View framework, you have this concept of props. If I have a component inside my component, I can pass props to it.

Chris: Mm-hmm.

Rich: As far as that component is concerned, those props become part of its own state. The other thing that we have, we call it a store. It kind of works the same way that you've seen stores work in other systems. A store represents a value. It's like an observable value, basically, and you can use that store without even using Svelte. It's just an object that have a value and you can subscribe to changes on that value.

What Svelte adds is it adds a tiny little bit of syntax, which makes the value of that store reactive inside your template. If you have, let's say, a global volume value and someone wants to slide that between zero and one at the top level of your application, that's a store any component anywhere in your application can import that store and just use that value on an audio element, for example, and that's how we think about cross-component state management. It seems to work pretty well.

Chris: It sounds like there's less to think about, in a way.

[Banjo music]

Chris Enns: This episode is sponsored by WordPress.com. WordPress.com gives you everything you need to create anything you want on the Web. Whether you want to build a fan base, open a store, start a blog, design a portfolio, WordPress.com is where you can host that.

You may be familiar with the self-hosted version of WordPress, the popular CMS that a lot of developers use, but what you may not realize is how easy, powerful, and inexpensive WordPress.com is to host your WordPress site. WordPress.com has plans for any budget. You can start for free and get your website running quickly. Then you upgrade for advanced customization and themes, additional storage space, and business tools. You can build a blog, a full website, a combination of both, write about your life, build a beautiful portfolio of your work, or build a robust business site. It's all up to you.

WordPress has got a fast, intuitive editor that includes HTML and Markdown support, and they save your work every few seconds so you'll never miss a word. Of course, WordPress.com has Jetpack essential features built in, including sites statistics, basic SEO, and social media sharing.

If you're like me, maybe you haven't tried WordPress's mobile app in a while in iOS or Android. It's worth checking out because you can update your site from anywhere on the app.

Free plans get their choice of a few themes and, if you upgrade to a paid plan, you've got hundreds of themes that you can choose from for any kind of project. You can visit WordPress.com/themes and check out hundreds of premium themes that are vetted and supported by WordPress.com. Your site doesn't have to look like the traditional WordPress blog with text on the left, sidebar on the right. There are tons of options for different layouts and styles. Portfolio, website, magazine, blog, business, a wedding, travel, food, maybe a wedding travel food blog, or just a music blog.

In the past, you may have thought you couldn't install plugins but, using WordPress.com business plan, you can install any of the thousands of free plugins available. You can add a store with WooCommerce. Try advanced SEO strategies with plugins like Yoast or support multiple languages with Polylang. With unlimited WordPress plugins, you can build anything you can imagine and customize it to meet your specific needs.

Visit WordPress.com today and build exactly the kind of site you need. Our thanks to WordPress for sponsoring this episode.

[Banjo music]

Dave: I'm impressed. I think Svelte comes up in conversations. Googlers, I guess, I see, they step into framework drama quite regularly.

[Laughter]

Rich: (Indiscernible)

Dave: Preact or Svelte always seems to be kind of on the list of, "Hey, maybe less JavaScript would work for you." I'm kind of blown away. I knew it was a framework. I knew it has component-y structures. But I don't think realized how cool it is that it kind of does a lot for you and then tries to disappear. It's sort of like I'm picturing like when you do those introduction emails to people, like in your company or whatever. You're like, "All right, here, you two meet. There you go. I'm going to step out." [Laughter] I think that's really, really cool for a framework to do.

Rich: It tries to do as much of the grunt work as possible. Because it has this slightly different design and architecture, it's able to have a lot of features that you wouldn't conventionally include a View framework.

Because we're so paranoid about bundle size, we tend to have this preference for things that are minimal. If you want to add new features, then you had to go and find a suitable library that interops with your framework. It becomes this whole sort of teetering tower of dependencies. That is something that I, frankly--particularly working on newsroom deadlines--don't have time for that. I just want something that contains all of the things that I need to do to build an application which also allows me to operate with whatever are the tools that exist in my toolkit.

Dave: You need D3 whatever cartography map. You don't need -- or you can't wait around for React D3 cartography map or whatever.

Rich: Right.

Dave: You just need kind of lower level.

Rich: You need the lower level stuff but, also, you need to have styles, right?

Dave: Yeah.

Rich: You need to have a way of thinking about changes in state between like when an element comes into the DOM and it leaves the DOM. Maybe you don't want it to just appear. Maybe you need some kind of a transition. Maybe that needs to be controlled pragmatically.

All of the things that go into building a really slick, pleasant to use user interface, a lot of them are kind of left as an exercise to the reader by some frameworks. Svelte takes a different view. It takes the view that you should be able to do this stuff without having to leave a dozen different languages. But, at the same time, if you like using them, you shouldn't pay for them … features. If you like using transitions, then you shouldn't pay for transitions.

Dave: Yeah. We just had Jason Miller from Preact on. They take a very hard kilobyte line.

Rich: Yeah.

Dave: It's three kilobytes, hell or high water. They're doing great. I think that's amazing that they do that, but that does mean, oh, a new feature like hooks. It's kind of dicey on how you're going to support it if you stick to your hardline. They're doing it, but it took a big rewrite also. [Laughter]

Rich: I like Jason, and I think we agree on a great many things. But on this issue, I think we're diametrically opposed. It sounded to me -- because I listened to that episode, it sounded to me like what he was saying is that having that hard limit makes it easier to maintain the library. That's a maintainer-centric way of looking at the problem when we should be looking at these things from a user-centric point of view.

Dave: Right. Well, is his user-centric not just less kilobytes equals good? But I think your user-centric point of view is--

Rich: My user-centric point of view is more features equals good, essentially.

Dave: More features, but also--

Rich: As long as you don't end up with this crazy API with tentacles all over the place, then having a framework that does the things you need from your framework is the direction to go in. I think the only other framework that really shares that philosophy is Ember, but Ember is obviously a very different beast to Svelte.

Chris: Has Svelte found a place? Has it clicked with a certain type of developer, a certain type of project, or certain type of situation? Have you found that over the few years it's been alive that it hits a certain person the right way?

Rich: I'll give you a couple of extreme examples. Last month, a developer in Brazil shared that it's being used for point of sale systems in Brazil. There are like 200,000 of these devices in the wild. His job is to build this interface for the point of sale system. They're working with a very outdated version of WebKit on extremely memory constrained and performance constrained hardware.

They tried a dozen different frameworks and none of them were up to the task. You would press a button on this interface and, half a second later, it would respond, which is kind of an awful user experience because you're more likely to press that button twice and end up overcharging your customers or something like that. They tried it with Svelte and it worked smoothly, so that is an example of what you can do when you have a framework that has a very, very low memory footprint and very good performance.

Another example, we have a guy using it in the context of smart televisions, which also tend to be quite constrained devices.

Dave: Weirdly.

[Laughter]

Dave: It's always the worst UI in the world. It's 8 FPS every time. [Laughter]

Rich: Right. I think our community, at the moment, it's people who really care about performance, to the extent that they're prepared to issue traditional frameworks. But once it gets a little bit more awareness, and I think that is starting to happen, like it was the number one write-in for the question, "Which frontend framework do you use?" in last year's State of JavaScript Survey. It is starting to pick up a little bit of steam.

It'll be interesting to see if it does attract a particular community or developer. At the moment, as I say, it's people who obsessively focus on performance. I think Svelte 3 is very largely about making a framework that appeals to developers beyond that because it has this really nice developer experience. It's a much nicer developer experience than Svelte 2 was.

Chris: That's kind of a big deal. We mentioned the maintainer experience and the user experience. I would think, much bigger than either of the two, unfortunately, for better or worse or whatever, is that developers make decisions based on developer experience. Maybe that's not good all the time, but it's a little hard to blame them when productivity is on the line and whatever else, deadlines and stuff.

Rich: Yeah, and I still prefer the Svelte 2 developer experience to certain other frameworks, but people have preferences and it is pretty hard to shake those preferences. I think the idea now is that there's really no excuse in terms of, "Oh, I don't know how I would use this in the context of my application." It's really simple. It's really straightforward to use, and so, hopefully, we're going to be able to appeal to a slightly broader base.

Dave: Cool. I guess we should probably kind of wrap up, but I had two more questions. Is there a situation where I shouldn't use Svelte? I think frameworks are opinionated and make decisions, but is there sort of something like, if somebody had a weird constraint you'd be like, oh, probably don't use this?

Rich: I can't really think of a kind of application that it's not suited to. I think the reasons that you would choose not to use Svelte are more social. You've already got a lot of experience in a different framework and it's working well for you. You shouldn't embark on a big rewrite just because something new has come along. You should only do that if you need to because you're hitting a performance barrier of some kind. Or if you're working on a large team with other developers and you don't want to make them learn a new framework, then you probably shouldn't use Svelte.

Dave: That all plays a part. I'm on a project right now. [Laughter] We're like, "Well, you know, maybe. I think we need it. It's time for a JavaScript framework," is sort of our discussion.

Then one guy is like, "I know Angular."

We're like, "Okay, yeah, Angular might work in this context."

He's like, "I'm writing it in in Angular."

You're like, "Oh, we should talk about it."

He's like, "Nope, I'm committing code in Angular."

[Laughter] It's like, "Oh, I guess we're on Angular."

Yeah, it's stuff like that. You're like, uh--

Rich: Yeah.

Dave: I think that social reason plays a part in any sort of framework.

Rich: Definitely.

Dave: Then I guess, how can people kind of Hello World this? Just follow the docs or--?

Rich: We have a playground on the website, Svelte.technology. If you click on the REPL link in the navigation, then you can start trying it out. That has a download button. You press "Download" and it will give you a prepackaged application ready to go with the bundler integration set up, all that stuff, and it's pretty easy to take away from there.

We actually have a blog post as well on the easiest way to get started with Svelte. We're trying to make that onboarding experience as easy as it can be given that it's such an unconventional approach in terms of not having a thing that you NPM install and then point to your application. We've tried to make that onramp as gentle as possible.

Yeah, I would say hop onto the website and give it a go, although maybe wait until we've got version 3 out the door.

Dave: [Laughter] Cool. Well, we'll look forward to it. Follow it on Twitter. I notice you all are super close to 10,000 stars.

Chris: What!

Dave: Shop-o-maniacs, go out and give--

Rich: Get in there. Yep.

Dave: --give the boost.

Chris: Dang!

Dave: Almost there, Shop-o-maniacs. Go click that star button. Put it over the top.

Cool. Chris, did you have anything else you'd like to say?

Chris: No. Thanks for this discussion. This was awesome. It's different than I thought. I have never -- I mean I apologize. It makes me a crappy podcast host, but I haven't even spun up a Hello World Svelte thing yet, but now I'm much more compelled to. It seems fascinating. I'm just in the mood to play with new things lately, so this will definitely be on my very soon thing to build something with. [Devious laughter]

Rich: Well, if you want to try out the new version, then just put V3 in front of the URL, v3.svelte.technology, and that'll become the main website once we've launched. But you can try that out.

Chris: Yeah. I only use new things, so that's great.

Rich: Yeah.

Chris: Ooh, even the design of it has been Svelted.

Dave: Oh! Whoa!

Chris: Mm-hmm.

Dave: This is Sveltier for sure.

[Laughter]

Dave: This is great. [Laughter] Man, secret URLs on the ShopTalk Show. This is wonderful. No, this is cool. I think I'm understanding how much the tool can affect the output, if that makes sense, and that's very cool to see here.

I guess, Rich, thank you for coming on the show.

Rich: Thanks for having me.

Dave: I appreciate all your contributions to The New York Times. They are always pretty amazing visualizations, and you did a privacy kind of look into Internet privacy recently that was pretty amazing.

Rich: Yeah. It turns out that everyone knows where you are all the time.

[Laughter]

Dave: Oh -- hopeless.

Chris: One less thing to worry about, you know.

[Laughter]

Dave: Hey, if you ever need to interview me, I ate a box of Cheez-Its and then YouTube was sending me Cheez-Its ads, so think about that.

Rich: Huh.

Dave: If you ever need -- [Laughter] If The New York Times ever needs to kick off an investigation, just call me. I guess, for people who aren't following you and giving you money, how can they do that?

Rich: I have a job, so I don't need money. But if they want to follow me on Twitter, it's @Rich_Harris. If they want to follow Svelte, it's @Sveltejs on Twitter, or they can come to our website, Svelte.technology. Oh, we also have a Discord chatroom, which I always encourage people to come and hang out. That's where the Svelte community chills out. It's a pretty nice place. Everyone is welcome.

Dave: Cool. Awesome. Probably can get some answers to questions pretty quick.

Rich: Yep.

Dave: That's great. All right. Well, thank you, again. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris, do you have anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.

Comments

Comments are closed.

Job Mentions

Check out all jobs over on the Job Board. If you'd like to post a job, you can do that here, and have it mentioned on ShopTalk for a small additional charge.