Svelte 5: North Star

As a child, I was obsessed with space. I loved coming to places like this. On cloudless nights, I would go into our back garden with my father, himself a bit of a space cadet, and he would teach me how to read the sky. He taught me the names of the stars and the constellations. He taught me that the things that seem most fixed are not fixed, but that through careful observation you can begin to predict their movements. And he taught me how to find the North Star.

On a clear night, if you can find the Big Dipper, then you can extend this line a little further to find Polaris, so named because a line drawn from the South Pole to the North Pole and extended into space would just about meet it. It is the fixed point about which the heavens turn and it always points due north. Ancient mariners used Polaris to cross the oceans. In the early United States, escaped slaves followed it to freedom. Today we don't tend to rely on celestial navigation, we have Google Maps. But I've been thinking a lot lately about this concept of being able to orient ourselves in an otherwise uncertain environment and how it applies to other areas of our lives. What does it mean to be pointing the right way?

My name's Rich Harris, you can find me at richharris.dev on Blue Sky, this is a talk about finding direction and purpose in open source. Like many of you, I write software for a living. More specifically, I work on a user interface called Svelte. I started working on Svelte eight years and three days ago. It started out as an innocent, fun side project that I had no idea would take over my life. The big idea was this. What if a framework, rather than being code that ran in the browser, was a compiler that transformed your component into self-contained JavaScript? We called it the magical disappearing framework and compared to React, it produced astonishingly efficient bundles. Because it moved work out of the browser and into your build process, we could make your apps really small and really fast.

Svelte three came out in 2019 and asked a different question. Can we use the compiler to make web development itself faster? If we're not constrained by the rules of JavaScript, can we make components easier to write with less boilerplate? That was the point at which people really started paying attention to Svelte.

It turns out that while most developers care very deeply about performance and bundle size in theory, in practice we pick the tools we enjoy using. Some thought leaders will try to shame you for this. But I think it's pretty reasonable that if you're going to spend 40 hours a week working on something, it may as well be fun. And with compilers, better developer experience needn't come at the expense of user experience. And Svelte has a really good developer experience, at least according to surveys like the state of JavaScript. I don't know how long we can keep this streak up, but I'm excited to find out.

Svelte by itself only solves a narrow slice of the problem of building a web application. Namely, keeping the DOM in sync with your application state. And leaves everything else to you, like setting up your build tooling, organizing your code, defining your routes, generating optimal bundles and deploying to different environments and many, many other problems. In 2020, we started working on a companion project called SvelteKit, which was the first major framework to be built on top of Vite. It's designed to solve those problems for you.

All of which is to say that the project has had many identities over the course of its life. Last month, we released Svelte 5. On one level, it's very much a continuation. It's a backward-compatible release, which you can drop into an existing project with minimal disruption. But on another, it's the most radical change the project has undergone yet. So at this point, let me take a moment to introduce you or reintroduce you to the new Svelte.

Unlike React, Svelte is unapologetically HTML first. JavaScript is a decent general purpose language. But as a language for describing user interfaces, it's a bad match. When you write JavaScript, you're primarily concerned with the changes between states that result from user interaction. But when you're describing a UI, you're primarily concerned with the states themselves. Frameworks slap a declarative layer on top of JavaScript that lets you sort of pretend. But you often find yourself working against the grain of the language.

Svelte takes a different approach. It takes HTML as the starting point. If you have some valid HTML, whether you wrote it yourself or co-pilot wrote it for you or you found it on CodePen or StackOverflow or even in your browser DevTools, you can drop that into a Svelte component and it will work. The same is not true of JSX, which superficially resembles HTML, but changes it in a variety of subtle and annoying ways.

Just as an HTML document can contain a style element, which will affect that document, a Svelte component can contain a style element whose contents will affect that component. The selectors in here won't match elements in other components, which means you don't need to manually avoid conflicts by giving everything a complicated class name and hoping for the best.

Here we're just using a P selector. You can, of course, use Tailwind and a lot of people do, but the problems Tailwind solves aren't as applicable when you have native scope styles. And CSS is arguably more future proof. Just like how in JavaScript and TypeScript your editor will tell you if you have an unused variable and your minifier will strip it out of your production build, Svelte will eliminate unused styles.

We can, of course, use JavaScript. We can use values directly on our markup or reference values that are defined in the component script tag. Chances are, you want to keep your UI up to date when the values of those variables change. For that, we need them to be reactive. This is the biggest change from Svelte 4 to Svelte 5. Svelte 4 would automatically make variables reactive if it thought it needed to. This was a process that you had no direct control over. In Svelte 5, we explicitly annotate state with something called a rune. A rune is an instruction to the compiler that, in the case of this dollar state rune, tells it to turn the value into something called a signal. The way that you interact with the value is unchanged. It's still just a number as opposed to a function or an object. But the compiler knows that every time it reads that value, such as in this attribute, or writes to it, such as in this event handler, it needs to unwrap the signal. We can simplify this code by replacing it with a binding. This does the same as the existing code, but it's a better articulation of the intent of your app. Svelte has a lot of these sorts of features that simplify common tasks.

For example, if you want to give your UI some pizzazz, you can add transitions, which use a web animations API to control what happens when elements enter or leave the DOM. We'll import the fly transition from Svelte and an easing function from Svelte easing and add that transition to this span element. Now, when we add this transition, the elements smoothly fade in and out. And in, and out, and in, and out, and in, and out. Reactivity in Svelte applies deeply to objects and arrays and is fine grained. In this example, I can add a to do just by calling to dos.push. If I do so, or if I toggle the done state of an individual to do, the number of remaining to dos is recalculated, which you can see because we've wrapped it in a function that calls our monkey patched alert function. But if we edit the text of the to do, nothing happens. Because remaining isn't affected by the text content of these to dos.

Contrast this with React, for example, where the default is to aggressively recalculate everything all the time. One of the major limitations of Svelte 4 was that reactivity only happened inside components. If you wanted to have some shared global state or some reusable reactive logic, then you had to write code in a completely different way. In Svelte 5, that's no longer the case. You can use runes in Svelte.js and Svelte.ts modules as well as in components.

Essentially, we've added reactivity as a language level construct to JavaScript and TypeScript. Now, we're certainly not the first framework to have fine grained reactivity with signals. A lot of frameworks will expose a function for creating signals, which might take the form of a class with a reactive value property or a pair of functions for reading and writing values. So, you might think that Svelte is just doing the same thing as everyone else. But we're actually doing something quite different.

For one thing, when you write code, you're not dealing with a framework API. You're just dealing with normal values. The compiler converts your code to something like this. Because we don't need to worry about the ergonomics of the signal API, under the hood, a Svelte signal is just a plain JavaScript object, which is very cheap to create and update compared to the other methods. We're not messing around with closures and prototype chains and what have you. As a result, Svelte's performance is pretty hard to beat.

This is a recent third party benchmark that compared signal implementations across different libraries. Svelte is the second fastest behind an experimental library that is no longer maintained. But it goes beyond that. Since we deliberately don't expose the signal creating mechanism, in many cases, we can avoid creating a signal at all. For example, during server side rendering where nothing is reactive or when we detect that a piece of state is updated but never directly reassigned. Similarly, if the compiler detects that a chunk of your markup doesn't contain reactive state, it doesn't need to track anything. It can just initialize the DOM and walk away. We call this compiler augmented reactivity. The code generated by the Svelte compiler is smaller and more efficient in terms of both performance and memory. Even if a faster signal implementation comes along, it won't be faster than not creating one that you didn't need in the first place.

It's not magic, but it is pretty magical. So, eight years is a long time in JavaScript. And Svelte has evolved a lot over the course of its life. We like to say that it's become more like itself.

In the same way that people grow into themselves, Svelte has survived its awkward adolescence and its pretentious college years and is now a youthful but mature piece of software at the start of its professional career. The project has hundreds of contributors and hundreds more financial supporters, not least Vercel, which employs three of us to work on it full time.

And the release of Svelte 5 is a good time to take a moment and ask ourselves, what is it we're hoping to achieve with all this work? This question came into focus for me recently during a conversation with Simon Halthausen, who along with me and Dominic Gannoway is one of the three full-time team members. Simon said, and I paraphrase, we have an endless list of ideas that we want to bring to fruition after we launch Svelte 5. How do we prioritize that work? How do we add all this stuff without changing Svelte's fundamental nature? How do we make sure that we're pointing in the right direction? What is our north star?

It's an interesting question to try and answer. Most of us go through life a lot of the time on autopilot, not really thinking about what impact we're trying to have in the world. Particularly if you work on an open source project, you'll know what it's like to spend your days battling issues and feature requests and rarely getting time to zoom out. But take a moment to think about it.

One way to approach it is to try to identify the things that you believe. Particularly if those beliefs are contrarian. Earlier this year I did just that in a post called Tenets, in which I attempted to codify some of the things that motivate us. Number one, the web matters. We work on Svelte because we believe that the web is critically important technology and that its continued survival is not guaranteed. Number two, optimize for vibes. That's right, America, I spell it with an S. People use Svelte because they like Svelte. They like it because it aligns with their aesthetic sensibilities. Instead of striving to be the fastest or smallest or whateverest, we explicitly aim to be the framework with the best vibes. Number three, optimize for adoption. We're not trying to be the most popular framework. We're trying to be the best framework. Sometimes that means making choices that we believe in but that go against the grain of web development trends, such as HTML, the mother language. It's a really good language for describing UI. Svelte augments HTML in a way that makes it a really good language for describing interactive UI. Number five, embrace progress. There is a tendency in the web developer community towards a harmful form of pessimistic nostalgia. The idea that things were better in the pre-lapse era and age before bundlers, Typescript, client side routing, and other trappings of modernity. This is nonsense. As a community, our default position is one of optimism about technology. The platform is getting better, our tools are getting better, our devices are getting better, and if we embrace that fact we can make better stuff.

Number six, numbers lie. Lighthouse has broken the brains of a generation of web developers. We have replaced good judgment with subservience to metrics that were only ever intended to be used as a diagnostic tool. We pay attention to the numbers, but when designing Svelte, we think qualitatively, not quantitatively.

Number seven, magical, Svelte magic. We want Svelte to feel magical, we want you to feel like a wizard when you're using Svelte. Historically, I think Svelte went too far into magic territory where it's not 100 per cent clear why things work a certain way. That's something we are trying to rectify with Svelte 5.

Number eight, dream big. Choose the right tool for the job is sensible but boring advice. It makes us small in our ambitions. I want us to dream bigger. I don't want to feel like my tools can't handle evolving requirements or if I want to dabble in a new field I need to learn an entirely new way of working first. Even if it turns out to be unachievable, I find it valuable to ask the question what would it take for Svelte Git to be the best framework for any app, whether it's purely static content or real-time multiplayer app, offline first productivity app, or even something built for an augmented reality headset. As engineers, we love to talk about trade-offs to the extent we instinctively believe that being good at one thing makes you bad at other things. But that's a scarcity mindset. In the same way that advancements in solar power and battery storage and nuclear fusion are on the cusp, I believe, of reshaping civilization, advancements in tooling mean that web developers are living in a time of abundance. We need to reshape our mindset accordingly. Remember point five. We are optimists.

Number nine, no-one cares. Most people do not care about frameworks. They just want to build something cool, and Svelte is for those people too. This informs our approach to documentation and tutorials. It should be possible to build what you want just by learning the concepts you need in the moment and worrying about the other stuff for another day. I like to call this just-in-time documentation.

Number ten, design by consensus. Svelte is a community-driven and consensus-led project. Many of Svelte's best ideas originated outside the core team. It is important the community has a stake in the project's future. These tenets guide our actions but none of them qualify as a north star. They're not telling us what to do so much as how to do it.

A few weeks ago, when the Svelte maintainers gathered online for our monthly meeting, this was our main topic of discussion. What are we striving towards? What is the change we hope to bring about in the world? A lot of ideas came up in that discussion, but we kept returning to one in particular. Software is broken. I think you all know what I mean by this. Most of us have probably had the experience of deleting an element in DevTools or removing a button's disabled attribute so we can submit a form, or waiting 30 seconds for a payment to go through before seeing an unstyled guru meditation page and not knowing if it succeeded, or helping a relative accomplish some basic task because the app they're using is just too dang confusing.

I offer you a challenge. Over the course of a week, make a note of every time you use a piece of software and it fails in some basic way. An app that crashes or fails to start, a remember me on this computer check box that does nothing, a visible error code that doesn't mean anything and doesn't offer any remedial action. When Spotify gets stuck in limbo between offline and online mode, make a note of it. When GitHub shows stale data or nukes the piece of UI you're about to interact with or collapses conversations to the point of uselessness, make a note of it. When the Twitter mobile web app fails to open the DM tab, make a note of it. When the Instagram web app breaks the back button, make a note of it. When your phone pings but the notification drawer only shows emails from a week ago, make a note of it. When command click opens a link in the current tab instead of a new one, make a note of it. When you try to read an article but your phone locks up because of all the tracking junk and badly coded ad tech, make a note of it. When you're walking around a city and you see a blue screen of death on an ATM or an advertising screen, make a note of it. These are all things I experience all the time. And I could go on for a while, but you get the point.

There's a reason this joke from the it crowd resonates. Those of us who work in tech have just decided that this is acceptable and as software eats the world, we try to convince everyone else that it's acceptable, too. But it's not.

As an industry, we have failed. We deserve to have our jobs taken by artificial intelligence. Don't imagine for a moment that artificial intelligence will save us, though. If you've paid any attention to the AI slot that's drowning social media or Amazon or Google, then you already know that we are facing an incoming tsunami of garbage software.

So, if every aspect of our lives is going to be mediated by software, we should aspire to something better. I want software that's rad, resilient, accessible, delightful. Resilient means that it works, is secure and degrades gracefully in the face of intermittent networks, underpowered devices and unexpected user input. Accessible means it works for everyone, not just non-disabled people with expensive phones and unlimited data plans. Delightful means I look forward to using it because I trust it to help me accomplish my task quickly and without bullshit.

So, in concrete terms, what would it mean to explicitly orient a project around these problems? Some things are obvious. We're currently prioritizing error boundaries and better debugging primitives so it's easier to make your apps resilient. We also want to invest in really good developer tooling. I really like the idea behind Astro's developer toolbar and think we should copy it so we can provide better accessibility diagnostics than the ones we generate by statically analyzing your code. This focus also helps us think about what we consider ourselves responsible for. We spend a lot of time in the JavaScript world talking about whether we should have our own Laravel or Rails. Should SvelteKit have opinions about databases and local first development? Should we have an official component library? Maybe.

Some of it is more speculative still. Given that AI is a reality of our work now, we're asking ourselves questions like how can we ensure that generative AI knows how to build high quality Svelte components? Or better than having an AI try to write our apps for us, could we one day use it to help fill the gaps in QA and user testing so that we have fewer blind spots? We don't have the answers to all these questions. But knowing which questions to ask is a step in the right direction. This, to me, is a mission worth signing up for. I love the web and I want to do my part to preserve it for generations to come. If we can nudge it in the right direction, even just a little bit, it will have been worthwhile. The North Star changes over time because the earth is wobbly. Today it's Polaris. When the ancient Egyptians built the pyramids, they oriented them towards a star called Thuban, and centuries to come, Polaris will be usurped. So, too, our priorities will shift as they have shifted before. But for now, this is our North Star.

Svelte exists to help us make better software. Thank you for listening. One last thing. Kevin from Svelte Society is somewhere in this room with a dozen Svelte T-shirts. If you would like one, go find him. Thank you.

All right. Your first question comes from Anonymous, and it is, what's the one thing that you wish people knew about building open source software or Svelte that isn't obvious from the outside? About building open source software in general? It's so much harder than you think, just in terms of the amount of work that you have to do. I posted on Blue Sky the other day about the fact that it had been eight years to the day since I started Svelte, and someone replied with, hang on a minute, version one came out like a week later. And version one is easy. It's all of the rest of the shit that takes the time. You've got to write documentation, tutorials, you've got to build a community, you've got to do so much, write tests, all of these things. And I, for one, have repeatedly underestimated quite significantly just how much work is involved. Which is not to dissuade anyone from embarking on an open source project, but it's definitely something that you should go into with your eyes wide open. Definitely.

This next one I think may be related to your work with Rollup, because they're asking about Rust. They're saying, do you see Rust becoming the default parser or build tool language in the future or do you think this should happen? It clearly is happening. There is a lot of momentum around that idea. I am not a Rustation, so if this does happen, I kind of feel like either I'm going to have to get in line or I'm going to be left out of it. I kind of like the fact that we have the ability to write our tooling in the language that we're all familiar with. And I think that's been a real boon to our entire community. And part of me is definitely a little bit sad with the shift to native language tooling, we might lose a little bit of that. But here's hoping it doesn't. Definitely.

I had this question, too. I'm glad somebody else asked it. What's your word per minute typing? And were you typing those examples? Are you really that fast? Okay. Awesome.

What's your word per minute typing? And were you typing those examples? Are you really that fast? Okay. Awesome.

I'll have to add that to my bag of tricks.

This one is from Ben. Can you elaborate on the parts of Svelte you think were too magical in the past? So the main one was just the variables would automatically become reactive. And whereas today we have what we now call compiler augmented reactivity. In Svelte 3 and 4 we had compiler driven reactivity. Which is to say that we would say that a variable was reactive if it was declared at the top level of a component and it was reassigned somewhere inside your component. And then if we wanted to have a computation or we call them derives now, then we hijacked a piece of syntax, the label syntax, dollar label, and then anything that follows it will automatically rerun when any of the pieces of state that are referenced inside that block change. And this works really well for simple cases. And people really want to it. But it turns out that if you build very large applications, compiler driven reactivity just doesn't really work. You find yourself hitting the limits of what you can do with static analysis. And that's very much what we found. Which is why when we were starting to think about the future of Svelte, we looked around, everyone else had gone into signals land, and we were like, yeah, we'll have some of that. And honestly, it's much better. I'll say in my experience, because I've written a lot of Svelte and then learning Svelte 5, I find that Svelte 5 makes the simpler problems slightly harder but the harder problems much simpler. Because I ran into issues with the label syntax. It's really easy to get an infinite loop if you have weird dependencies in your tracking there. Svelte 5 makes that much more explicit.

This next question comes from Daniel. Why are there so many frameworks? Are you actually solving different problems? I consider it a real blessing that we are in a community that is large enough to sustain this many different frameworks. The whole optimize for vibes thing. What I'm really saying with that is that you can build any app with any of these frameworks. And it really is just a matter of taste. You know, I don't want to live in a world where there's, I don't know, only one kind of peanut butter or whatever. I like the fact that I have choices. And that's what it is for me in JavaScript frameworks, too. Yes, there's a lot of them. But they're all coming at things from a slightly different angle and we're all informing each other.

Every framework brings something new to the table. And even if there's a lot of overlap, by pushing the boundaries in different directions, the rising tide really does lift all boats. A lot of communities don't have that. I know it's a meme. I know it's zero days since the last JavaScript framework or whatever. But, like, honestly cherish it. It's a precious thing.

Most front-end frameworks now have signals. A few are now getting compilers. What's the next advancement that most frameworks will implement? And I guess also where they were probably inspired by Svelte. It sort of feels like rendering is a solved problem. Like, we know how to take some state and turn it into a piece of DOM that updates. It does feel to me like we need to start moving beyond that and start thinking about in a more holistic way, what can we do that every app needs? What can we bring into a shared foundation so that we're not having to reinvent this stuff all the time?

The statistics are pretty dire, honestly. If you look at the time that people spend on their devices, people use the web a lot on desktop. But on mobile, it's like less than a quarter, I think. And it's declining. And that's partly because the platform itself is sometimes candidly a little bit wonky. It's hard to make a really high quality experience on the web compared to a native app. But it's also because there are these entrenched interests, right? App stores make a lot of money for Apple and Google. So, the incentives to promote the web don't exist in the same way as they exist to promote native apps. And that's a real shame. Because the web is the only open permissionless platform. It is the greatest application delivery mechanism ever created. And there is a real danger that we'll lose it if we can't build things that people want to use instead of resorting to native apps.