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.