The Changelog: Software Development, Open Source - A UI framework without the framework (Interview)

Episode Date: January 30, 2019

Jerod and Adam talked with Rich Harris –a JavaScript Journalist on The New York Times Investigations team– about his magical disappearing UI framework called Svelte. We compare and contrast Svelte to React, how the framework is embedded in a component, build time vs. run time, scoping CSS to components, and CSS in JavaScript. Rich also shares where Svelte v3 is heading and the details on Sapper, a framework for building extremely high-performance progressive web apps, powered by Svelte.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at rollbar.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by DigitalOcean. DigitalOcean is the simplest cloud platform for developers and teams with products like Droplets, Spaces spaces kubernetes load balancers block storage and pre-built one-click apps you can deploy manage and scale cloud applications faster and more efficiently on digital ocean whether you're running one virtual machine or 10 000 digital ocean makes managing your infrastructure way too easy. Get started for free with a $100 credit. Head to do.co slash changelog.

Again, do.co slash changelog. All right, welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog. We have a jam-packed show for you today. We talk with Rich Harris, a JavaScript journalist on the New York Times investigations team, about his magical disappearing UI framework called Svelte. We compare and contrast Svelte's React, get knee-deep in what it is,

how their framework is embedded in a component, build time versus runtime and the play on that for the browser, scoping CSS to components and CSS in JavaScript. Rich also shares where Svelte 3 is heading and details on Saper, a framework for building extremely high performance progressive web apps powered by Svelte. So Rich, we're here to talk about your magical disappearing UI framework. Before we get to that, let's talk a little bit about your day job. You've been a longtime journalist and you're a graphics editor at the New York Times investigations team. Tell us about that lifestyle and what you're up to at the Times. Yeah, my job title is graphics editor,

which is a slightly nebulous job title, honestly. A lot of the time I am working on graphics. I'm building interactive charts and things like that, things that help explain complex topics in the news. But really, it would probably be more accurate to say that I'm a JavaScript journalist. I work on... Nice. That sounds cool even. I currently work on the investigations team at the New York Times, and I'm part of a unit that uses computational techniques to find out things and report them. That's awesome. Can you give us a for instance, maybe something you've done in the last six

months or a year that's like a, for instance, I built this particular story or graphic. So about a year ago, we did a story called The Follower Factory, which was an investigation into the economy of fake social media accounts. The people that make Twitter bots and the people that buy them. We obtained a list of clients of a company called Davumi. People, many of whom you've heard of, people like Michael Dell, famous actors like John Leguizamo, people like that, who'd bought fake Twitter followers to try and puff up their own online influence. And we used a variety of techniques to track down where these bots were, where they were coming from. And we did a whole big expose on what that economy looks like. So that's a pretty good

example of the kind of work that we do that marries traditional journalistic techniques with the kind of more modern and computational techniques that our team specializes in. And it had some impact, right? After we did that story, Twitter got rid of millions of bots off their platform. There was like a big platform- the purge which got people paying attention that's cool so that was a result of that story and some of that fallout you'll have to give us a link back so listeners can go and check that out and i got one it looks pretty awesome you got it yeah it's uh this is an interesting you know it's kind of scroll driven page that begins with like this kind of montage of grid of like a person's face but sort of broken up like a fragmented mirror pretty interesting so

did you build this whole thing and is the whole thing a kind of like your baby or is it sort of a team effort i'm one of four bylined uh reporters on that piece i did the bulk of the graphics not the opening graphic that you've just described. That was a chap named Adam Ferris who did that for us. But the later graphics where we look at what these bots look like, what their behavior looks like

in aggregate when you start to analyze some of the statistical patterns, all that kind of thing was me together with my editor, Gabe Dance, and colleagues like Jeremy Ashkenes and Danny DeBelius.

Jeremy Ashkenaz is a friend of the show. We've talked to him since way back. Gosh, it's been so long since he actually began as Jeremy Ashinkas, since we did not pronounce his last name, and then we learned it's Ashkenaz. Sadly, no longer of this parish. He left the New York Times back in 2017, but that was the last big project that we worked on. I mean, having seen this page, I can see why you describe yourself

more so as a JavaScript journalist, because this page is definitely a culmination of not only good journalism, investigatively, as well as written, but then how it actually formulates onto a page. And I'm sure that you've got, you know, mobile viewports planned for web. Like it doesn't matter which platform that you're still going to be able to enjoy this content in a similar fashion. It's pretty amazing. Thank you. Yeah, we obsess over making things look good on a mobile device as well as on desktop and all of this stuff.

And it's an interesting challenge trying to take this vast wealth of information and condense it into something that makes a point that a reader who comes to a story without any level of prior knowledge or expertise can actually get something from it. And trying to use technology in a way that makes that more apparent and more impactful.

So technological question on this, which may lead in the spell, maybe not. But when you guys do stories like these, is each individual story, I mean, this feel like a unique experience where this would be like its own separate software application versus, you know, fitting into the larger times CMS or just curious, do you guys start fresh each time? Do you guys have a existing framework that you're shoving stories and code into or is it like little micro services for each little story?

In that example, the story is written into the same content management system that all of our journalists use. The individual graphics are, each one is an individual Svelte application. So it's the, the idea behind Svelte is that you can, you can create a full blown web app, but you can also create little parts of web apps. You can create embeds like, like the examples that you're looking at right now. Very cool. Well, that is about the perfect segue into the main focus of the conversation.

By the way, I have to give a thanks to Kevin McGee, long-time listener, Adam, long-time show idea creator who's still listening, according to Ping, who actually gave us the idea for the show. Now, Svelte did cross my radar a couple years ago. I think I read your initial 2016 post, Frameworks Without the Framework,

and we probably logged it on changelog news, but I didn't see much else between then. And I think it was probably back in June or something of 2018 when Kevin said, Hey, you know, get rich on the show. It should be interesting to talk about this, uh, magical disappearing UI framework. So here we are, uh, Svelte three is upon us. So it's been a couple iterations on the idea. Take us back to the big idea of frameworks without the framework, what Svelte is, and how it differentiates itself from other things

that are out there in the front-end space. Yeah, so imagine that if React and Vue and Elm and Babel and maybe some other projects had a love child, and the love child somehow inherited all of the best qualities. That's what we're aiming for with this project. It's a JavaScript framework. If you've used things like React and Vue

and Angular and Ember, you'll be familiar with the concept. You create a series of components and you connect them together and the framework manages updating the DOM in a way that frees you from having to do element equals document dot query selector, element dot text content equals blah, blah, blah.

All of that declarative style of programming that is the way that people build web applications nowadays. It's designed to do exactly that, but it does it in quite a radically different way from traditional frameworks like React and Vue. What it does is it works on your components at compile time as part of your build step it takes your components and it compiles them into optimal vanilla javascript rather than having a library in the browser that you give your

components to your component becomes the javascript module that executes directly. And the result of that is an application that is smaller, typically much smaller, and is much faster to update. And at the same time, you, the author, because you're writing this very compact component format, you end up writing a lot less code than you typically would with other frameworks. Does that mean that the end product is difficult to kind of peek into as a developer, like view source kind of thing? Does that, I'm sure that maybe a compile time there, vanilla JavaScript, it's probably minifying it,

things like that. Does it make it hard to view port or view source kind of things like that? It's a really good question. And it is a thing that we think about a lot. Obviously, if you're compiling a representation of a component into vanilla JavaScript, there is a slightly larger disconnect between the code that you've written and the code that executes than if, say, it was just a transformation from your JSX, if you're writing React, to the React.createElement calls that that compiles to. However, first of all, we have pretty good source map support

and you can use that for debugging. But also when you look at the compiled output, which we do optimize for readability as well as other things, it's really easy to understand what is actually happening. So the disconnect between what you've written and what you're running

might be slightly larger, but it's paradoxically much easier to understand what's going on. Because rather than looking through 20,000 lines of library code when you're running might be slightly larger, but it's paradoxically much easier to understand what's going on. Because rather than looking through 20,000 lines of library code, when you're trying to understand how a particular state change resulted in a particular DOM update, it's right there in front of you. And you maybe only have to look through a hundred lines. So the experience that a lot of people have had has been that debugging has actually got easier, surprisingly. So the way I'm thinking about this and correct my thoughts if they're wrong here

is that what it kind of is, or it could be boiled down to a framework, like a code generator. So you're writing your JavaScript into this framework, but when you build it, instead of saying, okay, here's my runtime, I'm going to ship that with my code,

it's saying take the code that I wrote and generate new code that's very similar, but also has, I think in one point in the docs you say, the framework is embedded in the component. So it's code generating the component based on the component I wrote, a fancier component that has svelte things in it that provide the functionality that I don't have to write. Is that a good way of thinking about it or am I upstream of it? That's exactly what's happening. You're writing at a high level. You're sort of behaving as the architect, let's say.

And the compiler is acting as the thing that builds the thing that you've designed. So you don't need to worry about wiring up the lights or doing the plumbing or anything. That is taken care of. so you don't need to worry about wiring up the lights or doing the plumbing or anything that is taken care of and your time is spent at a higher level thinking more creatively about the kind of experience that you're trying to deliver so the framework is embedded in the component that was a phrase that spoke to me it made sense but then i thought well what if i have 150 components on this page do i have 150 frameworks embedded into the component seems like it would actually bloat more than shipping a single runtime that gets called into is that not the case it's it's not

the case it is another very good question and a lot of people do hit upon this um straight away they're like how can this possibly make sense when we're building something at the scale of a typical modern web app right i'm i'm actually the author of a module bundler called Rollup. So I've spent a lot of time thinking about this question as well, about how do you deduplicate code efficiently and all the rest of it. And Svelte does have an internal library. When it turns your component into a JavaScript module,

it's not a completely self-contained bit of code. It's actually importing helpers from that internal library, just the ones that it needs, and the rest get tree-shaken away so um all the code that does the heavy lifting is in fact deduplicated and so while you would expect it to scale very poorly it actually scales pretty well there is theoretically an inflection point where if you have more svelte components because the incremental cost of a component is slightly larger than let, because the incremental cost of a component is slightly larger than, let's say, the incremental cost of a React component,

in theory there's an inflection point where the lack of a library is outweighed by the extra size of the components. But in practice, we don't see that. In practice, we see that the inflection point is at a much larger application size than people are typically building. And on top of that, we have code splitting. And code splitting is a technique that people use to deliver small chunks of their app at a time

so that when you first hit a page, you don't have to get all of the JavaScript for every possible thing that you could then do as you move through the application. It just gives you the code that you need for that first page experience, and then the rest is loaded as and when you need it. Now, with a traditional framework, there's a limit, a pretty strict limit, to how effective code splitting can be, because the smallest chunk of your application still needs the entire library, all of your state management, all of your router, all of this other stuff. And Svelte doesn't have that problem. So while in theory, there is this problem with scalability, in practice, it's

actually better than traditional frameworks. Have you done any of the math on where that inflection point is? Could you say, well, you need to have an application with 6,500 components or a million components? Like what's the, even the order of magnitude where people might say, oh, the trade-off isn't worth it anymore. I haven't done the napkin math on that, no. Okay. The reason being that, I mean, there's really no point.

It's just an intellectual exercise that doesn't actually bear any relation to how we're building applications. There is a project called the Real World Project by Go thinkster you can find that on github and the point of this project is to actually do this comparison allow you to do this comparison between different frameworks so that you can get a sense of what it feels like to implement something slightly less trivial than the traditional to do mvc or hack and use. And there is a Svelte implementation of the real-world project, and not only is it about half the size

of the reference React slash Redux implementation, but it's actually about half the number of lines of code as well. So your initial payload is much smaller, your total application size is much smaller, and the number of lines of code that you had to write is much smaller. So one of the things you wrote, I think it was the subtitle to that post back in 2016, which we will include in the show notes, is why didn't we think of this sooner? Yeah.

And here we are in 2019 and React is dominating the front end framework space. You have Vue, which is very popular and gaining steam, but really it's kind of a two-dog race, it seems like, in terms of just mass adoption. Angular has had the head of steam, but it's kind of fallen into third place in that regard. And Ember, of course, always there, always just plodding along relentlessly, which we love. But Svelte seems like, this model,

seems like it's markedly better in terms of end user experience because you're not shipping as much javascript and of course the the raw kilobytes of the size of your js bundle isn't the end of the story because you also have to parse and evaluate that code inside the the device which is slower on slower devices, especially phones. So it's not like saying, you know, a bunch of big images versus a bunch of big drivers. Point being is like, this seems like a pretty big advantage. Why didn't we think of this sooner?

And then why hasn't anybody else adopted it? Or maybe they have, and I'm not paying close enough attention. Well, actually they have. Svelte probably wasn't the first library to do this anyway. We've always had, you know, we've had things like Elm, which is kind of a version of this idea, you could argue. Before there was Svelte, there was a project that I wasn't aware of at the time called Monkberry, which was doing something vaguely similar. There is a project called Marco from eBay, which again is doing something not a million miles away from what Svelte is doing. And then we have Angular's AOT compilation, ahead-of-time compilation, which they're baking into their new renderer called Ivy.

Ember's new rendering engine is a thing called Glimmer, which takes your handlebars components and compiles them to a very efficient bytecode format. So pretty much every framework is adopting this model. And Svelte, I think, is probably the purest expression of the idea in that it compiles your components to vanilla JavaScript and you don't need any other library code once you've imported the component. But it's far from the only framework that is,

that is cottoned on to the fact that if you can move work out of the browser and into your build step, you're providing a better experience to users and in most cases to developers as well. I can imagine too

that being from the New York Times that you think about not only, you know, think about not only you know download time for you know or performance page speed things like that but you also think about battery life and things that you know generally users shy away from i mean it your newspaper so generally you have ads on your pages in most cases so you've got to have that as a concern so after you load ads javascript all that good stuff with that you've got to have that as a concern. So after you load ads, JavaScript, all that good stuff with that, you've got to now deliver your application.

And the easier you can make that on your users probably is pretty important. So was this project born out of the New York Times? And we're just now hearing about that part? It wasn't born out of the New York Times. It was actually something that I created while I was working at the Guardian US, just before I came to the New York Times. But it is absolutely born out of the problem that people doing this job have, which is that we're putting code, which is often very heavily interactive, lots of animations, all that kind of thing, pretty performance intensive. We're putting it onto pages that we don't control, right?

Because very often we're doing embeds that sit in someone else's article. And on that article, as you say, we've got ads, we've got analytics, we've got comment widgets, we've got all of this stuff. And our code is the last thing that gets loaded. So it's sort of this hostile environment that we're working in. And we're working with these extraordinary constraints. We're often working on really punishing deadlines. And when I started Svelte, I did so because the existing tools, frankly, didn't allow me to do the job that I wanted to do as well as I wanted to do it.

When you say people in your job, how often do you encounter other JavaScript journalists? Like, is this a seriously big type of role at all these newspapers and all these different news outlets? Or is this like, this is the first time I've heard that title. And I'm imagining there's lots of you out there, but did they all play at the same level or have the similar skills that you do?

It's a very broad church. There's definitely a lot of people who would qualify for that label. A lot of them are here at the New York Times. New York Times invested very heavily in building out the graphics department. Way back when a lot of other publishers were still trying to figure out what their digital strategy was, the New York Times was laying the groundwork for, I'm not boasting here, the best graphics department in the world. It's had a ton of really influential JavaScript programmers

come through the graphics department, folks like Mike Bostock, Gregor Eich, Jeremy Ashkeneth. But at the same time, we've got a lot of people who don't have a background in hardcore programming. We've got people who have backgrounds in straight reporting and design and they've learned javascript because they want to be able to tell stories that are richer and more interactive and that is the way to do it other news organizations definitely have other people doing very similar work um i'd struggle to give you an estimate of the number, but there's certainly in the US, there think, with regard to storytelling and providing, you know, valuable information for people. But that being said, it would be cool to be like JavaScript journalist and really work at the intersection of all those different skill sets, right? Journalism, data science, design, programming.

I always tell people that it's the best place to be a software engineer. You know, you're surrounded by so many people with overlapping but different interests, which means it's a great place to learn. You're doing work that is, it's important. It's important for our civic life. You're doing work,

and this is my favorite part of it probably. You can spend four weeks working on a project rack up as much technical debt as you can manage and then you can just light a match at the end of it and walk away I was just going to say that because you don't have to maintain a product for months after you've launched it

as soon as you hit publish that's it I was just revelating that thought I'm glad that you said that because I was thinking wow like you have to care about these things that matter, right? But you don't have to care about the things that don't matter, which to most of us, the things that matter is maintainability and for software to be malleable to change over time because software that doesn't

provide value over time is invaluable. We want to write valuable software, but for this, for your style, it really is kind of a one and done, which means you have lots of green fields as well. Like you get to start over a lot, which many of us don't get to. It means that we get to experiment with a lot of different ideas and technologies. And so I think it's one of the reasons that it's a pretty fast moving, fast evolving arena for JavaScript to come out of. This episode is brought to you by Git Prime. Git Prime helps software teams accelerate their velocity and release products faster by turning historical Git data into easy to understand insights and reports. Because past performance predicts future performance, Git Prime can examine your Git data to identify

bottlenecks, compare sprints and releases over time, and enable data-driven discussions about engineering and product development. Shift faster because you know more, not because you're rushing. Get started at gitprime.com slash changelog. That's G-I-T-P-R-I-M-E dot com slash changelog. Again, getprime.com slash changelog. so rich help us understand the evolution of spelt over time you have version three which is imminently being released depending on when you're listening to this listener it may be out there it may not you know software developers and timelines we hate them but uh it's right around the corner

or it's out there one of the two um so spelt two was last year i'm gonna put my money on it's right around the corner or it's out there one of the two um so svelte 2 was last year april 2018 i'm gonna put my money on it's oh it's just around the corner okay i thought you were gonna put a stake in the ground for a second there and say it's out there but no you played it smart played it smart coming soon as as all good software is so you know things change over time svelte came out in 2016 as we said that's three years later you have a version 2 you have a version 3 so tell us about the way it's changed. Has it been philosophical changes, just implementation? Help us understand where it's gone and then where it's going to be today,

or I guess in the near future. I guess if we want to talk about the origin of Svelte, we have to go back to 2012, which is when I started working on Svelte's predecessor, which is a library called Ractive as in short for interactive also a word from a Neil Stevenson novel. Ractive was a view framework

that was based around templates it was based around the idea that if you had some data that existed as a plain old JavaScript object and you had a template which resembled Mustache, and you could combine the two together, then you could generate a really highly performing application by tracking which parts of your data were changing over time. This is something that I think was probably pioneered

with Knockout back in the day, but I wanted a different developerered with Knockout back in the day but I wanted a different developer experience than Knockout could provide and I noticed that a lot of the things that we were building all we were doing really was trying to make the page match some some templated HTML but the way that we were doing that was by inner HTMLing parts of the page which is kind of gross and inefficient so i built this library that would allow me to create a slash template that would be kind of self-updating in the most efficient way possible and that's something that i started when i was working at the guardian in the uk back in 2012 and it powered a lot of our interactives back at

that point and it was it was reasonably successful. It was my first big open-source project. It ended up getting used in a bunch of places. It was used inside Amazon, inside a Wall Street bank. It was used by the NFL, Delta Airlines, Playboy TV at one point, apparently. And in spite of that, it never really hit the mainstream um but i like to think that some of the ideas kind of stuck um view came along shortly after active was launched and sort of took all the best ideas and jettisoned the bad ideas and became very

successful and i was pretty pleased with it. It was better performing than React in most of the tests that I could throw at it. And it was really easy to use and it had this really delightful community around it. But over time, as more of our work shifted to mobile, I became increasingly aware of the bundle size concern. People are always telling us that we need to make smaller JavaScript bundles

because the initial load experience is so important. And if you've got a bunch of JavaScript that has to get parsed and evaluated when the page first loads, it provides this really bad experience. And so I started thinking that there must be a way that I can deliver these applications without also having to deliver a library that knows nothing about the application right because a library like Ractive or React or Vue it has to be able to accommodate an infinite set of possible states of your application but there isn't an infinite set of possible states of your application. But there isn't an infinite set of possible states.

There's a set of states that can be known ahead of time. And if we could find out what they were, then we could deliver optimized JavaScript for them. And so I started to think about what a solution to that problem might look like. Around that time, I had a conversation at a JavaScript meetup in New York with a guy named Jed Schmidt,

who's a really smart programmer, and he'd been thinking about this problem too. And he started talking about compilers, whatever a compiler could look at your code and write the application for you. And this idea kind of bounced around in my head for a little while. And then I thought, I think I know how we can do this. We can take our existing reactive components

and we can put them through a special purpose compiler. I know what code it needs to generate. And so I spent a furious week coding, did a first version of that, and it worked. The performance was unbelievable. The size of the applications that it was generating were unbelievable. So we started using it at The Guardian for some of our projects, open sourced it, and it turned out that the idea resonated with a lot of people.

And it kind of went from there. But the initial design was very heavily influenced by Ractive because I wanted to be able to have a development experience that I was familiar with. And in retrospect have a development experience that I was familiar with. And in retrospect, that development experience had a lot of flaws. There were a lot of mistakes made in the original design of Ractive, and it was getting a little bit difficult to move away from those mistakes.

So Svelte 3 is, in essence essence a complete reboot of the idea it's a little bit inspired by the work the react team have been doing with hooks it's very focused on developer ergonomics but it also has a bunch of new features and a new approach to updating the DOM which will result in even better performance in a lot of situations. New to Svelte or new to the space in general? New to Svelte. The big difference between updates, DOM updates in Svelte 2 and Svelte 3 is that they're no longer synchronous.

We've embraced this new concept of reactivity in our applications. It used to be that the reactivity lived in the component API. You would do component.set and then you would provide a new data. And that behaved similarly to a React set state or something like that, except that it was completely synchronous. And that was good enough for most situations because you could pass in all of your data in one go and it would update everything very efficiently. But there were some situations

where that could cause layout thrashing and so on and so forth. And so we've moved away to an asynchronous batched update model. But what's more interesting is that the reactivity has moved out of the component API and into the language itself. And this is the big thing that we're going to be talking about with Svelte 3, is rethinking how we approach the problem of reactivity.

So when you say into the language itself, are you referring to extensions to JavaScript or just functions inside of the Svelte component API? Tell me what you mean by that. So imagine that you have a counter component often used as a demo for these sorts of things. You've got a button, and when you click the button, it calls an event handler, and the event handler changes the count part of your internal state. There's a few ways that you can do that.

In React, classic React, you might do component.setState. In React with hooks, you would have a state update function that was specific to the count property, and you would call that. In Vue, you might do this.count plus equals one. And in Svelte 2, you would do this.set count count plus one. In Svelte 2, you do this.set count count plus one.

In Svelte 3, all you need to do is count plus equals one. And the compiler sees that you've made an assignment to a value that the template is bound to, and it will add a piece of code that invalidates that. It will tell the component, this piece of state has now changed and we need to update the component. But what it does is it keeps track of which parts of the component this piece of state has now changed and we need to update the component but what it does is it keeps track of which parts of the component have changed so it doesn't re-render the entire thing and then put you through this fairly wasteful diffing process all it does is update the parts of the component that are affected by the state that has changed where i get confused starting to think about svelte now is like and what is that build time and what is that runtime?

So this is all accomplished at build time? As much as we can do at build time, we do at build time. Surely it can't, yeah, like the events can't fire at build time. Oh, my click handler keeps firing when I build my project. You know, a podcast is fundamentally the wrong medium to discuss this, because I really need to show you some code. Once people see the code,

they see the input and they see the output, it becomes very obvious how this works. There's no magic involved. It's not doing anything weird. It's doing very predictable and very obvious things, but it just frees you up from having to think about state management as something that you need to spend time doing. And it injects code that, it's more code instrumentation than code transformation. It instruments the code in such a way that you don't need to think about telling the browser

that a value has changed beyond just changing the value so it injects instrumentation code that watch is watching for value changes then and you just go ahead and change the value and you didn't have to actually wire any of that up or am i you don't have to wire it up the compiler wires it up for you okay um so if you do count plus equals one for example the next statement gets injected by the compiler and it calls a framework provided function called invalidate invalidate knows which property has been invalidated it knows what the new property is and so through that mechanism it's able to keep track of which parts of your state are clean and which which are dirty And if an update isn't yet pending, it will schedule an update for the next micro task. And then it will go through

and just surgically update all the little parts of the page that are affected by the change in state. Very cool. So has this yielded excellent runtime results then of page of DOM updates versus Svelte 2? I don't put a lot of stock in in benchmarks um personally that i i find that they're they're very rarely measuring the things that actually matter in an application um it does perform extremely well on benchmarks you know i need to just allay any doubt Svelte is extraordinarily fast.

Well, the question is you have to ask yourself, if you didn't have benchmarks, I agree, especially synthetic benchmarks are sometimes problematic. They can be misleading. Sometimes they're helpful. It's just a mixed bag. But the question is if all of this reworking of how this rendering happens is for performance sake because of the thrashing that was happening before,

and maybe there's features as well, but how else would you know that it's working? All your efforts for rewiring this entire thing to be reactive versus the way it currently is, if you don't have any sort of benchmarks versus the other, then it's kind of just going on a feeling, unless there are also features that you're yielding from this work?

There are features. I mean, the primary motivator for that change is the developer experience. It's really nice to write Svelte three components. You're incredibly productive. You need to write much less code than you do with other frameworks. And that's the selling point. Yeah.

Yeah. When it comes to performance, you know, a lot of it, I think we just need to rely a little bit more on common sense than on benchmarks. It stands to reason that if your update process consists of re-rendering your application

and then comparing the previous virtual DOM with the next virtual DOM and then finding out what's changed and then applying those changes in this kind of long-winded indirect process, obviously that's going to be slower than if you've got code that just directly updates the dom for you i would tend to agree assuming that the code works as desired right so one reason i at least have those benchmarks in place would be to see if you're doing doing it right and catch it catch it

not working the way that you just we have a We have thousands of tests in our test suite. So that's a pretty substantial change. Anything else not to belittle that change but anything else in Svelte 3 that's dramatically different than what you've produced so far like that? We have a new approach to cross-component state management which

is a lot more flexible. It's again a little bit hard to describe in the context of a podcast, but it moves away from having a single central global state atom and into having values that can be passed around in different components and composed in various ways. It's very flexible.

It allows for some really cool things like springing animations and all that sort of thing without a lot of developer effort. It's better at composition. We have some new composition primitives that just went in over the weekend, which will make it easy to build more complex compound components than has been possible before. There's probably a bunch of things that I'm just kind of blanking on at the moment,

but it's a huge release, and the changelog for this thing is going to be an absolute monster to write. We should make people drink when they see something like that, Jared. We should. Every time someone says the changelog, on the changelog. That's right. You win a free t-shirt. Little Inception, take a drink, get a t-shirt.

There you go. Where does something like CSS come into play? I know that one thing that you've talked about is just the importance of scoping CSS. There you go. Where does something like CSS come into play? I know that one thing that you've talked about is just the importance of scoping CSS. There's a lot of issues with that, like leakage. Is that a bigger picture of what you just mentioned in Svelte 3, or is there something you can cover kind of here in Svelte 2? No web application is complete without styles.

Right. CSS is a core part of any web app that you build. And yet some of our JavaScript frameworks don't include any primitives for styling. I think that a JavaScript framework that doesn't have styling built into it is incomplete. And Svelte has had that philosophy baked in from the start.

Because you write your components into an HTML file, you can just add a style tag and you can put your CSS in that style tag. And the compiler will compare your styles with your markup. It will see which classes are being used, which ones aren't being used. It'll dead code eliminate your unused styles. It will transform your class names so that they are scoped to that component so that you don't have style leakage throughout your application it does all of that stuff you can also use your favorite css in js library if you want to you can use plain old dot css files but svelte has pretty good css handling baked into its core it's not

perfect there are some things that we want to tackle after the version 3 launch, particularly around composing styles from different sources. But CSS, if you're familiar with CSS, if you're good at CSS, then you'll enjoy building applications as Svelte components because it's not an afterthought. It's not something that has been left to an ecosystem of third-party libraries.

It's baked into what the framework is all about. Sounds like you might have some pretty decent opinions about this great divide Chris Clear just actually talked about, which since I said that you may already have read the article. What are your thoughts on that? I skim-read it because everyone in my feed was going mad about it. I'm not going to offer any opinions because I will probably be basing those opinions

on other people's misinterpretations of what Chris was saying. Well, it was a long post, so easy to misinterpret. The more words you put in, the more things can be misread. And I know I definitely also skimmed it, didn't read it in detail because of the length and happened to be short on time. The part that I read, it seemed perfectly reasonable.

It seemed like it was identifying a thing that indisputably exists in the industry. People seem to be interpreting it as, let's encourage this great divide. Let's deepen it. And I'm not sure that's what i read into it but i'm less interested about the politics of it and more interested the practicality of it meaning that so well meaning that he just said you know no javascript framework is complete without you know the necessary for css so right with so many that don't just based on that bias alone means that there is in fact a divide and that his, his stance on the divide,

whether he says so or not in response to my question is just simply that he cares. So he thinks that it should be, I have a place that when you say here, you talk about Chris, you talk about rich, rich, rich.

Okay. Sorry. My, in all those cases, it was Rich, not quoting Chris at all. Because I'm the same. My skin is just like you guys did. And I sort of just saw this divide that I'm aware of, but based on what you just said with how you clearly think about styles in a JavaScript framework makes me think that, you know, you want to find common ground. I do. You know, I was, I was saying earlier that one of the great things about, um, the, the work that I do here is that I'm surrounded by people with different, but

overlapping interests. And, and that is, that is when things really start to sing is when you have people who, um, who can share knowledge and expertise across disciplines, but all be speaking the same common language and working towards the same common goals. And when we put ourselves in silos, when you think of yourself as a JavaScript developer or a CSS developer, then it becomes harder to do that. And so I'm all about ways of working that allow people who have expertise in one discipline to work right next to people who have expertise in another discipline and not enforcing arbitrary divisions between them. Yeah. Well, pulling somebody away from vanilla CSS or making somebody who's very familiar with that work in other areas

is a necessary learning curve for progress, but it sounds like you question, does it have to be that way? Yeah, I don't think it does need to be that way. If you're the team CSS expert, then don't go and sit in the corner and write CSS by yourself. Write the CSS in the context of the component that you're working on, and you will start to understand at a much deeper level how all of the different parts of the application fit together. And that will give you insights that pay dividends beyond,

I'm not articulating this very clearly, but you understand what I'm getting at. I think that the more holistic a view of a project each member of the team can have, the better the end result is every single time. I 100% agree. And that means breaking down the barriers. Well, now we kind of have a basis of your point of view. Can you talk about scoping and components as it relates to, say, styles and having no overlap or no leakage, as you say, in the blog post about it? Yeah, so the big problems that people have identified with CSS

and the reason that CSS in JS has become a thing, there's a couple of main problems. First of all, CSS is global, right? If you add a style sheet to a page, then you will affect everything on that page that happens to have the same classes. And so because of that, we've come up with these incredibly baroque naming conventions that are designed to prevent your styles from one component affecting the styles for another component. Things like BEM, that kind of practice. And the trouble with these is they make your style sheets incredibly wordy

and they don't actually prevent conflicts. It's just a convention. It's not enforced by anything that can actually stop styles from conflicting. If you want to do that, a computer needs to do it for you and it needs to happen as part of your build process. The other side to do that, a computer needs to do it for you. And it needs to happen as part of your build process. The other side of it is that a lot of people have experienced the phenomenon of the append only style sheet. It becomes really

difficult to delete a piece of CSS because you're never entirely sure what part of the application depends on it. And so what tends to happen is if you need to counteract the effects of a class that is stopping your element from looking the way that it needs to, you will just add another CSS rule. And people keep doing that, going back and forth. Eventually you get into the important wars

where you're just increasing the specificity of the selector, adding important to rules so that your styles are the ones that apply and not the previous styles which are quite possibly unused in your application. And so in that way, style sheets get bigger and bigger and bigger until your entire CSS is just an unmaintainable mess. Now Svelte basically solves both of those problems. It solves the first problem by scoping your css so that if you have

class equals foo on an element in your component and you have a dot foo style rule it will add another scoping class that's unique to that component and it's computer generated so it can't possibly conflict with anything else on the page. And that will ensure that your foo styles don't affect anything else on the page, even if you have another element with the same class name in a different component. It solves the other problem by analyzing your CSS in the context of your components markup and determining which classes are definitely not being used. And I say classes to mean all CSS selectors. It can look at all of your CSS rules and say, well, this active class, that's not being used anywhere. There's no element that at any point

could have that active class. So we can just remove that and not even emit it when we generate our style sheets. And it'll issue a warning. It'll tell you so that you can then remove the class yourself so you don't have it cluttering up your code base. But between those two things, you end up with these very compact style sheets because you're not using these these incredibly long naming conventions and you don't have styles that aren't being used in your application

and so it's it's good for the developer it's a nice developer experience but it's also good for the user because you're not shipping all this unnecessary CSS. At this point, I feel like just saying, shut up and take my money. Because that's awesome. What's interesting too is that a lot of this began with, say, particularly around CSS with preprocessors like SAS and others, kind of helping us know that CSS itself is not dynamic while SAS is. Yeah.

And doing a lot of this pre-processing, now it's graduated from, say, just a particular sliver of the overall thing you ship, which is HTML, CSS, and JavaScript to the browser to, you know, you're graduating it up to the framework level and doing it at compile time versus in just one area. And, you know, because SAS wouldn't solve these problems, right? It requires the kind of thought process you put into this vote because it needs to be at that level, not down at the just CSS only level. Fundamentally, the only way it works is if the styles are analyzed in the context of the markup.

Yeah. If you're not aware of, if the markup isn't aware of the styles and the styles aren't aware of the markup, then there's a limit to what you can achieve. And this idea of being able to statically analyze your application at build time is kind of the thing that everything in Svelte springs from. This episode is brought to you by our friends at Rollbar.

Check them out at rollbar.com slash changelog. Move fast and fix things like we do here at changelog. Catch your errors before you use this do with Rollbar. If you're not using Rollbar yet or you haven't tried it yet, they have a special offer for you. Go robot I comp slash changelog sign up and integrate roll bar to get $100 to donate to open source projects via open so rich you've talked a lot about developer experience as well as user experience but you said version 3 really is keying in on making the developer experience better. We haven't talked too much about what it actually looks like to use Svelte or to participate

with Svelte or whatever you call it. Use the framework. I assume it's a command line tool or there's some sort of build tool. A lot of us have current workflows. Does it integrate into web packs and other things? Tell us about how it integrates with other tools and how you use it to get started. At its heart, Svelte is just a compiler

that takes an HTML file in, or rather the contents of your HTML file, and spits out a JavaScript module at the other end and some CSS if your component has styles. That's quite low level. You wouldn't typically use the compiler directly. You would typically use it via an integration for Webpack or Rollup or Parcel or whatever your preferred build setup is.

Svelte has a plugin that will work for it. So the way that you use it is inside your application source directory. In the same way that you write JavaScript modules, utils.js, you would write these HTML components, app.html. Some people prefer to do app.svelte. It's really up to you.

And then you just import that. You import from that file, import app from.slash app.html. And then that is a component, a standalone component that has the Svelte API, const app equals new app. Same way that you would use a lot of other constructors. It's just a regular JavaScript class at that point. If people want to get started with Svelte more easily than having to rig rig up a whole build setup we do have some really easy to use starter templates and if you go to the website svelte. technology you can go into our repl start playing around with that and just click the download

button and you will have a project fully set up and ready to go with all of the optimizations and all of the bells and whistles very cool cool. You also have a companion project that looks to be higher level even than Svelte, which is called Sapper, the tagline military-grade progressive web apps. Which we're going to change. We're going to change, because some people don't like that tagline.

Is that right? Yeah, it was supposed to be a little bit tongue-in-cheek, because a lot of these frameworks have fairly kind of in my view slightly insipid and an unmemorable strap lines and we wanted to get something that was a little bit more evocative but some people really hate the military and so we're gonna change that because some some people have literally said I'm not going to use this framework because of that tagline so we're gonna change it but yes this is a higher level framework that sits around Svelte. If you think of Svelte as a component framework,

Sapper is the app framework that uses Svelte. Have either of you used Next.js? Heard great things, but I haven't personally used it. Yeah, same here. Okay, so Next is this amazing thing. The idea behind next is that you can have each page of your application is a react component and you put all of these react components inside a pages folder and next we'll turn that into a server rendered application so if you go to a page you get html and then at the end of it it will will load the client-side version of that application and seamlessly switch you into this modern native app-like

client-side navigation style app. Very sophisticated. It does all of the code splitting stuff out of the box, and it's just this really beautiful developer experience. And I wanted to have the same thing for Svelte, and Sapper is that thing. So is Sapper going to be updated alongside Svelte 3

is that a thing that people should hop in on right now, should they wait for Svelte 3 what's the situation with Sapper is it going to get broken or upgraded or is it safe to just use it right now and it'll be seamless I hate to say this but I would tell people to wait

I've been telling people to wait actually from diving into svelte full stop until svelte 3 comes out because there are going to be breaking changes um and people are building apps with svelte 3 right now in its pre-release state and we're getting loads of really helpful feedback from that from the community um but it's it's not bulletproof at this point so there's this unfortunate limbo that that happens when your previous version is not gonna survive that much longer but your new version isn't quite ready yet and so i'm sort of telling people just just wait a couple of weeks and then the and then we'll be ready for you come and dive in what else in terms

of community projects is Are there plugins? Are there extensions? Are there people building components that you can use with Svelte? Or are there other people working on Svelte proper? Tell us about the landscape of people participating with the project. We have a really nice community.

It's one of my favorite parts of working on Svelte. It's just a really nice group of people um we hang out on discord uh there's always people in there we've got people from all around the world um just comparing notes and uh and talking about the library talking about the apps that they're using, talking about ideas for the project's future development. It's not just me working on the project. I think we ran the numbers recently. There's something like 75 contributors to the project since it's been going. Obviously, some of those are people who've just done a drive-by pull request here and there.

It's a long tail, but there's a pretty active group of people working on it and the community itself is very active putting out components, putting out pre-processes that would enable you to use things like Sass and Less inside your components.

All that sort of thing. There's a lot of stuff going on. Since maybe Jared and I are hearing about this for somewhat the first time. Jared, you mentioned you heard about this a while back but hadn't really gotten into it i'm curious why why it seems like if if maybe i'm just an outsider and i'm i'm not aware like the visibility is felt to the greater community you know obviously it's growing but can you speak to maybe the sort of the underground movement with it it It seems like it's more underground and sort of ready to explode rather than have exploded in, you know, at kind of a react level, for example. Absolutely. People talk about it like a well-kept secret. I've, so this,

this isn't my first big open source project. I've been involved in a few different ones now. And the thing that I've learned is that it takes so much longer than you would imagine to gain the level of traction that you're talking about. People still talk about Vue as like the new shiny thing. It's been around since like 2013. It's six years old. There's nothing new and shiny about a lot of the projects that are only now reaching people's awareness. So Svelte is very much under the radar

for the vast majority of JavaScript programmers. People are starting to cut on to it. There was the state of JavaScript 2018 survey at the end of last year. And Svelte was the, for the front end framework section, it was the number one write-in answer to the question which framework are you using um it was ahead of you know aurelia and other frameworks like that um so it's slowly gaining traction um a little bit of anecdata i've noticed a sudden uptick in invitations to speak at conferences and things like that so i think people are kind of aware that this is a thing, but a lot of people are hesitant to dip their toes into a new technology stack because there is a very high switching cost. And so I guess our task over the coming months

is to try and persuade people that the cost of not switching is ultimately higher in the long term than the cost of um i confuse myself i was switching yeah not switching versus switching our task over the next few months or so is to try and convince people that the cost of um of not switching to a newer and more future-proof technology is uh higher than the cost of staying put. Sometimes you can't change until the pain that changes is so great that you are forced to change.

That's a terrible place to be in. It's nice to be maybe an earlier adopter in those regards, but sometimes the pain gets so great that you're like, I can't take this anymore. My foot hurts. I need a doctor. You certainly don't want to be in that position. No.

Nor do you want to be in a position of adopting something that isn't yet ready. And so I totally empathize with people who have been using Svelte 2 and they're going to have to do some work to upgrade to Svelte 3. And that's something that I regret because I'm one of those people. You're causing yourself pain here. So one of the things with adoption that

we've seen, Vue had great success with this. Even Elm had success when they blogged about the fact that you can dip your toe into the water with Elm. Evan wrote a great post about how, you know, Elm seems like the kind of thing that's all in, which a lot of frameworks historically have been. Ember is the kind of thing, maybe not anymore, but historically it was like, you've got to use it all and you've got to start with it, or you've got to switch to

something else. Is Svelte the kind of technology where you can say, hey, I'm just going to write my nav bar as a Svelte component and not use it anywhere else on my site, or do I need to dive into it a Svelte component and not use it anywhere else on my site or do I need to dive into it? Svelte is the perfect example. It's like the platonic ideal of a framework that you can adopt incrementally. And the reason for that is that it doesn't have this bulky library that goes along with it. You can't have an Angular app and say, oh, you know what? I'm going to

incrementally adopt Ember it just doesn't really work because then you've got two frameworks on the page at once which means that you've got all of that extra javascript that needs to be evaluated and passed whereas with svelte your minimum component size is it's like something like a you know a kilobyte or two so you can really easily dip your toes in and on on top of that, you can compile to the vanilla JavaScript class, or you can compile to a web component. So if you're in an environment where web components are supported, then you can use Svelte components that way. You get the nice authoring experience, but you also get the cross-platform,

cross-framework compatibility that web components are designed to have that's excellent i would definitely put that up front and center on your guides and marketing materials because that helps people you know bridge the gap right when the gap is much smaller than they think it is oh i can just dip my toe in i can just try this and if i't like it, it's not going to cost me very much. It's not like I have to completely abandon my current workflows or my current application to give it a try. I'm definitely going to think about that advice

because, honestly, marketing is not our strong point. That's kind of where I was getting at, too, is with that sort of direction we're taking the last few minutes is, you know, if it's not well-known, how do you make it more well-known? And, Jared, your point of dipping your toe in is a great example of how to begin to inch towards that execution because the easier you can give somebody an on-ramp to either contribute in open source, that's great too, or also be able to try or adopt. Like adoption is, you know, one of the hardest things of open source is how do you get market

share how do you get somebody to try it and the easiest way is like make it simple how you make it simple well just like jared said rebuild your navbar and use it just in that case and see how it works out for you and your team i'd actually write a blog post around that and make it a challenge you know like i challenge you to try it and see if this new way as you just said before like talking about the pain to change you know make it a challenge to to

to try one small thing in your application to initiate change yeah we should do that the Svelte challenge the Svelte challenge the other good way to market is to have a bunch of

synthetic benchmarks that all make yours look the best you know there's there are some benchmarks out there that we've taken path in. There was one recently that showed that Svelte was 35 times faster than React

and 50 times faster than Vue. And I'm just not a fan of using numbers like that in marketing materials because it's contextless. It is. And it doesn't help someone decide whether it's suitable for their application or not. No, but it sure, sure makes headlines. That's, that's the thing.

So yeah, that's the problem with, uh, I don't know if you call it integrity, but I'll just call it integrity is, is that when you, if you have integrity in the sense of, you know, there's an advantageous approach, but it violates a personal moral ethic, then you bypass certain opportunities that would otherwise arise, right? I think the other thing that I've realized lately is that people value developer experience more than they value that stuff anyway. I think so.

Yeah, people actually don't very often really do a deep exploration of the tools that they're using. Something that I've seen time and time again, people will opt for a really nice, easy developer experience, even if it comes at the expense of user experience, ultimately. And they'll come up with various kind of rhetorical justifications for, oh, you know, if the developer experience is better, then I can spend more time focusing on user experience, which is just so logically fallacious.

But people will buy into it because ultimately we want the thing that makes our job the easiest. And so that's why Svelte 3 is so heavily focused on improving the developer ergonomics, undoing some of the original design mistakes that we inherited from Reactive, and trying to do something that will appeal to people in, for example, the React community, who've looked at frameworks like Svelte and said, templates, I don't want to deal with templates and other specious justifications. I think that if people really give it an honest go, they'll really enjoy the experience of writing applications in this way. Well, I'll go on record to say when Svelte 3 comes out, let us know

and I will take the Svelte challenge. I will write a little bit of change.com with Svelte 3 and let everybody know and I will take the Svelte challenge. I will write a little bit of change.com with Svelte 3 and let everybody know what I think. Let's talk about the future then. I mean, the future seems bright. There's probably something on the horizon that maybe people don't know about. What's in the future for Svelte and maybe Sapper as well?

What's coming up? So more of the same, first of all, just trying to make the quality of the generated code as high as possible and as small as possible we want to make SAPR

the best development experience for an application that you could possibly have we want to take the best features from other frameworks like we want to do

something that's similar to React Suspense which is a nice way of allowing asynchronous data to not interrupt the flow of navigation around an app that's um something that we think is possible with the svelte 3 architecture and something that we'll probably do in the next few months um beyond that something that i've been thinking a lot about and something that I would really love to do is take the ideas from Svelte,

this idea of constructing what is essentially a graph of your application at a moment in time and then turning it into DOM manipulation code. I would like to do that, but turn it into WebGL code. I think it's possible to apply the same ideas and generate a WebGL code. I think it's possible to apply the same ideas and generate a WebGL application that is built around a scene graph and a camera and lights and materials and all of that sort of thing, but doesn't have all of the library code that you typically associate with WebGL apps.

You know how when you go to see a cool WebGL thing, there's often a loading screen. It takes like a minute or two before the progress bar finishes and you can actually experience the thing. I think we can do better than that. And I really want to explore that space once Svelte 3 and everything else that accompanies Svelte 3, including the documentation, which is going to take me forever, is out of the way. When it comes to kind of following along, I noticed that the blog is a bit dated in terms of like announcing Svelte 2. So what's the, aside from that, is it like Discord? Where are good places for people to keep up? Or obviously they listen to this podcast, they're probably tracking ChangeLog News and our newsletter, but what are other good sources for just keeping up with,

you know, latest, greatest bleeding edge stuff? Uh, you're right about the blog. It's not been historically something that we've been very good at keeping up to date. We do have a bunch of blog posts that are going to be released along with Svelte 3, but if people want to stay up to date with everything that we're doing, they should follow us on Twitter, uh, twitter.com slash SvelteJS, and they should come and hang out in our Discord chat room. There's a link to that on the website, which is Svelte.technology. Cool. We'll link it up in the show notes for sure.

Rich, thank you so much for taking the time to kind of do this deep dive with us. I know that you're busy and you've got lots of stuff to do. I mean, JavaScript journalist, I mean, that's the coolest title ever. But we really appreciate the time you spent with us today. Thank you. My pleasure. Thank you for having me. All right. That's it. Thank you for tuning into this episode of the change log. If you enjoyed this show, do us a favor, go into iTunes or Apple podcasts and leave us a rating or review, go into Overcast and favorite it. We to it share with a friend and of course want

to thank our sponsors digital ocean get prime and rollbar also thanks to fastly our bandwidth partner head to fastly.com to learn more we're able to move fast and fix things around here at changelog because of rollbar check them out at rollbar.com and we're hosted on linode cloud servers linode.com slash changelog. Check them out. Support this show. This show is hosted by myself, Adam Stachowiak, and Jared Santo. The edit, mix, and master was done by Tim Smith. And the music is done by the one and only Breakmaster Cylinder.

If you want to hear more shows like this, subscribe to our master feed at changelog.com slash master. Or go into your podcast app and search for changelog master. You'll find it. Subscribe. Get all of our shows in one single feed, as well as some extras that only hit the master feed. Thanks again for tuning in. We'll see you soon. I'm Tim Smith, and my show Away From Keyboard explores the human side of creative work.

You'll hear stories sometimes deeply personal about the triumphs and struggles of doing what you love. Jumping off into the abyss is kind of my skill. And so I'm not saying that it's not scary. I'm saying that perhaps my skill is just not being able to estimate how scary it will be. New episodes premiere every other Wednesday. Find the show at changelog.com slash AFK or wherever you listen to podcasts.