Rich Harris - Rethinking reactivity

tl;dr watch this fantastic intro to svelte talk by it's creator: [this video] , it covers some of the growing pains of React that svelte addresses. While it might look like the frontend is going around in circles, there are major & minor differences between the technologies, and they have each introduced novel (to JS at least) things... Off the top of my head (this timeline might not be right but it's how I went through it at least): - Backbone got you away from jquery spaghetti, helped you actually manage your data & models. Often paired with Marionette to handle views (if you squint this is the precursor to components) and bring some order in that part of the app. - Angular bundles backbone's data handling (services), marionette's orderly view separation (views, directives), but they made a fatal mistake in the apply/digest cycle and maybe encouraging a bit too much complexity. Angular is everything bundled together, with consistent usage/documentation/semantics, a familiar programming pattern (MVC), and a large corporate sponsor in Google it caught on like wildfire. - Knockout sees Angular's MVC, laments it's complexity and focuses on MVVM -- simple binding of a model and a relatively simple reactive-where-necessary controller - React comes along and suggests an even simpler world where the only first class citizen is components and everything else comes separate (this isn't necessarily new, there is an article out there comparing it to COM subsystems for windows). React is alm

> Does it solve the problem of only redrawing the required minimum (beside the normal VDOM approach)? Yes, in fact I think it's actually pretty hard _not_ to redraw the bare minimum LOL. If you want to know more about Svelte (even if you're not looking to develop with it) I HIGHLY recommend listening to this presentation called "Rethinking reactivity" by Rich Harris (the creator) [this video] > But does it solve the problem of growing state which never gets GC'd when components which used to use it are gone? I think the answer to the question is yes. Although the problem I'm speaking mostly about state management is the source of truth problem. Svelte provides a global store to store data, and data stored on local components are just _variables_ (no useState or hooks or anything complicated) where the Svelte compiler handles everything. Something else I'm really eyeing right now is SolidJS which takes a very similar approach to Svelte (compiler instead of library) for frontend development but provides an API that's very familiar to React developers so there's not much of a learning curve (although Svelte has a very easy learning curve too).

I don't think anyone is going to sell you on something else, you seem very ingrained in the React ecosystem. More dollars doesn't equate to "better product" down the road. Angular came and is still a part of Google. Would anyone starting a new project use it over something like VueJS or React today? Probably not. Right? So that sort of tosses your argument out the window. I don't do JavaScript professionally anymore, but I've worked with jQuery, BackboneJS, lots of AngularJS, some Elm, some VueJS, and some React, but being the curious person that I am, in search of greener pastures, I checked out Svelte, by first watching Rich Harris' video [this video] on "Thinking Reactivity", then seeing the benchmarks: [link] , and watching Rich and Dan Abramov spar a bit over their challenges. From an outsider with no skin in the JS game, it is clear that Svelte seems far superior now and into the future... 1. it is a compiler (it's like comparing C/C++ to Python) 2. the joy of out-of-the-box animations that use the GPU in CSS (reminds me of the joy of using jQuery for the first time w/ it's OOB animations) 3. you can drop in any other JS lib (doesn't have to be in a particular JS framework ecosystem) and have it inter-op! This is huge! It's because it's literally like writing vanilla JS 4. no need to learn some new syntax like JSX (not a huge fan) Just take a peek. If you don't like Svelte, so be it, but at least you know what it is that you don't like rather than turning a blind eye because

Ooh, if you liked what you saw of Svelte, you might like these videos that do a great job explaining some of its benefits: [this video] and [link] SvelteKit is very new and I haven't had a chance to use it yet, but my own framework was directly inspired by it. SvelteKit does a lot and looks great — fantastic developer experience, deploys to lots of types of services, SSR/SSG/client-side routing support, etc. And it seems like a great thing for Svelte to have as a default way for developers to start making Svelte components. Personally, I'm going to wait till SvelteKit a bit more mature before I dig in, but I'm guessing I'll end up rewriting my framework on top of SvelteKit at some point.

Svelte is awesome. Svelte 5's runes are especially powerful because they let reactivity escape the component boundary. The same reactive model works everywhere, whether you're updating the DOM or building plain application logic. Rich Harris makes the point that React isn't actually reactive: "React doesn’t have any understanding of the values running through your app. It is not Reactive." Rich Harris - Rethinking reactivity: [this video] >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. He starts with spreadsheets as the archetypal reactive system. Defines reactivity as values automatically updating according to dependency relationships. Contrasts that with React's model of rerunning component functions and diffing virtual DOM trees. Argues that React "doesn't understand the values flowing through your application" and therefore isn't reactive in the traditional sense. Virtual DOM is pure overhead: [link] >But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. React tracks component renders; reactive systems track data dependencies. React doe

My view on this is that complexity, like energy, can only really be converted from one form into another. Normally the distinction is between runtime complexity and cognitive complexity — the result of hand-optimised imperative code. In other words, the classic trade-off between developer experience and user experience. Svelte's claim is that converting it into build time complexity is in fact the only sensible thing to do. It doesn't really matter how much complexity is involved in `npm run build` if it means that DX and UX are no longer in tension. But to answer your point about SVG, Svelte has to obey the same fundamental constraints as any other code, so you will eventually hit performance issues (though you may enjoy this demo [this video] ). One avenue I'm currently exploring is whether the same declarative/compiled model can be used as a wrapper around WebGL APIs, though it's very early days.

There is nothing in React I'd regard as "terse". Perhaps slightly more terse than the mountain of boilerplate it required previously, but that's as far as I'd go. [this video] We really should accept that all of the following are ABSTRACTION LEAKS and not inherent benefits to web development at large: • shouldComponentUpdate • React.PureComponent • useMemo • useCallback • Concurrent mode They exist solely because React's underlying model is insufficient and we, the developers, are being made to do the computer's job with all this optimization boilerplate. The VDOM is dying. Let it die. It's long past time to move on. Any further React development in the existing foundation is just continuing to build upon sand.