Svelte Creator Harris Rejects React Virtual DOM in Compiler Push
You Gotta Love Frontend
Runtime virtual DOM diffing imposes unnecessary performance overhead that frameworks can eliminate by shifting reactivity directly into build-time compiler code.
AI-assisted summary of Rich Harris - Rethinking reactivity — original source. Check the original for full context.
Source published:
Key ideas
- Svelte 3 reframes frameworks as build-time compilers rather than runtime libraries, eliminating the virtual DOM to compile declarative code into surgical DOM mutations instrumented around standard JavaScript assignments. (6:39)
- By co-opting JavaScript labeled statements ($:), Svelte implements topologically ordered reactive declarations and side effects without the manual dependency arrays or boilerplate required by hooks like useMemo. (13:40)
- Architectural workarounds like React's Concurrent Mode treat the symptoms of runtime diffing overhead rather than root causes, whereas compile-time reactivity delivers buttery-smooth performance even on constrained platforms like 200,000 Brazilian point-of-sale terminals. (19:35)
- Operating as a compiler decouples framework capabilities from shipped bundle size, enabling built-in features such as scoped CSS, a11y compiler warnings, and off-main-thread CSS animations without penalizing unneeded code paths. (31:54)
Detailed notes
## Background Published on YouTube by You Gotta Love Frontend on April 22, 2019, this presentation features Rich Harris speaking at YGLF 2019. The session description highlights how modern frameworks incur runtime overhead to track state, proposing an alternative architecture that moves reactivity into the language itself via compilation to make applications smaller and faster.
## TL;DR Rich Harris critiques the runtime costs and abstraction leaks of virtual DOM-based frameworks like React, tracing the history of reactive programming back to early electronic spreadsheets like LANPAR and Lotus 1-2-3. He presents Svelte 3, which fundamentally rethinks reactivity by shifting change detection and DOM updates to a build-time compiler rather than maintaining an in-browser virtual DOM. By instrumenting standard JavaScript assignments and repurposing labeled statements ($:) for topologically sorted derived state, Svelte generates surgical, imperative DOM updates that eliminate reconciliation bottlenecks. Harris demonstrates how this compiled approach dramatically improves real-world performance on constrained devices like point-of-sale terminals and smart TVs, while offering built-in scoped styles, compiler-driven accessibility checks, off-thread CSS transitions, and an approachable syntax that lowers barriers for cross-disciplinary teams.
## Atmosphere & style The presentation feels intellectual, witty, and quietly subversive, striking an engaging balance between historical appreciation and provocative engineering critique. Harris carries an easygoing, self-deprecating stage presence—cracking jokes about Kyle Simpson, playful benchmark trolling, and Candyman—while maintaining unapologetically high engineering standards that question industry orthodoxy. The room moves from chuckles over esoteric JavaScript syntax to genuine awe during live performance demonstrations, creating an inspiring, forward-looking atmosphere centered on craftsmanship, radical simplicity, and broader accessibility.
## Bulletin - [06:39](https://www.youtube.com/watch?v=AdNJ3fydeao&t=399s) Svelte 3 reframes frameworks as build-time compilers rather than runtime libraries, eliminating the virtual DOM to compile declarative code into surgical DOM mutations instrumented around standard JavaScript assignments. - [13:40](https://www.youtube.com/watch?v=AdNJ3fydeao&t=820s) By co-opting JavaScript labeled statements ($:), Svelte implements topologically ordered reactive declarations and side effects without the manual dependency arrays or boilerplate required by hooks like useMemo. - [19:35](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1175s) Architectural workarounds like React's Concurrent Mode treat the symptoms of runtime diffing overhead rather than root causes, whereas compile-time reactivity delivers buttery-smooth performance even on constrained platforms like 200,000 Brazilian point-of-sale terminals. - [31:54](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1914s) Operating as a compiler decouples framework capabilities from shipped bundle size, enabling built-in features such as scoped CSS, a11y compiler warnings, and off-main-thread CSS animations without penalizing unneeded code paths.
## Key takeaways - [00:06](https://www.youtube.com/watch?v=AdNJ3fydeao&t=6s) Electronic spreadsheets pioneered reactive programming through forward-referencing dependency graphs, allowing engines to recalculate only changed values rather than recomputing the whole sheet. - [04:08](https://www.youtube.com/watch?v=AdNJ3fydeao&t=248s) React popularized declarative component architecture, but continuously diffing virtual DOM trees and re-executing entire component bodies creates unnecessary runtime overhead for simple state changes. - [05:54](https://www.youtube.com/watch?v=AdNJ3fydeao&t=354s) Performance optimization APIs such as shouldComponentUpdate, React.PureComponent, and useMemo serve as abstraction leaks where developers must manually instruct the computer on what not to re-render. - [06:39](https://www.youtube.com/watch?v=AdNJ3fydeao&t=399s) Frameworks should function as tools for organizing thought at build time rather than runtime libraries running inside the client's browser. - [09:24](https://www.youtube.com/watch?v=AdNJ3fydeao&t=564s) Svelte 3 instruments native JavaScript variable assignments by injecting calls to invalidate, batching surgical DOM mutations at the end of the microtask loop. - [09:24](https://www.youtube.com/watch?v=AdNJ3fydeao&t=564s) For server-side rendering, Svelte compiles markup into raw string concatenation instead of instantiating component trees in memory, substantially reducing server overhead. - [13:40](https://www.youtube.com/watch?v=AdNJ3fydeao&t=820s) Svelte repurposes valid JavaScript labeled statements ($:) to declare derived state and side effects, topologically sorting evaluation order at compile time much like Observable notebooks. - [17:09](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1029s) Drawing a strict philosophical line between runtime reactivity magic (such as Vue's property accessors) and build-time compiler magic is an arbitrary distinction. - [19:35](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1175s) Time slicing and concurrent rendering improve responsiveness by breaking virtual DOM tasks into chunks, but they fail to resolve underlying rendering inefficiencies during heavy interactive workloads. - [22:15](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1335s) Reimplementing the virtual DOM in low-level languages like Rust compiled to WebAssembly (as in Dodrio) cannot bypass the architectural bottlenecks inherent to runtime diffing. - [25:00](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1500s) Resource constraints in the modern embedded web—ranging from Smart TVs to payment terminals—make lightweight compile-time approaches essential where traditional JavaScript runtimes falter. - [26:32](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1592s) Because Svelte parses the entire template at build time, it provides built-in accessibility linting and automatically scopes CSS while stripping unused selectors from output bundles. - [30:29](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1829s) Svelte compiles component transitions into native CSS keyframe animations that run off the browser's main thread, avoiding battery-draining JavaScript animation loops. - [31:54](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1914s) A compiler-first framework decouples feature breadth from bundle size, allowing rich animations and conveniences to exist in the framework without forcing every project to pay the bundle penalty. - [35:26](https://www.youtube.com/watch?v=AdNJ3fydeao&t=2126s) By mirroring basic HTML, CSS, and plain JavaScript, Svelte lowers the technical barrier to entry so non-engineers like product managers can directly inspect and edit component logic.
## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=AdNJ3fydeao&t=6s) From LANPAR and VisiCalc to Lotus 1-2-3
Rich Harris opens with what sounds like a grandiose tribute to the moon landing—fifty years ago, humanity entered a new era when two heroic explorers took a small step into a new world, sparking technological breakthroughs that transformed agriculture, medicine, business, and consumer products. But the punchline quickly follows: he is talking about electronic spreadsheets. In 1969, René Pardo and Remy Landau came together to create LANPAR Technologies. Aside from being a play on their names, LANPAR stood for "Language for Programming Arrays at Random," and it pioneered the feature most fundamental to modern spreadsheets: forward referencing, or what is known today as reactive programming.
To demonstrate, Harris shows a spreadsheet tracking his fruit purchasing habits. Columns B and C contain raw prices and quantities, while column D contains formulas whose values derive directly from other cells. Buying an extra cantaloupe causes the subtotal and total to update automatically. The spreadsheet maintains an internal dependency graph where cells connect as inputs and outputs. Adding another formula dynamically alters that graph so that existing cells branch into multiple outputs. In 1969, when computing power was scarce, this dependency graph was essential because calculating only what had changed was vastly more efficient than recalculating the entire sheet from scratch.
```mermaid flowchart TD accTitle: Spreadsheet Dependency Graph accDescr: Data flow from raw cell values to calculated totals in a spreadsheet subgraph Inputs["Inputs"] B["Price (Column B)"] C["Quantity (Column C)"] end subgraph Derived["Formulas"] D["Subtotal (Column D)"] T["Grand Total"] end B --> D C --> D D --> T ```
Yet LANPAR never became a household name; it was simply too far ahead of its time and faded into a computing footnote. When people think of the first electronic spreadsheet, they usually think of VisiCalc. Steve Jobs credited VisiCalc with driving the early commercial success of the Apple II, but VisiCalc took a much more primitive, naive approach without forward referencing. Whenever users edited a cell, the software forced recalculations cell by cell across the board, making it sluggish and clunky. Users tolerated it because they knew no better—until Lotus 1-2-3 arrived with proper forward referencing, unlocking massive performance and utility while relegating VisiCalc to irrelevance almost overnight.
[02:33](https://www.youtube.com/watch?v=AdNJ3fydeao&t=153s) What Is Reactive Programming?
Introducing himself as a graphics editor at *The New York Times*, Harris explains that his talk, "Rethinking Reactivity," is about applying the hard-won lessons of spreadsheet history to modern web software—aiming to build tools that are "a little bit less VisiCalc and a little bit more Lotus 1-2-3." Addressing the question of what reactive programming actually means, he borrows a definition shared the previous day by Michel Weststrate:
> “The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration.”
At its core, reactive programming is about data flow: tracking values as they travel through an application so that when an underlying input changes, the rest of the application automatically reacts. Turning to React, Harris acknowledges that it was a genuine miracle when released in 2013, introducing patterns that reshaped the entire web development community. Year after year, the React team has reliably solved problems developers did not even realize they had. Even so, Harris insists the community can do far better. Acknowledging the awkwardness of critiquing popular libraries—especially with a React core contributor, Brendan, sitting directly in the front row—he argues that candid criticism is vital for collective growth, reminding the audience that React's early advocates won over the community precisely by being fiercely critical of the existing frameworks of their own day.
[04:08](https://www.youtube.com/watch?v=AdNJ3fydeao&t=248s) How the Virtual DOM Works and Why React Isn't Reactive
React popularized the virtual DOM, and Harris breaks down step-by-step how a standard React component executes on state updates. Looking at a simple `App` component holding `count` and `name` state alongside click and input handlers, React regenerates a slice of virtual DOM whenever that local state changes. It is then React's responsibility to reconcile the previous tree with the new one:
```mermaid flowchart TD accTitle: React Virtual DOM Reconciliation Walkthrough accDescr: Step-by-step virtual DOM diffing process checking every element A["Check top div (unchanged)"] --> B["Check className 'app' (unchanged)"] B --> C["Check h1 child (unchanged)"] C --> D["Check h1 text content (unchanged)"] D --> E["Check input element & value (unchanged)"] E --> F["Check button element (unchanged)"] F --> G["Check button text ('4' to '5')"] G --> H["Apply DOM Mutation"] ```
- React inspects the top-level `<div>`; it remains a `<div>`, so it is kept. - It checks attributes; the `className` remains `"app"`, so it is kept. - It checks the children; an `<h1>` remains an `<h1>`, so it is kept. - It checks the text node inside the `<h1>`; it hasn't changed, so it is kept. - It checks the `<input>`; it is still an input and its value is identical, so it is kept. - It checks the `<button>`; it is still a button, but its inner text has changed from 4 to 5, so React finally writes that update to the real DOM.
Harris laments the sheer overhead required just to change a single digit: "All that work to change a 4 to a 5. As engineers, we should be offended." Yet the reconciliation walk is not even the most wasteful aspect. The deeper flaw is that the component function must execute repeatedly on every single state change, continuously re-declaring functions that close over local variables. Because React treats the component body as an opaque black box, it lacks any granular understanding of how data flows through the application. As John Lindquist pointed out, “React is a terrible name for React.js.”
[05:54](https://www.youtube.com/watch?v=AdNJ3fydeao&t=354s) Is the Virtual DOM Fast?
Harris tackles the persistent myth of virtual DOM performance. Is the virtual DOM fast? "No, it's not fast." Is it fast enough? For data visualization and complex animation, Harris argues categorically that it is not. But developers do not need to take his word for it; the React core team's own architectural additions prove the point. Tools like `shouldComponentUpdate`, `React.PureComponent`, `useMemo`, and `useCallback` exist precisely because the virtual DOM is not inherently fast enough:
> “These are all abstraction leaks that let you, the programmer, tell the computer that it doesn't need to worry about this subtree within your application—in other words, you're doing the computer's job for it.”
When a framework has to invent complex amortization strategies like Concurrent Mode to break up expensive rendering tasks into background slices, it is an unmistakable symptom that runtime diffing costs have become problematic.
[06:39](https://www.youtube.com/watch?v=AdNJ3fydeao&t=399s) Frameworks as Compilers and Svelte 3's Approach
Confronting this performance bottleneck while wanting the declarative convenience of React led Harris to reconsider what a framework actually is. He argues that a framework does not need to live inside the browser at runtime:
> “Frameworks are not tools for organizing your code; they are tools for organizing your mind.”
Embracing the idea that compilers are the new frameworks, Harris created Svelte. Svelte processes declarative components during the build step and compiles them down into surgical, imperative, low-level JavaScript that directly mutates the DOM without an intermediate runtime virtual DOM.
The critical challenge is change detection: how does an application know when something changed? - Traditional class-based React relies on `this.setState()`, which merges state and triggers a full subtree render. - Modern React relies on Hooks, invoking updater functions like `setCount()` paired to state variables. - Early versions of Svelte mirrored classical React with `this.set()`.
Harris explains that both `this.setState` and `this.set` suffer from being verbose and tying the component to `this`. Relying on `this` introduces awkward lexical constraints and unexpected ergonomics. JavaScript already has a native mechanism for signaling change: the assignment operator (`count += 1`). Vue recognized this early on by intercepting property assignments on `this` (`this.count += 1`), but it still required an enclosing component instance at runtime. Because Svelte is a compiler, it is not bound by normal runtime JavaScript constraints. With Svelte 3, reactivity is moved entirely out of API calls and directly into the language syntax itself.
[09:24](https://www.youtube.com/watch?v=AdNJ3fydeao&t=564s) How Svelte Works: Assignments, Invalidation, and SSR
Demonstrating a Svelte component, Rich Harris replaces React’s `useState` hooks with plain JavaScript assignments: `let name = 'world'` and `let count = 0`. Instead of invoking a setter function, updating the counter simply requires assigning directly to the variable with `count += 1`. Typing into an input field or clicking a button immediately updates the view. To answer how this is possible without a virtual DOM, Harris examines the code emitted by the Svelte compiler. The compiler leaves the original user code almost entirely intact; it simply instruments state changes by injecting calls to an internal `invalidate` function right after any assignment to a variable referenced inside the template markup. The job of `invalidate` is straightforward: it notifies the component that a value has changed and schedules a DOM update to batch at the end of the current microtask/event loop tick.
Harris streamlines the code even further by replacing manual event handlers with Svelte’s two-way `bind:` directive and inlining the button click handler, demonstrating that Svelte achieves the same interactive behavior with a fraction of the boilerplate. Because Svelte places JavaScript inside HTML rather than embedding HTML inside JavaScript via JSX, the compiler can target vastly different outputs based on operational needs. In the browser, it outputs a lightweight JavaScript class that manipulates the DOM directly. For server-side rendering (SSR), it compiles the template into plain string concatenation. Creating a serialized component tree in memory is unnecessary when the server can simply stitch strings together, making Svelte’s SSR mode orders of magnitude faster. Harris quips: “What this means is that if you do server-side rendering with Svelte, your AWS bills will be lower—tell your product managers.”
```mermaid flowchart TD accTitle: Svelte Update Lifecycle accDescr: Diagram showing how Svelte instruments assignments with invalidate to update the DOM at the end of the event loop.
subgraph CompileTime["Compile Time"] A["User Code: count += 1"] --> B["Svelte Compiler"] B --> C["Instrumented Output: invalidate('count', count += 1)"] end
subgraph Runtime["Runtime Event Loop"] C --> D["invalidate() records dirty state"] D --> E["Batch updates at end of microtask"] E --> F["Direct DOM Mutation"] end ```
- Consuming a Svelte component in a build pipeline is identical to importing any standard JavaScript module; a bundler plugin converts the `.svelte` file on the fly into an ES class. - Client-side initialization uses standard instantiation: `new App({ target: document.body })`. - Server-side execution exposes an optimized string-rendering API: `App.render()`.
---
[11:42](https://www.youtube.com/watch?v=AdNJ3fydeao&t=702s) Derived State: React's useMemo vs. Svelte's Dilemma
State in non-trivial applications rarely exists in isolation; components frequently contain derived values that depend directly on other pieces of state, much like formula cells in a spreadsheet. In React, this is handled naturally because the entire component function re-executes on every render. If a component has an array of todos and a boolean toggle to hide completed items, a derived variable like `const filtered = todos.filter(...)` recalculates automatically whenever the component renders, and the JSX maps over the resulting array. However, Harris points out that this default execution model has a serious flaw: if the parent component re-renders, the child recalculates its derived values unconditionally, even when none of their underlying dependencies have changed.
To solve this in React, developers reach for `useMemo`, wrapping the computation in a callback and providing an explicit dependency array such as `[todos, hideDone]`. React inspects the dependency values from the previous render, and if nothing changed, skips the calculation and returns the cached result. While this avoids wasted work, Harris stresses that it offloads mechanical bookkeeping onto developers: “That’s a bit more efficient, but it’s obviously more work for the developer—it’s more boilerplate for us.” Comparing the full React component with its Svelte equivalent, Svelte’s syntax is visibly leaner; Harris notes that across many components he has converted, React equivalents consistently demand around 40% more code. Yet, directly translating that component into Svelte reveals a fundamental problem: when clicking todos to toggle them, the UI refuses to update. Because Svelte runs its `<script>` block only once upon initialization, `const filtered` stays frozen forever, forcing the framework to find a new way to express reactive dependencies.
---
[13:40](https://www.youtube.com/watch?v=AdNJ3fydeao&t=820s) Topological Ordering and the Labeled Statement ($:)
To solve derived reactivity without re-running entire components, Harris looks outside standard UI frameworks to Mike Bostock, the creator of D3 and Observable. Observable notebooks differ radically from traditional top-to-bottom runtimes like Jupyter or RunKit by executing cells in topological order. If statement A depends on statement B, statement B is guaranteed to evaluate first regardless of where it appears in the source file, operating exactly like an electronic spreadsheet. Harris also cites an essay titled *What is reactive programming?* by Australian developer Paul Stovell, which imagines code anthropologists in the year 2051 looking back at modern JavaScript and wondering why updating `a = 10` failed to automatically update `b = a + 1`. In Stovell’s speculative future, developers use a dedicated “Destiny operator” (`b <= a + 1`) to permanently bind relationships into the language itself.
Inventing a new operator in JavaScript is impossible because non-standard syntax breaks parsers, linters, and editor tooling. Instead, the Svelte team co-opted an obscure, valid feature of JavaScript syntax that almost no one uses: labeled statements. By prefixing declarations with `$:` (such as `$: filtered =...`), Svelte binds the variable reactively. Harris jokes about repurposing this syntax: “Does anyone recognize this? This is a thing called a labeled statement, and it doesn't really do anything most of the time in JavaScript, so we on the Svelte team have co-opted it—we've made it our own.” He playfully adds that Svelte has become “the guy Kyle Simpson was trying to warn you about.” Reactive declarations can also be chained (`$: showing = filtered.length`), and Svelte automatically topologically sorts them at compile time, guaranteeing that `filtered` recalculates before `showing`. Furthermore, `$:` is not limited to variable assignments; developers can attach arbitrary statements or side effects, such as `$: console.log(filtered)`, creating an effortless tool for debugging state changes over time.
- In Observable notebooks and Svelte reactive declarations, execution order is determined strictly by dependency graphs rather than lexical line position. - Svelte compiles `$:` statements into compact conditional checks: if either `todos` or `hideDone` changes, the compiled component recalculates `filtered` and issues an `invalidate('filtered')` signal before calculating downstream dependents.
---
[17:09](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1029s) The "SvelteScript" Debate and Magic at Compile Time
Svelte’s reliance on labeled statements has sparked debate across the front-end community. Harris notes that critics often dismiss the syntax as the "bad kind of magic." He highlights a reaction from Evan You, the creator of Vue: “Evan You, the creator of Vue.js, said, 'Well, this isn't even JavaScript, this is technically SvelteScript.' And he's right—we are abusing the language for fun and profit.” However, Harris finds it ironic that Evan of all people would voice this critique, given that Vue popularized making JavaScript property assignments carry reactive side effects via runtime getters and setters. You’s critique hinges on distinguishing runtime browser magic from build-time compiler magic, a division Harris rejects as entirely arbitrary: “I think if you draw a line between those two things, then you're guilty of making the same mistake as people who used to say that templates and styles and JavaScript should be in separate files even though they relate to the same component.”
Harris shifts to performance comparisons, admitting to a mischievous habit: “Something I like to do when framework authors release benchmarks showing how fast their framework is, I add Svelte to it and then I tweet out the result—it is probably why I don't have many friends, but it's so worth it.” He displays a benchmark demonstrating Svelte running 35 times faster than React and 50 times faster than Vue. Yet, Harris readily concedes a point raised by Dan Abramov of the React team: synthetic benchmarks that pump hundreds of thousands of updates per second into a component are meaningless when human eyes consume screens refreshing at 60 Hertz. The true priority is perceived user experience, which leads directly to the core rationale behind React’s Concurrent Mode. Referencing Abramov’s influential JSConf Iceland talk, Harris opens a demo running an artificially throttled CPU where typing into an input field stutters visibly under standard synchronous rendering, setting the stage for how frameworks should tackle real-world responsiveness.
[19:35](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1175s) The Limits of Time Slicing vs. Svelte's Raw Speed
Rich Harris demonstrates how typical applications handle heavy loads on the main thread, contrasting common optimization patterns with Svelte's compiled architecture. When firing up a live "frustration meter" alongside an interactive data-heavy graph, unoptimized updates quickly choke the browser. Historically, developers resort to debouncing—waiting until the user stops typing to trigger an update. While debouncing unblocks the main thread and keeps the input field responsive, Harris notes it yields a poor user experience because the user receives zero real-time visual feedback while interacting.
React's concurrent mode (originally introduced as async mode or time slicing) attempts to offer the best of both worlds: the graph updates live, and if the workload becomes too intense, it slices the rendering tasks into smaller chunks and yields execution back to the main thread. This prevents total input freeze and keeps the frustration meter green. However, Harris reveals the catch: as the workload's complexity grows, the background graph lags visibly and becomes "chunky." He then switches over to the exact same application implemented in Svelte, where both the input and the underlying graphic update instantly and buttery-smooth without any perceptible delay or frame drops.
Addressing an audience suggestion about Inferno, Harris acknowledges it would likely outperform React, but emphasizes that Inferno still relies on a Virtual DOM mechanism and will ultimately encounter the same foundational bottlenecks. While time slicing is undeniably superior to vanilla React without it, Harris argues it treats the symptoms rather than the disease.
> “The best way to deliver a good user experience is to be extremely fast.” — Rich Harris
```mermaid flowchart TD accTitle: Strategies for Handling Heavy UI Updates accDescr: Diagram comparing Debouncing, Concurrent Mode, and Svelte compiled DOM updates. subgraph S1["Debouncing"] D1["User Input"] --> D2["Delay Execution"] D2 --> D3["Batch Run on Pause"] D3 --> D4["Zero Feedback While Typing"] end
subgraph S2["Concurrent / Async Mode"] C1["User Input"] --> C2["Chunk Work in Virtual DOM"] C2 --> C3["Yield to Main Thread"] C3 --> C4["Input Responsive, but Graph Lags"] end
subgraph S3["Svelte Direct Updates"] V1["User Input"] --> V2["Surgical DOM Mutations"] V2 --> V3["No Virtual DOM Overhead"] V3 --> V4["Instant Real-Time UI Updates"] end ```
[22:15](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1335s) The Internal Combustion Analogy and Dodrio's Rust/Wasm Benchmark
Harris draws an analogy to automotive engineering: the modern internal combustion engine (ICE) is an astonishing marvel of mechanical engineering, honed over decades through millions of dollars in research to squeeze out fractional improvements. Yet an ICE contains hundreds of moving parts and tops out at an energy efficiency of roughly 20% to 25%. When Tesla entered the market, they threw out the premise of fossil fuels entirely, using an electric motor with only two moving parts and an efficiency of 85%. In the web world, trying to optimize Virtual DOM diffing by slicing tasks across threads or cycles mirrors car companies pouring fortunes into squeezing marginal gains out of fundamentally inefficient engines.
Harris notes that moving code around never genuinely accelerates it. Slicing work into chunks merely changes perceived responsiveness, and past fads like offloading UI logic into Web Workers failed because shuttling data across thread boundaries is too costly. Even rewriting the Virtual DOM in low-level systems languages like Rust compiled to WebAssembly cannot escape structural architectural flaws. Citing a blog post by Nick Fitzgerald about Dodrio—a Rust-based Virtual DOM library compiling to Wasm that claimed "best-in-class performance"—Harris jokes about his competitive nature:
> “Now when you say best-in-class performance, it's like if you stand in front of the mirror and say Candyman five times, I will appear behind you.” — Rich Harris
Harris benchmarked Svelte against Dodrio. Upon discovering that Dodrio's original benchmark used `setTimeout`—meaning most runtime was spent idling on the browser's timer—Harris refactored it to use microtask promise resolution to measure true DOM mutation speeds. Svelte outperformed Dodrio by a substantial margin. While Harris remains enthusiastic about Rust and Wasm for heavy computational jobs, he maintains that applying a Virtual DOM architecture will never produce ultimate rendering speed. Borrowing a philosophy from Marie Kondo, he urges developers to speed up code by asking if their JavaScript "sparks joy," and throwing the unnecessary runtime away.
[25:00](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1500s) Real-World Performance: Point-of-Sale Terminals and the Embedded Web
Harris pushes back hard against critics who claim that obsessive performance optimization is merely an ivory-tower hobby detached from genuine engineering needs:
> “When people like me talk about performance, we are often accused of having our heads in the clouds, of not being concerned with the real-world impacts of our applications, and I find that so confusing: performance is the most real-world thing there is.” — Rich Harris
To demonstrate real-world impact, Harris highlights Stone, a financial services company in Brazil producing point-of-sale (POS) payment terminals. Stone initially attempted to build the device software using React, Vue, and a range of competing libraries. The devices were simply too underpowered, resulting in sluggish, unusable software. Stone rewrote the interface in Svelte, and today over 200,000 POS terminals run Svelte directly on the streets of Brazil.
A second case study is Moslab in Russia, which engineers software for low-resource environments like Smart TVs. Svelte offered them rapid developer productivity without demanding performance compromises. Moslab has since expanded Svelte's footprint into internal products such as smart-home automation dashboards. Harris underscores that the mobile web is no longer the new frontier; modern frontend engineering is expanding into embedded devices, Internet of Things (IoT), wearables, in-car dashboard infotainment systems, and Smart TVs. In these constrained environments, resource-heavy JavaScript-first runtimes inevitably fail.
- **Stone (Brazil):** 200,000 payment terminals powered by Svelte across Brazil after React and Vue proved too resource-intensive. - **Moslab (Russia):** Deploys Svelte onto Smart TVs and home automation control panels to overcome limited hardware profiles. - **The Embedded Web:** Wearables, IoT hardware, and automotive infotainment define the modern performance constraints where runtime-heavy frameworks cannot compete.
[26:32](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1592s) Built-in Accessibility Warnings and Scoped CSS
Harris turns his attention to architectural advantages beyond pure rendering speed, beginning with accessibility (a11y). Developers typically intend to build accessible software, but fall short because engineers without visual or motor impairments often overlook non-visual user experiences. Because Svelte functions as a compiler that understands the entire template, it can catch access issues before code ships. In a live code demonstration, Harris shows an `<img>` tag provided with an `src` attribute but no `alt` tag. Svelte immediately displays a compiler warning in the terminal and editor: `accessibility: <img> element should have an alt attribute`. Once the alt attribute is added, the warning vanishes.
> “It will let you write markup that isn't accessible, but it won't respect you for it.” — Rich Harris
Harris next tackles CSS. Asking the audience if anyone builds web applications without styles, he notes that most mainstream frameworks neglect styling entirely, leaving developers to piece together third-party CSS-in-JS libraries. Svelte treats components as supersets of HTML, allowing `<style>` blocks to live directly inside component files. Styles are automatically scoped at build time: a bare `p {... }` selector styles the component's paragraphs without leaking into child components or parent wrappers. Svelte generates a unique CSS class hash applied simultaneously to the compiled markup and the generated stylesheet. Furthermore, if a CSS selector in the `<style>` block matches no markup in the component, Svelte issues an unused CSS selector warning and automatically purges the dead styles from the production output.
[29:46](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1786s) Declarative Built-in Transitions
Harris demonstrates that animations and component transitions should not require sprawling external animation engines. By simply importing transition primitives from `svelte/transition` (such as `fly`), developers can attach declarative directives directly to elements in their template:
- Elements smoothly animate into and out of view when bound to state changes, rather than snapping abruptly into and out of the DOM. - Directives like `transition:fly="{{ y: 200 }}"` configure direction and distance via basic JavaScript object literals. - Svelte gracefully handles interruption: toggling the visibility variable mid-flight causes the animation to reverse seamlessly without jumping or resetting layout positions.
[30:29](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1829s) CSS-Driven Animations and Custom Transitions
Rich Harris explains that Svelte manages transitions by smoothly reversing them and restoring elements to their correct places—a task that is notoriously difficult to pull off cleanly in traditional JavaScript frameworks. Crucially, Svelte does not execute these animations through ongoing JavaScript runtime loops. Instead, when the component's state changes, Svelte computes a CSS animation and applies it directly to the target DOM element. Because modern browsers execute CSS animations completely off the main thread, this implementation strategy delivers significantly better runtime performance and is far more battery-friendly, particularly for mobile devices.
```mermaid flowchart TD accTitle: Svelte CSS Transition Pipeline accDescr: Flow showing how Svelte translates state changes into CSS animations that run off the main thread. subgraph SvelteJS["JavaScript Thread"] A["State Change"] --> B["Svelte calculates CSS animation"] B --> C["Apply keyframes/rules to DOM element"] end subgraph BrowserEngine["Off Main Thread"] C --> D["Browser Compositor executes animation"] D --> E["Smooth 60fps rendering without battery drain"] end ```
Harris demonstrates how flexible the system is by showing how developers can construct custom transitions. He walks through a custom `spin` transition function that accepts a DOM `node` alongside optional configuration arguments. The function returns an object containing a `css` method, which receives a normalized time parameter `t` ranging from `0` (completely off the screen) to `1` (completely on the screen) and returns a CSS string. Svelte compiles this dynamically generated CSS into native keyframe animations on the element:
```javascript // Conceptual structure of a Svelte transition function function spin(node, { duration = 400 }) { return { css: (t) => ` transform: scale(${t}) rotate(${t * 360}deg); opacity: ${t}; ` }; } ```
Harris shows how clean the template usage is by importing `spin` from `./spin.js` and applying directives directly to markup: `in:spin out:fade`. This architecture opens the door to non-standard easing equations and intricate visual effects while keeping the underlying execution fully offloaded to CSS.
- “Because CSS animations run off the main thread, this is more performant and more battery friendly particularly on mobile devices than if you're doing the animation inside JavaScript.” — Rich Harris - Custom transition functions take `(node, options)` and return an object with a `css(t)` method where `t` is a value from `0` to `1`. - Svelte can animate using complex easing curves that are not natively supported in vanilla CSS, while still packaging the final result as pure CSS.
---
[31:54](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1914s) Coordinated Lists and Decoupling Features from Bundle Size
To illustrate higher-level UI choreography, Harris presents a to-do list separated into two views: items that are still pending, and completed items below them. Without transitions, toggling a checkbox causes an item to abruptly vanish from one list and instantly appear in the other. Harris highlights that this jarring visual jump contradicts how objects behave in physical space, leaving users disoriented:
> “Our brains don't like it when things just disappear and reappear elsewhere on the screen. What we want is for these things to move gracefully to their new position; that helps us understand what's actually happening to the things inside the application.”
By adding Svelte crossfade transition directives to the list items, the completed tasks smoothly slide across the screen and settle into their new positions, all executed via hardware-accelerated CSS.
Most front-end libraries avoid baking in advanced animation engines because the JavaScript community is hyper-focused on bundle size. Framework landing pages routinely boast metrics like being a "3-kilobyte alternative to React." While shipping fewer bytes over the wire is undeniably good for end users, runtime libraries pay a steep penalty: adding built-in features directly increases the baseline bundle weight for every application.
Because Svelte operates strictly as a compiler, it breaks this trade-off completely. Unused framework capabilities—whether complex transition math, specialized SVG helpers, or two-way bindings—are simply omitted from the compiled output.
- “It means that we've decoupled feature set from file size and that lets us, the Svelte team, be far more expansive in the kinds of features that we consider worth including in the framework.” — Rich Harris - “Developers, as developers, we want all the features, but we just don't want to pay for the ones that we're not using, and what's good for developers is ultimately good for users.” — Rich Harris - Svelte applications bundle only the minimal operational code required to support the exact feature set authored in the source files.
---
[34:06](https://www.youtube.com/watch?v=AdNJ3fydeao&t=2046s) The Broader Ecosystem: Sapper, Svelte Native, and Svelte GL
Harris explains that while core Svelte operates as a low-level component framework capable of powering complex applications, building comprehensive web products requires high-level application machinery. To meet this need, the team maintains **Sapper**, an application framework companion to Svelte modeled on tools like Next.js and Gatsby for React. Sapper packages essential production features—file-system routing, automatic code splitting, and server-side rendering (SSR)—while producing dramatically smaller JavaScript bundles due to Svelte's compile-time design.
Harris also highlights other projects expanding across the wider ecosystem: - **Svelte Native:** A community-driven project built on top of NativeScript-Vue that allows developers to write mobile applications for iOS and Android using Svelte components. Harris notes it will likely become an official project in the future. - **Svelte GL:** An initiative Harris is eager to build, designed as a Svelte-centric counterpart to Three.js. Developers would declare a 3D scene graph using familiar Svelte component syntax, which the compiler would then transform directly into low-level WebGL draw calls without the abstraction overhead of traditional WebGL engines.
---
[35:26](https://www.youtube.com/watch?v=AdNJ3fydeao&t=2126s) Accessibility, Shared Ownership, and the Power of Spreadsheets
Returning to the broader theme of the presentation, Harris observes that spreadsheets remain one of the most successful reactive computing paradigms ever created because of their radical accessibility. He shares a personal story about his wife, who is not a programmer and has zero desire to become one after living with him for 15 years, yet routinely creates extraordinary value inside businesses using spreadsheets. Harris argues that web development tools should strive to match that level of intuitive approachability:
> “Wouldn't it be wonderful if the tools that we used to build the web were as accessible as spreadsheets are? And that is one of Svelte's overriding goals: is to make web development accessible without sacrificing power for power users.”
To show this accessibility in practice, Harris shares an anecdote from his friend Eliza at Spotify. While building a project with Svelte, her product manager was able to walk over, examine the code, and directly edit component markup and logic on the spot. Because Svelte components look and act like plain HTML, CSS, and basic JavaScript rather than dense, heavily abstracted framework code, they remove the intimidation barrier that usually keeps non-engineers from contributing. Harris concludes that when diverse people with varied disciplines and skill sets can crowd around a single laptop and work together on the same codebase, true breakthroughs occur, expressing his hope that Svelte will ultimately bring teams closer together.
## Notable quotes > [06:39](https://www.youtube.com/watch?v=AdNJ3fydeao&t=399s) Frameworks are not tools for organizing your code; they are tools for organizing your mind. — Rich Harris
> [19:35](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1175s) The best way to deliver a good user experience is to be extremely fast. — Rich Harris
> [31:54](https://www.youtube.com/watch?v=AdNJ3fydeao&t=1914s) Developers, as developers, we want all the features, but we just don't want to pay for the ones that we're not using, and what's good for developers is ultimately good for users. — Rich Harris
## Mentioned Apple II, Brendan, Dan Abramov, Dodrio, D3, Eliza, Evan You, Gatsby, Inferno, John Lindquist, Kyle Simpson, LANPAR, Lotus 1-2-3, Marie Kondo, Michel Weststrate, Mike Bostock, Moslab, NativeScript-Vue, Next.js, Nick Fitzgerald, Observable, Paul Stovell, React, Remy Landau, René Pardo, Rich Harris, Rust, Sapper, Spotify, Steve Jobs, Stone, Svelte, Svelte GL, Svelte Native, Tesla, The New York Times, Three.js, VisiCalc, Vue.js, WebAssembly
## Video description Modern JavaScript frameworks are all about reactivity. Change your application's state, and the view updates automatically. But there's a catch — tracking state changes at runtime adds overhead that eats into your bundle size and performance budgets. In this talk, we'll discover an alternative approach: moving reactivity into the language itself. Your apps have never been smaller or faster than they're about to become.
Slides: https://rethinking-reactivity.surge.sh/
YGLF 2019: Code Camp Blog - Rich Harris: https://www.israel.yglfconf.com/post/meet-the-speaker-rich-harris
[Source](https://www.youtube.com/watch?v=AdNJ3fydeao)