Thread by @Rich_Harris

My talk from @YGLF_IL, 'Rethinking Reactivity', went online yesterday — . You probably don't have time to watch a 35 minute video though, so I'm going to pull out a few key slides into a quick tweet thread:

@YGLF_IL The talk is about how we can fuse ancient wisdom with modern techniques in such a way that front end development survives the coming tectonic shift — the embedded web.

@YGLF_IL "What is reactivity?" You know how when you edit a spreadsheet cell, related cells automatically update? It doesn't need to redraw the entire spreadsheet; changes propagate through a dependency graph resulting in targeted, granular updates. That's reactivity.

@YGLF_IL Don't be confused by the name — reactivity doesn't mean 'what React does'. React is a truly wonderful thing, but this talk is about how we might do even better, by discarding old assumptions and choosing a different set of constraints.

@YGLF_IL For example, our assumptions about what frameworks are. We tend to think of frameworks in terms of code, but I prefer to think of them in terms of the *concepts* they articulate. Given that, why not move the work out of the browser and into your build step?

@YGLF_IL Aside from various performance benefits, this lets us design a better developer experience. For example, we can trigger updates by simply assigning to component state variables — moving reactivity out of the API and into the language.

@YGLF_IL Here's what that looks like in practice — extremely compact, readable code. More on why that matters: svelte.dev/blog/write-les…

@YGLF_IL By putting JS in our HTML instead of HTML in our JS, we gain new powers. For example, if we compile in SSR mode, the output is completely different — we're just concatenating strings. It's incredibly performant, relative to wrangling component trees.

@YGLF_IL To be truly reactive, we need a way to derive reactive values from reactive local state. @observablehq showed us how well this can work, by conservatively running code in *topological order*.

@YGLF_IL @observablehq In Svelte, that looks like this — add `$:` in front of a statement or declaration to make it reactive. The Svelte compiler turns that into the kind of imperative update code that browsers are extremely good at executing.

@YGLF_IL @observablehq "But wait!", you say. "That's not JavaScript!". And that's true. JS isn't an ideal language for authoring declarative components, which is why frameworks have a proud tradition of abusing the language to bend it to our will.

@YGLF_IL @observablehq Vue's proxies and React's hooks are great examples — both completely violate your expectations of what a given line of code should do, but in a way that makes perfect sense once you understand it. This is just taking that principle a step further.

@YGLF_IL @observablehq Like everyone else, I watched @dan_abramov’s talk at JSConf Iceland last year () with my jaw on the floor. In future React's ‘time slicing’ will improve UX by preventing React from hogging the main thread.

@YGLF_IL @observablehq @dan_abramov But it doesn't speed up your code; in fact it delays your updates! A better UX might be to update immediately while still not hogging the main thread... just by being, like, really fast.

@YGLF_IL @observablehq @dan_abramov An analogy I like to think about is the internal combustion engine. Car makers have invested $$$ making ICEs more efficient, and they are marvels of engineering. But if we abandon their underlying premise — hydrocarbons — we can improve efficiency (and simplicity) greatly.

@YGLF_IL @observablehq @dan_abramov Improving performance isn't some ivory tower concern. It directly impacts what we're able to build. Mobile isn't the new frontier any more — the web of the future will also run on wearables, smart home control screens, and so on.

@YGLF_IL @observablehq @dan_abramov (Sidebar: don't expect LARGE_TECH_CO to care about these use cases. When they build UIs for their IoT devices, they're not slinging divs, they're hiring native app developers.)

@YGLF_IL @observablehq @dan_abramov But Svelte is about a lot more than perf — it has a ton of other features, e.g. a11y guidance. I've found I've got a lot better at a11y just by having my tooling keep it in my attention. Tools have a responsibility and an opportunity to help us get it right.

@YGLF_IL @observablehq @dan_abramov In conclusion: spreadsheets are neat. And not just because they teach us the value of reactivity, but also because anyone can use them. Wouldn't it be great if the tools we use to build the web were equally accessible, without sacrificing power? That's Svelte's north star.