Svelte 3: Rethinking Reactivity

From the tutorial:<p>&gt; Svelte is giving us a warning:<p>&gt; A11y: &lt;img&gt; element should have an alt attribute<p>&gt; When building web apps, it&#x27;s important to make sure that they&#x27;re accessible to the broadest possible userbase, including people with (for example) impaired vision or motion, or people without powerful hardware or good internet connections. Accessibility (shortened to a11y) isn&#x27;t always easy to get right, but Svelte will help by warning you if you write inaccessible markup.<p>Thank you! We accessibility advocates have wanted this kind of checking to be built into mainstream development tools for years. I hope Svelte becomes popular for this reason alone.

I&#x27;m really impressed that the release announcement starts by explaining what Svelte is. It&#x27;s a little thing, but it&#x27;s appreciated.

Congratulations on the launch, Rich! It&#x27;s looking like we&#x27;re really starting to approach the form and function of what &quot;a language to build the web&quot; ought to be.<p>One small question about some of the pragmatic choices in Svelte 3: What was the decision process behind choosing to smuggle the new reactive features under a &quot;standard&quot; JavaScript skin? ($:, export let, etc.) Is it just to avoid needing to rewrite all existing JS tooling — parsing, syntax highlighting, linting — or is there something deeper going on?

&quot;The magical disappearing UI framework&quot; was a much better tagline than &quot;Cybernetically enhanced web apps&quot; …

Nice handling of reactivity - I think this should already be in language as well.<p>I&#x27;m not sure I like this single components approach and embedding JS in HTML.<p>The problem with this is that it&#x27;s too frameworkish.<p>The big benefit of JSX&#x2F;React rendering is that it&#x27;s composable and declarative (as it&#x27;s just functions), but it&#x27;s also simple to get - render just returns wanted structure, given the state and you can use simple assert to verify that.<p>Solutions like angular&#x2F;vue&#x2F;svelte rely on custom template parsing which IMO sucks, because it&#x27;s hard to extend&#x2F;test without specific template compilers. JSX in contrast is embracing language.<p>I think that render functions written like in react and data reactivity is the simplest approach to describe application. Seems like VueJS with JSX is closest to this right now.<p>It would be cool to keep similar API but maybe use compiling to have smaller bundle&#x2F;older browsers support&#x2F;different platform support etc.<p>To be clear by similar API I mean just pure JSX components, where you plugin reactive data, that could be tested without any frameworks and without rendering. This is the simplest way, yet nobody build it yet - MobX + pure React components is close to this (problem is that still rendering is done by React, so rendering isn&#x27;t most performant - depends on components hierarchy) - with compilation&#x2F;integration you could make it more performant, but I would keep declararive nature and simplicity of JSX.

I&#x27;m currently working on a giant React frontend codebase and it&#x27;s baffling how slow certain simple things are for our users. Yes it makes it easier for us to reason about, but performance should be able to scale without hacks.<p>Svelte seems to show a lot of promise, but I have a few things that I&#x27;m not 100% on.<p>1. How are the higher level abstractions for Svelte? Any framework can be easy for simple applications, but how easy will this be to reason about as we get to larger applications? React deals with this through a semi-functional mindset. What does Svelte offer?<p>2. Is there any plans for facilitating incremental rollouts? Changing your application to an entire new framework is not always worth it, and is greatly difficult. I could imagine Svelte being incredibly useful for large-scale, performant applications. However, unless it can be incrementally rolled out, then I can&#x27;t see how the biggest players will be able to utilise the power of Svelte.<p>I&#x27;d love to see the game changed in web frameworks, and I love the idea of using compilers where possible. If anyone could answer these queries, I&#x27;d be very much grateful.

How easy would it be to &quot;hook into&quot; Svelte&#x27;s compilation pipeline so that users can create their own optimisations? I ask that because I work in a huge codebase with many layers of component abstraction and performance is starting to take a hit. For example, most of these components:<p><pre><code> &lt;Box flex flexAlignItems=&quot;center&quot; marginTop={5}&gt; &lt;Heading level={2} caret=&quot;down&quot;&gt; Profile info &lt;&#x2F;Heading&gt; &lt;Media&gt; &lt;Avatar id={avatarId} size=&quot;small&quot; lazy &#x2F;&gt; &lt;Media.Block marginLeft={2}&gt; {displayName} &lt;&#x2F;Media.Block&gt; &lt;&#x2F;Media&gt; &lt;&#x2F;Box&gt; </code></pre> would be compiled into their simplest forms:<p><pre><code> &lt;div className=&quot;flex flex-align-items-center margin-top-5&quot;&gt; &lt;h2&gt; Profile info &lt;span className=&quot;caret-down&quot; &#x2F;&gt; &lt;&#x2F;h2&gt; &lt;div className=&quot;media&quot;&gt; &lt;img src=&quot;https:&#x2F;&#x2F;www.cdn.com&#x2F;avatar&#x2F;{avatarId}&quot; className=&quot;avatar-small&quot; lazyload=&quot;on&quot; &#x2F;&gt; &lt;div className=&quot;media-block margin-left-2&quot;&gt; {displayName} &lt;&#x2F;div&gt; &lt;&#x2F;div&gt; &lt;&#x2F;div&gt; </code></pre> I believe the technique is called &quot;component folding&quot;. I tried to do it with Babel but it&#x27;s a real pain.<p>Thanks for putting so much work into exploring alternative ways of making the web faster, because, at the moment, it still requires an immense effort.

I recommend everyone to take a look at the talk linked in the article. It gives you a good overview of how awesome svelte is and how easy it is to use.<p>I chose vue over react for simplicity and I&#x27;ll be damned if I don&#x27;t choose svelte over vue for the same reason and more after this talk.

Immer.js (a library to work on data structures, not a framework) uses a similar concept, using Proxies.<p>The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively.<p>It&#x27;s very interesting, and a reversal of the traditional &quot;functional core, imperative shell&quot; architecture.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;immerjs&#x2F;immer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;immerjs&#x2F;immer</a>

<i>Hooks have some intriguing properties, but they also involve some unnatural code and create unnecessary work for the garbage collector.</i><p>Thank you for pointing this out. To me hooks were always a way to solve problems in React that wouldn&#x27;t be there if it weren&#x27;t for React. They help, but come at a cost which barely anybody seems to talk about.<p><i>We really want to add first-class TypeScript support.</i><p>Yes, please!

I&#x27;m excited about the updated Svelte. Although it is currently nowhere near being in the top handful of frameworks by adoption, it has some very forward ideas. Most prominently, look at the first main value proposition on its website:<p>“Write less code”<p>Svelte has a ways to go to catch up with the leaders on popularity and future breadth, but it is focused on the right problem: reducing the cost&#x2F;size&#x2F;effort of making things.

Since you are reading here Rich Harris; while I really admire your solutions, one weak point with Svelte seems to be a clear unit testing solution, or at least docs last I looked. I also noticed this with Ractive, and feel it weakens these in the eyes of many businesses considering these tools.<p>I know it&#x27;s a solved&#x2F;solvable problem but it feels like better docs and samples in quick start guides would help.

This is roughly how QML works too right?<p>&gt; Cybernetically enhanced web apps<p>That is pretty terrible! It seems to me that the main think that distinguishes Svelt is that more work is done at compile-time? Why not a slogan that says just that?<p>&quot;Compile-time optimised reactivity.&quot; or &quot;Low overhead reactive web apps&quot; or something like that. Cybernetics is nonsense waffle.<p>Anyway good luck! Seems like a better approach than shadow DOM etc.

One area where the virtual DOM seems to be important is for rich text editors, where the VDOM can basically take the input, diff it using an immutable structure, then render it to properly structured HTML.<p>An example use case where this would be valuable: a user hightlights text, bolds it, then highlights it again plus some more text, and bolds it. A naive approach would have: &lt;b&gt;&lt;b&gt;This text is bolded&lt;&#x2F;b&gt; plus I bolded this&lt;&#x2F;b&gt; when what you want would simply be: &lt;b&gt;This text is bolded plus I bolded this&lt;&#x2F;b&gt;<p>Libraries like DraftJS and SlateJS use immutable data structures to parse the input&#x2F;formatting in the VDOM and reconcile them into &quot;blocks&quot; (basically javascript objects containing the formatting) that deduplicate formatting.<p>The talk below on DraftJS is pretty good.<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=feUYwoLhE_4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=feUYwoLhE_4</a><p>What&#x27;s the recommended way to handle a rich text application in Svelte? Is there anything like the above for Svelte?

I tried Svelte&#x2F;Sapper a few weeks ago. It is definitely not the new framework of the month that come and go.<p>I love it. I cannot believe how fast the app load on both first and second time visits. 100% in lighthouse.<p>I think Svelte is the way to go! I hope the community will accelerate and eventually catch up with React and Vue!

Mithril.js has been doing plain javascript variables for years :) Basically, React&#x27;s decision to use setState is an overoptimization. Mithril (and flutter, interestingly) opts for global redraws, greatly reduces end-user code complexity while still being fast for most all cases.

Their interactive tutorial with sandboxes is really impressive. That&#x27;s a great onramp into actual usage. It might also be cool to have a good way to &quot;eject&quot; the sandbox into a functional local build.

I went through the tutorial. It’s quite confusing. I’ve been doing front-end SPA apps for about 10 years now.<p>The framework that has blown me away with it’s simplicity and elegance but power is snabbdom.<p>It’s small, it’s fast, it’s modular. You can use it with jsx, you can use it with webcomponents if you want. You can type it with typescript. Animations check, custom module extensions, check.<p>As the recent experiments in wasm has shown, you can make extremely fast vdom diffing that is memory allocator friendly.<p>So my bet in the future is this. Vdom will be here for a while. It’s simple, elegant and we’ll figure out how to make it faster with newer tricks.<p>More non web UI frameworks will use similar approaches. React Native is paving wave here but I can see desktop apps and terminal apps embrace the same concepts too.<p>View as function of state is a very powerful paradigm. State being a simple dumb old nested object. No magic tricks.<p>Svelte feels too magical. Vue has same issues. It’s hard to reason with magic when you hit edge cases.<p>You ideally want a simple model in your head so you can build really complex apps by connecting simple axioms of logic.

This is really cool. That said, I noticed that it cites performance vs vdom as a selling point. Something I&#x27;ve been wondering lately is how big of an issue is UI performance for most web apps really? So many of the little apps and prototypes I develop aren&#x27;t hurting for performance. It seems to me the industry made a huge leap from JQuery&#x2F;Backbone&#x2F;etc to reactive&#x2F;vdom. But declarative UIs and virtual doms don&#x27;t solve exactly the same problem; they just go well together. Are there any frameworks out there that provide a JSX&#x2F;VueSFC&#x2F;hyperscript development experience, without adding the complexity of a virtual dom implementation? I think developing UIs in a declarative fashion is a big win, but having a virtual dom seems like it should be treated more like an optimization to me.

I&#x27;m wondering how good Typescript support is. Can I use Typescript in the component script?

&gt; this.set is almost identical to the this.setState method used in classical (pre-hooks) React<p>It&#x27;s an amazing reflection on the velocity of the web &amp; JS ecosystem that React APIs prior to hooks, which were shipped all of 3 months ago, can be sincerely referred to now as &#x27;classical&#x27; :-)

I&#x27;m very intrigued by Svelte and I really hope that it will succeed. In that sense I also hope that this is the last major version, i.e. no more breaking changes. That would be fantastic!<p>Does anyone here have a major, non trivial app in production that&#x27;s built on Svelte?

Hey Rich if you&#x27;re still lurking - I really like the Tutorial layout (even on mobile!) and how that all works. Is this something you built yourself or is there a re-usable component that I can use?

Interesting to see performance difference comparing to 2 version: <a href="https:&#x2F;&#x2F;github.com&#x2F;krausest&#x2F;js-framework-benchmark&#x2F;issues&#x2F;553" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;krausest&#x2F;js-framework-benchmark&#x2F;issues&#x2F;55...</a>

Svelte looks amazing. Some questions that occurred to me:<p>- Does it work with TypeScript?<p>- How does it relate to other reactive frameworks, such as RXJS? Does it make sense to use them together or does the Svelte compiler invalidate the benefits of them?<p>- Does it work with any existing components?

- Is speed comparison going to include Angular with Ivy renderer enabled (and probably OnPush change detection strategy enabled)? It&#x27;s also AOT rendering stuff that doesn&#x27;t use virtual DOM.<p>- There is a lot of static code analyzing tools, like linters, that work with separate JS&#x2F;CSS&#x2F;HTML files. Does Svelte have to adapt all those tools in order to make them properly work with a single file component (.svelte file)?<p>- I believe enabling first-class TypeScipt support would bring more sanity to Svelte-based development.

Odd that they don&#x27;t mention Angular amongst the component-based frameworks, as what they&#x27;re describing sounds very similar to Angular&#x27;s compiler and change-detection system.

I haven&#x27;t used it yet but I really like the idea of Svelte, just how I really enjoy using Preact over React for certain projects.<p>One question about version 3. I was wondering if they addressed the issue of how a Svelte code base can grow in size larger[1] than a Preact based codebase the bigger it gets.<p>[1] <a href="https:&#x2F;&#x2F;medium.com&#x2F;@chrisdaviesgeek&#x2F;tiny-js-frameworks-preact-and-svelte-d2388e2f8994" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@chrisdaviesgeek&#x2F;tiny-js-frameworks-preac...</a>

This is a great talk. During its discussion, I&#x27;ve seen some misconceptions about what Concurrent React is. I hope this thread will be helpful to someone who&#x27;s wondering why we&#x27;re continuing work on that approach: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov&#x2F;status&#x2F;1120971795425832961" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;dan_abramov&#x2F;status&#x2F;1120971795425832961</a>

Yes, the release I&#x27;ve been waiting for. I started to dabble with Svelte v2 right before coming of v3 was announced.<p>Are web component going to happen with v3? I am trying to combine Python server app with Svelte enhanced HTML and got good results on v2. I noticed they are marked as todo: <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;docs#Custom_element_API" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;docs#Custom_element_API</a>

Would you consider adding a way to set tag names in a component dynamically? I’ve found that to be incredibly useful in React, when you want to encapsulate some behavior but use it in different semantic contexts across an app.<p>Or is it possible already somehow? I tried to use<p><pre><code> &lt;svelte:component this={“h1”} ... </code></pre> but it doesn’t appear to support strings, just Svelte components?

Amazing. I was working on a mortgage calculation app with graphs and dependencies upon dependencies as calculations depended on other calculations. It seems Svelt would have been so much better to use than React in this case and I&#x27;m seriously going to use it going forward. Great work.

Is the frustration meter shown in the talk video part of that original benchmark? Or is it something we could run on top of any page? I had a search around, but didn&#x27;t find anything.

Congratulations on the release, Rich!<p>Minor suggestion: it should be easier to find how to get started (read install) for people trying to give Svelte a try. I had already played a bit with Svelte before but wanted to try v3 and the only thing I could find about how to install it was in <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;blog&#x2F;the-easiest-way-to-get-started" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;blog&#x2F;the-easiest-way-to-get-started</a>.

Very cool. Would love to try this. Anything that pushes things into compilation has immediate appeal, and this thing is clearly explained.

What I think is really interesting is that the Virtual DOM was touted as the better abstraction when React came out (in comparison to Angular 1&#x27;s dirty checking).<p>I think Svelte is doing a lot of things right (simple code, computing CSS animations, accessibility built in, focusing on a compiler versus a full on framework) and I can&#x27;t wait until Sapper is updated to dig in.

Looks great. I&#x27;m looking forwars to experiment with it. I enjoy that you have taken some of the &quot;it&#x27;s just js&quot; approach from React, some of the reactivity from Vue&#x2F;Mobx and the good parts of AngularJS (bindings where it makes sense). I am very curious!

The style of the talk was a bit overly confident to my taste, almost presumptuous.<p>But the idea of replacing a framework with a compiler blew my mind, so thank you.<p>And subverting the labeled statement is a wonderful hack. The kind that sticks.<p>I’m very impressed overall even if a bit scared from the “bad kind of magic” cited.

&gt;&gt; Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you&#x27;re able to write ambitious applications with excellent performance characteristics.<p>The best and self-defining para from article

I was giving a chance to Svelte when it was upgrading to version 2 and releasing this compilation thing but it failed badly during a project that I was building due to some bugs of Svelte had with transpiling. Should I give it another chance?

reminds me a bit of a very old project called FlapJax: <a href="https:&#x2F;&#x2F;www.flapjax-lang.org&#x2F;tutorial&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.flapjax-lang.org&#x2F;tutorial&#x2F;</a><p>Elm is a compile to JS language with a small footprint (it does still use a virtual-dom though). It would be nice to see a size comparison of the two. <a href="https:&#x2F;&#x2F;elm-lang.org&#x2F;blog&#x2F;small-assets-without-the-headache" rel="nofollow">https:&#x2F;&#x2F;elm-lang.org&#x2F;blog&#x2F;small-assets-without-the-headache</a>

In case you&#x27;re reading this, Rich, thank you for choosing the term &quot;compiler&quot; and not &quot;transpiler&quot; when describing what Svelte is!

Very happy for this. I wrote a Firefox extension with Svelte v1, and will take this release of Svelte v3 as an opportunity to refactor my extension.<p>Thank you, contributors!

Are there any write-ups about the internals of Svelte? I would be especially interested in how state changes are converted to concrete DOM updates.

So basically mostly the same thing MobX does in React and Vue does out of the box?<p>That&#x27;s not a bad thing - that&#x27;s the &quot;good&quot; kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.

For the sake of an example, let&#x27;s stop &quot;pure, simple&quot; hello world with `let x = 1;`.<p>Instead, please put some real async stuffs, how to manage state, how to put state into many small components.<p>Examples, not just documentation matters.

Looking at the talk, how is this different from markojs?

So, how about a React-to-imperative compiler?

Is there a DevTools which allows us to view the tree of components and manipulate it, like Vue does? Is there a script tag mode so it can replace jquery?

&gt; Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM.<p>So, Svelte is compiled into web assembly? If not, given the emitted imperative code is less efficient than emitted web assembly and the emitted imperative code is less concise than the original declarative code, then what would be the advantage of an imperative translation of the declarative Javascript code compared to emitted web assembly or the original?