svelte: The Framework That Disappears

The Newsroom Compiler

This is episode seven of What Did I Just Install.

Picture a newsroom in two thousand and sixteen. Not the kind with typewriters and cigarette smoke, but the kind with thirty-two inch monitors showing real-time traffic dashboards and an editor pacing behind a row of developers. It is the day before a major investigative piece goes live. The interactive data visualization that accompanies it needs to load on a phone in rural Alabama just as smoothly as it loads on a fiber connection in Manhattan. Millions of people will hit this page in the first hour. And the developer responsible for making that happen is a philosophy graduate from University College London who used to be a financial reporter.

His name is Rich Harris. You might remember him from our left-pad episode, where he argued that the micro-module philosophy was not quite as simple as its defenders claimed. But that was a footnote. The real story of Rich Harris is much bigger, and much stranger, than a blog post about dependency trees. It is the story of how a journalist with no computer science degree looked at every major JavaScript framework, decided they were all doing it wrong, and built something that the industry is still trying to understand a decade later.

The package is called Svelte. And unlike React, unlike Vue, unlike Angular, it is not a framework that runs in your browser. It is a framework that runs on your computer once, compiles your code into lean vanilla JavaScript, and then vanishes. The framework disappears. What gets shipped to the user is just the code they need and nothing else. No runtime library. No virtual DOM diffing engine. No framework tax.

To understand why that matters, and why a journalist was the person to figure it out, you have to go back to a newsroom in London where the web was being reinvented one deadline at a time.

A Philosopher Walks into a Newsroom

Rich Harris studied philosophy at University College London. Not computer science, not mathematics, not engineering. Philosophy. He graduated and did what many philosophy graduates do, which is figure out what to actually do with a philosophy degree. He landed at Citywire, a financial publication in London, right around the two thousand and eight financial crash. His title was financial reporter, but he also did video journalism and web production. It was a small outfit and everyone wore multiple hats.

While making videos about collapsing banks, Harris was watching what organizations like the BBC, The Guardian, and The New York Times were doing with the web. These newsrooms were not just publishing articles anymore. They were building interactive experiences, data visualizations that let readers explore complex datasets, maps that updated in real time, visual stories that scrolled and animated and responded to the reader's touch. Harris was mesmerized. As he later recalled, he was very inspired by the work happening at those places, and he realized that if he was going to make it in this industry, he needed to become more employable. So he started teaching himself JavaScript.

This is the detail that makes the entire Svelte story make sense. Harris did not learn to code as a teenager in a basement. He did not study algorithms at Stanford. He learned JavaScript because he wanted to tell better stories with data. Every design decision he would later make, every philosophical stance he would take about how frameworks should work, traces back to this moment. He needed fast, small, interactive pieces that would load instantly on any device, because his readers were not developers with fast machines. They were ordinary people clicking a link on their phones. The user came first, not the developer experience, not the framework's elegance, not the theoretical purity. The user on a slow phone in a place with bad signal.

He got good. Good enough that The Guardian hired him for their interactive team, the group that built data visualizations and investigative interactives for the website. The Guardian's interactive team was small but legendary in journalism circles. The Guardian's digital team had won major awards for their interactive journalism, including an Emmy. Harris was part of that world, building things that millions of people would see, under deadlines that left no room for bloated code.

The Thing Before the Thing

At The Guardian, Harris hit a wall. The JavaScript frameworks available at the time were not built for newsroom interactives. They shipped too much code to the browser. They were designed for long-lived single-page applications, not for a visualization that someone would look at for ninety seconds and then close the tab. He needed something lighter, something that could handle data binding and DOM manipulation without the overhead. So he built it himself.

The project was called Ractive.js. If that name sounds like "reactive" with the letters shuffled around, that is because it is. Harris created Ractive because, as he put it, his dream library did not exist. The premise was simple and at the time somewhat radical: declarative programming is easier than imperative programming, and a library should let you describe what the interface should look like rather than manually updating the DOM every time data changes.

When I started building tools, I did so because the existing ones frankly did not allow me to do the job that I wanted to do, as well as I wanted to do it.

Ractive got attention. The Guardian used it internally for interactive stories, including projects like The Counted, their investigative database tracking police shootings in the United States. Other newsrooms picked it up. It was good. But Harris knew it had a fundamental problem that shared a flaw with every other framework of that era. It shipped too much JavaScript. On a desktop with a fast connection, nobody noticed. On a phone in two thousand and fourteen, where mobile web traffic was exploding but mobile processors and connections were still catching up, the cost was real. Every kilobyte of framework code was a kilobyte the user had to download, parse, and execute before they could see anything useful.

Harris left The Guardian's London office and moved to the United States, joining Guardian US in New York. Eventually he moved to The New York Times, where his job title was graphics editor, though he described himself more accurately as a JavaScript journalist. He worked on the Investigations team, using computational techniques to find stories in data and then building the interactive pieces that told those stories to the public.

The Thanksgiving Epiphany

The story of Svelte's creation has a specific date attached to it. It was Thanksgiving two thousand and sixteen. Harris was turning Ractive's limitations over in his mind, and a conversation about compilers sparked an idea that would not let go. What if the framework did not have to ship to the browser at all? What if it did all its work at build time, turning your components into optimized vanilla JavaScript, and then stepped aside completely?

Svelte began as an act of atonement for my sins. The idea happened around Thanksgiving twenty sixteen.

He spent a few furious days coding. When he emerged, he had the first version of what he called Svelte. The word means slim, elegant, gracefully thin. For a framework whose entire philosophy was about shipping less code to the browser, it was a perfect name. Harris and some colleagues at The Guardian had kicked the name around. In a world of frameworks named after concepts and mythological figures, a simple English adjective that described exactly what the framework aimed to be felt right.

But here is the thing that made people skeptical. The JavaScript world in late two thousand and sixteen was firmly in the grip of React. Facebook's virtual DOM approach had won the framework wars of that era. Angular was the enterprise choice. Vue was the elegant newcomer. None of these approaches was right. The virtual DOM itself was a wasteful abstraction. A compiler could produce better code than a runtime. That was the claim, and in late twenty sixteen it was considered somewhere between contrarian and crazy.

Harris announced Svelte with a blog post and a talk. The reception was polite but cautious. Some people were intrigued by the compiler concept. Others dismissed it as a neat trick that would not scale. Version one was rough. Version two refined the approach but still had not found the syntax and developer experience that would make people fall in love. Svelte existed in that uncomfortable space of being technically interesting but not yet practically compelling enough to switch to.

Rethinking Everything

Then came twenty nineteen. Svelte three.

Harris gave a talk at You Gotta Love Frontend called Rethinking Reactivity. The title was a provocation aimed directly at React, which despite its name, is not actually reactive. In React, when state changes, the framework re-renders the entire component tree and then diffs the result against the previous version to figure out what actually changed in the DOM. It is clever but fundamentally wasteful. You are doing work twice, once to build the new virtual DOM and once to compare it with the old one. Svelte three threw all of that away.

It does not make sense to do a lot of work in the browser when every single user has to do that work and you have to ship the code that does that work, when you could just do that at compile time.

The key insight was elegant. In Svelte three, reactivity was not a runtime feature. It was a compiler feature. If you wrote count plus equals one, the compiler could see at build time that you had made an assignment to a value the template was bound to, and it would generate the precise DOM update code needed. No virtual DOM. No diffing. No runtime overhead. Just the exact instructions to change the exact element that needed changing.

The developer experience was startling. A Svelte component was just HTML, with script and style blocks. No JSX. No template language. No importing hooks or composables. You wrote something that looked like a web page and it compiled into something that ran like a hand-optimized program. Harris had a line that captured this beautifully.

Frameworks are not tools for organising your code. They are tools for organising your mind.

The Rethinking Reactivity talk went viral in developer circles. It was not just a framework launch. It was a philosophical challenge to the entire React-dominated ecosystem. Harris was saying, gently but firmly, that the virtual DOM was a solved problem solving the wrong problem. That the industry had optimized for developer convenience at the expense of user experience. That a compiler could give you both.

The community response was electric. Developers who tried Svelte three kept saying the same thing. It felt like cheating. It was too easy. You wrote less code, the bundles were smaller, the performance was better, and the learning curve was gentler. The State of JavaScript survey started showing Svelte with the highest satisfaction scores of any framework. Not the highest usage, mind you. React still dominated there by an enormous margin. But among developers who had actually tried Svelte, the love was almost universal.

The Bundler and the Kingdom

It is worth pausing the Svelte story to note something important. Rich Harris did not just build one framework and one precursor framework. He also built Rollup, the JavaScript module bundler.

Rollup was created in two thousand and fifteen, a year before Svelte. Its core idea was tree shaking, the ability to analyze your import statements and throw away any code that was not actually used. When you imported a function from a large library, Rollup would include just that function and its dependencies, not the entire library. This seems obvious now. In two thousand and fifteen, it was not. Webpack, the dominant bundler of the time, bundled everything and let the developer figure out code splitting.

Rollup matters to the Svelte story for two reasons. First, it shows that Harris was already thinking in terms of compilation and optimization before Svelte existed. The compiler mindset was not an overnight insight. It was a way of thinking about web development that had been building for years. Second, Rollup became part of the infrastructure that the entire JavaScript ecosystem depends on. When Evan You built Vite, the blazing-fast development server that would eventually become the default build tool for Vue and a growing number of other frameworks, he used Rollup under the hood for production builds. By the time Harris had also accumulated nearly twenty-five thousand GitHub stars on Rollup alone, the man had quietly shaped the build tool landscape as much as the framework landscape.

This is the part of the Rich Harris story that does not get told enough. He is not just the Svelte guy. He built the bundler that other frameworks rely on. He built the precursor framework that proved declarative UI worked in newsrooms. He contributed to the intellectual foundation, the idea that compilation can replace runtime work, that now influences projects far beyond his own. When people talk about the JavaScript ecosystem, they often miss that one person, working from a newsroom, created several of the tools they use every day without knowing it.

From Sapper to SvelteKit

As Svelte three gained momentum, the community needed an answer to a question that every component framework faces. How do you build a full application with this thing? React had Next.js. Vue had Nuxt. Svelte had Sapper.

Sapper was the application framework Harris built around Svelte, named after a military engineering term for someone who builds bridges and trenches. It handled routing, server-side rendering, code splitting, and all the other things you need for a real web application beyond individual components. Sapper worked, but it had accumulated design decisions that Harris was not happy with. In October of twenty twenty, he announced its successor: SvelteKit.

The transition from Sapper to SvelteKit was more than a rebrand. It was a fundamental rethink of how a Svelte application should be built, and it would take over two years to reach version one point zero. SvelteKit launched in December twenty twenty-two after an extended beta that tested the patience of early adopters but ultimately produced a framework that reviewers consistently praised for its developer experience.

SvelteKit is to Svelte what Next.js is to React, a meta-framework that handles the plumbing of real applications. File-based routing, server-side rendering, API endpoints, form handling, deployment to multiple platforms. But SvelteKit carries the same compiler-first philosophy as Svelte itself. Everything that can be done at build time is done at build time. The result is applications that are smaller, faster, and simpler than their equivalents in other frameworks, at least in theory. In practice, the difference matters most exactly where Harris always said it would: on slow connections and underpowered devices.

The Vercel Paradox

In November twenty twenty-one, something happened that sent ripples through the JavaScript community. Rich Harris announced that he was joining Vercel, the company behind Next.js, to work on Svelte full time.

Let that sink in. Vercel is the Next.js company. Next.js is built on React. React is Svelte's primary competitor. The company that had built its entire business on the React ecosystem was now paying the salary of the person who had spent five years arguing that React's fundamental approach was wrong. It was as if Coca-Cola had hired the inventor of Pepsi and said, go ahead, keep making Pepsi, we will fund it.

Today is a big day for Svelte. I have joined Vercel to work on it full time. So happy about what this means for Svelte's future. It will be the same independent, pluralistic project as before, but with Vercel's backing we can get ambitious.

The community reaction was, as the corporate bloggers like to say, mixed. Many developers were thrilled. Harris had been building Svelte in his spare time around a demanding job at The New York Times. Having him work on it full time, backed by serious funding, meant faster progress, better documentation, and the kind of stability that open source projects desperately need. For the first time in its history, Svelte had a dedicated full-time developer.

But the skeptics had questions. Vercel makes money by hosting web applications. Next.js is their flagship product and their primary funnel for getting developers onto the Vercel platform. Why would they fund a competitor to their own framework? Was this an embrace-extend-extinguish play? Would SvelteKit be subtly steered toward Vercel's hosting platform in ways that disadvantaged other deployment targets? And the deeper question that surfaces every time a corporation funds an open source project: what happens when the business priorities change?

Harris addressed this directly. The governance of Svelte would not change. It remained an independent, community-driven project. Vercel's bet was that supporting the broader ecosystem, not just React, made them a better platform. And cynically or not, having the Svelte creator on payroll meant that SvelteKit would deploy beautifully to Vercel, which was good for business regardless of whether Svelte ever overtook React.

The pattern is familiar if you have been following this series. We saw it with npm being acquired by GitHub and then Microsoft. We saw it with Express passing through StrongLoop to IBM. Corporate backing is the lifeblood that open source projects need to survive, and simultaneously the thing most likely to change what they are. The Svelte community, to its credit, has maintained its independence better than most. Harris still makes the design decisions. The project still accepts contributions from anyone. But the tension is always there, simmering just below the surface.

The Runes Gamble

For seven years, Svelte's calling card was its simplicity. You wrote normal-looking JavaScript and the compiler figured out the reactivity. Variable assignment was reactivity. It was beautiful. It was unusual. It was the thing that made developers fall in love at first sight.

And then, with Svelte five, Harris changed everything.

The release landed on October nineteenth, twenty twenty-four, and it introduced a system called runes. Instead of the compiler magically inferring reactivity from plain assignment statements, Svelte five asked developers to be explicit. You wrapped reactive state in a dollar sign state function call. You wrapped derived values in dollar sign derived. You wrapped side effects in dollar sign effect. The magic was replaced with explicitness.

The community reaction was volcanic. Some developers felt betrayed. The simplicity that had defined Svelte, the thing that made it different from React and Vue, was being replaced with something that looked suspiciously like React hooks or Vue composables. One developer wrote that Svelte was going through an identity crisis. The old way, where you could just write let count equals zero and the compiler would handle everything, was being deprecated in favor of let count equals dollar sign state of zero. More characters. More cognitive overhead. More framework-specific syntax.

Svelte four reactive assignments were beautiful. Svelte five runes are more verbose. It feels like we are losing what made Svelte, Svelte.

But Harris had his reasons, and they were substantial. The magical inference approach had edge cases that were genuinely confusing. When did reactivity apply and when did it not? What about objects? What about passing reactive values across module boundaries? The compiler could handle simple cases, but complex applications kept hitting walls where the magic broke down and developers had to understand the internals anyway. Runes made the contract explicit. You always knew what was reactive and what was not. It was more typing, but fewer surprises.

We should not be surprised that we are in the middle of another one of these pendulum swings right now.

The runes debate exposed a philosophical split in the Svelte community. One camp valued the magic, the thing that made Svelte feel different. The other camp valued the explicitness, the thing that would make Svelte scale to larger teams and more complex applications. Harris chose the latter, betting that growing the community was worth upsetting some of its most passionate early members. Time will tell whether the bet pays off. But the early indicators are positive. Svelte five has the highest developer satisfaction scores in the twenty twenty-four Stack Overflow survey, at nearly seventy-three percent, ahead of React, Vue, and Angular.

The Eternal Framework Cycle

Here is where we zoom out. Because the Svelte story is not just the story of one framework. It is the latest chapter in a cycle that JavaScript has been spinning through for twenty years, and understanding that cycle is essential to understanding what Svelte actually means.

In the beginning, there was just the DOM. Raw document dot get element by ID, raw event handlers, raw string concatenation to build HTML. It was painful and everyone hated it. Then jQuery arrived in two thousand and six and made the DOM tolerable. Then Backbone arrived in two thousand and ten and introduced structure. Then Angular arrived in two thousand and ten as well and introduced the idea of a full framework with data binding. Then React arrived in two thousand and thirteen and said forget data binding, just re-render everything and diff the result. Then Vue arrived in two thousand and fourteen and took React's ideas and made them more approachable. Then Svelte arrived in two thousand and sixteen and said the entire runtime approach was wrong.

Each new framework was, in part, a reaction to the limitations of the one before it. jQuery was too unstructured. Backbone was too boilerplate-heavy. Angular was too complex. React was too much runtime overhead. Vue was, frankly, very good, but still carried the virtual DOM tax. Svelte eliminated the tax entirely.

But here is the uncomfortable question. Is Svelte actually different, or is it just the latest turn of the wheel? Every framework in the history of JavaScript has been announced with the claim that it solves the problems of its predecessors. Every framework has had a honeymoon period where its community was passionate and its satisfaction scores were sky-high. And every framework has eventually accumulated enough complexity that the next generation of developers looks at it and says, surely we can do better.

Harris is honest about this. He has talked about pendulum swings, about the way the industry oscillates between simplicity and complexity, between convention and configuration, between server rendering and client rendering. Svelte five's runes are themselves a pendulum swing, from implicit magic to explicit contracts. The question is not whether the cycle will continue but whether Svelte's compiler-first philosophy represents something genuinely new that transcends the cycle, or just another variation within it.

The case for Svelte being different is real. The compiler approach is not just a different philosophy. It is a different architecture. React, Vue, and Angular all ship a runtime to the browser, a piece of framework code that interprets your components at run time. Svelte ships no runtime. The compiled output is vanilla JavaScript that directly manipulates the DOM. This is not a matter of opinion or aesthetic preference. It is a measurable difference in bundle size, parse time, and runtime performance. Svelte applications are consistently smaller and faster than their equivalents in other frameworks.

The case against Svelte being different is also real. The JavaScript ecosystem has a long history of compiler-based approaches that seemed revolutionary at the time and then faded. CoffeeScript compiled to JavaScript and was going to change everything. Google Web Toolkit compiled Java to JavaScript and was going to change everything. Dart was supposed to replace JavaScript entirely. The compiler approach is not inherently a guarantee of success. What matters is whether the community grows large enough and the ecosystem becomes rich enough to sustain itself against the gravitational pull of React's dominance.

The Numbers Game

Let us talk about where Svelte actually stands, because the numbers tell an interesting and somewhat contradictory story.

As of early twenty twenty-six, Svelte gets roughly two million weekly downloads on npm. That sounds impressive until you learn that React gets over twenty-five million. Vue gets around four million. Svelte is not third place. It is a distant fourth among the major frameworks, and the gap is not closing quickly. In raw usage, Svelte is a niche product. A growing niche, but a niche.

But satisfaction tells a completely different story. In survey after survey, developers who have used Svelte love it more than developers who have used any other framework. The twenty twenty-four Stack Overflow survey put Svelte at seventy-three percent admired, compared to sixty-two percent for React and sixty percent for Vue. The State of JavaScript surveys have consistently shown Svelte with the highest satisfaction and interest scores. There is a chasm between how many people use Svelte and how much the people who use it enjoy using it.

This pattern has a name in the startup world. It is the product that everyone loves but nobody switches to. And the reasons are structural. React has an enormous ecosystem of libraries, components, and hiring pools. Companies that chose React five years ago are not going to rewrite their applications just because a survey says developers are happier with Svelte. The switching costs are too high. The talent pool is too thin. And the business case, ship slightly smaller bundles, is not compelling enough to justify the migration.

Harris knows this. He has never chased market share. His pitch has always been about the experience of building things, not about winning the framework war. And in a way, that is Svelte's greatest strength and its most frustrating limitation. It is the framework that everyone admits is better but nobody is willing to bet their company on.

The Tree That Disappears

The dependency tree story of Svelte is unlike any other framework's, and that is precisely the point.

When you install React, you get react and react-dom, and then you need a build tool, and a state management library, and a routing library, and a styling solution, and before long your node modules folder has accumulated hundreds of packages and your dependency tree looks like a small forest. Svelte's dependency tree is minimal by design. The runtime cost is essentially zero because there is no runtime. What you ship to the browser depends only on what your application actually uses, tree-shaken and compiled down to the bare minimum.

SvelteKit adds more dependencies, as any meta-framework must, but even SvelteKit's tree is remarkably lean compared to Next.js. The entire philosophy is about having less. Less code shipped. Less runtime overhead. Less configuration. Less framework getting between the developer and the browser. Harris has described Svelte as a love letter to the web platform itself. Other frameworks abstract away the browser. Svelte compiles down to the browser's native capabilities.

HTML is the language of the web. JavaScript is not the language of the web. JavaScript is one of the three languages that are sort of contained within HTML, because HTML is designed to contain CSS and JavaScript.

This philosophical stance, that the web platform itself is the foundation and frameworks should enhance it rather than replace it, is what makes Svelte feel different from React. React treats the DOM as an afterthought, a rendering target that could be swapped out for anything, which is why React Native and React Server Components exist. Svelte treats the DOM as the point. The browser is not a limitation to be abstracted away. It is the medium.

The JavaScript Journalist

There is something poetic about a journalist being the person to build a framework that prioritizes the end user over the developer. Journalists do not build for other developers. They build for readers, for viewers, for the public. Harris spent years building interactives that had to work for everyone, not just people with fast computers and ad blockers. That sensibility is embedded in every design decision in Svelte.

At The New York Times, Harris described his role as being on the Investigations team, using computational techniques to find things out and then building the interactives that told those stories. The tools he built were not products with long lifecycles and dedicated engineering teams. They were one-off pieces that had to work perfectly on launch day, load fast, render correctly on every device, and then quietly do their job for years in the archive. The constraints of newsroom development, small bundles, broad compatibility, tight deadlines, minimal dependencies, are exactly the constraints that Svelte optimizes for.

My job title is graphics editor, which is a slightly nebulous job title. I am a JavaScript journalist.

This is why Svelte resonates with a certain kind of developer. The developer who cares about what gets shipped to the user, not just what the code looks like on the developer's screen. The developer who has felt the frustration of explaining to a non-technical stakeholder why the site is slow, knowing that the answer is two megabytes of framework code the user did not ask for. The developer who has looked at their bundle analysis and wondered why the thing that makes the buttons work is larger than the entire application logic.

Harris's journey from philosophy student to financial reporter to data journalist to framework author follows no established career path. There is no bootcamp for this, no degree program, no internship pipeline. He taught himself JavaScript because he wanted to tell stories better, and in doing so he invented a new way to think about web frameworks. The philosophy degree, far from being irrelevant, gave him the intellectual tools to question first principles that computer science graduates took for granted. Why does the framework need to run in the browser? Why does reactivity need a runtime? Why do we accept the virtual DOM as a given? These are philosophical questions as much as technical ones, and it took a philosopher to ask them.

Where It Connects

Svelte is not a theoretical framework. It is the tool that thousands of teams have chosen over React and Vue for projects where performance and simplicity matter more than ecosystem size. Startups pick it because they ship faster. Newsrooms pick it because their readers are on slow phones. Agencies pick it because smaller bundles mean lower hosting costs. And individual developers pick it because writing Svelte feels like writing HTML with superpowers, not like learning a new programming language.

When you install SvelteKit, you are installing a framework built by a British philosophy graduate who taught himself JavaScript in a London newsroom, refined his ideas building data visualizations for The Guardian and The New York Times, announced his radical compiler approach over Thanksgiving weekend in twenty sixteen, spent five years proving that the virtual DOM was unnecessary overhead, and then got hired by the company behind his framework's biggest competitor to work on it full time. Every Svelte component you write compiles down to code that carries that lineage, the newsroom urgency, the compiler conviction, the user-first philosophy.

The framework that disappears. That is not just a tagline about bundle size. It is a design philosophy that says the best framework is the one the user never has to download. Rich Harris did not set out to win the framework wars. He set out to make a web page load faster on a phone. Everything else followed from there.

Two million weekly downloads. Seventy-three percent satisfaction. A compiler that turns your code into the leanest possible JavaScript. And a creator who still describes himself, after everything, as a JavaScript journalist. In the eternal cycle of JavaScript frameworks, Svelte might not be the last word. But it might be the first one that asked the right question. Not how do we make this easier for developers, but how do we make this better for the people who actually use what we build.

That was episode seven.

Open a terminal and type npx sv create my-app. Answer the prompts, pick whatever options look interesting, and let it scaffold a project. Then cd my-app, npm install, npm run dev. Open localhost in your browser. You have a running Svelte application. Now open the source file for the main page component and change some text. Save the file. The browser updates before your finger leaves the key. That is the compiler at work. No runtime downloading, no virtual DOM diffing, just your code compiled into the leanest JavaScript the browser needs. Rich Harris built this for a reader on a slow phone. You just felt what that philosophy looks like from the developer's side.