Svelte and the Future of Front-end Development

First released in 2016, the Svelte Web framework has steadily gained popularity as an alternative approach to building Web applications, one that prides itself on being more intuitive (and less verbose) than the current framework du jour, Facebook's React. You can say that it reaches back to the era before the web app — when desktop and server applications were compiled — to make the web app easier to develop and more enjoyable to user. In this latest episode of The New Stack Makers podcast, we interview the creator of Svelte himself, Rich Harris. Harris started out not as a web developer, but as a journalist who created the framework to do immersive web journalism. So we were interested in that. In addition to delving into history, we also discussed the current landscape of Web frameworks, the Web's Document Object Model, the way React.js updates variables, the value of TypeScript, and the importance SvelteKit. We also chatted about why Vercel, where Harris now works maintaining Svelte, wants to make a home for Svelte. TNS Editor Joab Jackson hosted this conversation. Below are a few excerpts from our conversation, edited for brevity and clarity. So set the stage for us. What was the point that inspired you to create Svelte? To fully tell the story, we need to go way back into the mists of time, back to when I started programming. My background is in journalism. And about a decade ago, I was working in a newsroom at a financial publication in London. I was very inspired by some of the interactive journalism that was being produced at places like the New York Times, but also the BBC and the Guardian and lots of other news organizations, where they were using Flash and increasingly JavaScript, to tell these data rich interactive stories that couldn't really be done any other way. And to me, this felt like the future of journalism, it's something that was using the full power of the web platform as a storytelling medium in a way that just hadn't been done before. And I was very excited about all that, and I wanted a piece of it. So I started learning JavaScript with the help of the help of some some friends, and discovered that it's really difficult. Particularly if you're doing things that have a lot of interactivity. If you're managing lots of state that can be updated in lots of different ways, you end up writing what is often referred to as spaghetti code. And so I started building a toolkit, really, for myself. And this was a project called Reactive, short for interactive, something out of a out of a Neal Stephenson book, in fact, and it actually got a little bit of traction, not it was never huge, but you know, it was my first foray into open source, and it got used in a few different places. And I maintained that for some years, and eventually, I left that company and joined the Guardian in the U.K. And we used Reactive to build interactive pieces of journalism there, I transferred to the U.S. to continue at the guardian in New York. And we use directive quite heavily there as well. After a while, though, it became apparent that, you know, as with many frameworks of that era, it had certain flaws. A lot of these frameworks were built for an era in which desktop computing was prevalent. And we were now in firmly in this age of mobile, first, web development. And these frameworks weren't really up to the task, primarily because they were just too big, they were too big, and they were too bulky and they were too slow. And so in 2016, I started working on what was essentially a successor to that project. And we chose the name Svelte because it has all the right connotations. It's elegant, it's sophisticated. And the idea was to basically provide the same kind of development experience that people were used to, but change the was that translated into the experience end users have when they run it in the browser. It did this by adopting techniques from the compiler world. The code that you write doesn't need to be the code that actually runs in the browser. Svelte was really one of the first frameworks to lean into the compiler paradigm. And as a result, we were able to do things with much less JavaScript, and in a way that was much more performant, which is very important if you're producing these kinds of interactive stories that typically involve like a lot of data, a lot of animation Can you talk a bit about more about the compiler aspect? How does that work with a web application or web page? So, you know, browsers run JavaScript. And like nowadays, they can run WASM, too. But JavaScript is the language that you need to write stuff in if you want to have interactivity on a web page. But that doesn't mean that you need to write JavaScript, if you can design a language that allows you to describe user interfaces in a more natural way, then the compiler could turn that intention into the code that actually runs. And so you get all the benefits of declarative programming but without the drawbacks that historically have accompanied that. There is this trade off that historically existed: the developer wants to write this nice, state driven declarative code and the user doesn't want to have to wait for this bulky JavaScript framework to load over the wire. And then to do all of this extra work to translate your declarative intentions into what actually happens within the browser. And the compiler approach basically allows you to, to square that circle, it means that you get the best of both worlds you're maximizing the developer experience without compromising on developer experience. Stupid question: As a developer, if I'm writing JavaScript code, at least initially, how do I compile it? So pretty much every web app has a build step. It is possible to write web applications that do not involve a build step, you can just write JavaScript, and you can write HTML, and you can import the JavaScript into the HTML and you've got a web app. But that approach, it really doesn't scale, much as some people will try and convince you otherwise. At some point, you're going to have to have a build step so that you can use libraries that you've installed from NPM, so that you can use things like TypeScript to optimize your JavaScript. And so Svelte fits into your existing build step. And so if you have your components that are written in Svelte files, it's literally a .SVELTE extension. Then during the build step, those components will get transformed into JavaScript files. Svelte seemed to take off right around the time we heard complaints about Angular.js. Did the frustrations around Angular help the adoption of Svelte? Svelte hasn't been a replacement for Angular because Angular is a full featured framework. It wants to own the entirety of your web application, whereas Svelte is really just a component framework. So on the spectrum, you have things that are very focused on individual components like React and Vue.js and Svelte. And then at the other end of the spectrum, you have frameworks like Angular, and Ember. And historically, you had to do the work of taking your component framework and figuring out how to build the rest of the application unless you were using one of these full-featured frameworks. Nowadays, that's less true because we have things like Next.js, and remix-vue, And on the Svelte team are currently working on SvelteKit, which is the answer to that question of how do I actually build an app with this? I would attribute the growth in popularity is felt to different forces. Essentially, what happened is it trundled along with a small but dedicated user base for a few years. And then in 2019, we released version three of the framework, which really rethought the authoring experience, the syntax that you use to write components and, and the APIs that are available. Around that time, I gave a couple of conference talks around it. And that's when it really started to pick up steam. Now, of course, we're growing very rapidly. And we're consistently at the top of developer-happiness surveys. And so now, like a lot of people are aware of is, but we're still like a very tiny framework, compared to the big dogs like React and Vue. You have said that part of the Svelte mission has been to make web development fun. What are some of Svelte's attributes that make it less aggravating for the developer? The first thing is that you can write a lot less code. If you're using Svelte, then you can express the same concepts with typically about 40% less code. There's just a lot less ceremony, a lot less boilerplate. We're not constrained by JavaScript. For example, the way that you use state inside a component with React, you have to use hooks. And there's this slightly idiosyncratic way of declaring a local piece of state inside the component. With Svelte, you just declare a variable. And if you assign a new value to that variable, or if it's an object, and you mutate that object, then the compiler interprets that as a sign that it needs to update the component.