Rich Harris - Rethinking reactivity

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 [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.

May not be exactly what you are looking for, but take a look at [LINK] if you haven't seen already. and this [VIDEO]

I haven't seen any, but as a relatively early proponent of Vue(as in: I was there when v2 came out), I found Svelte even easier to get into than Vue. Anyway Rich Harris' presentation is a good starting point: [VIDEO]

It's a shame that the site's down. Until then, you can (and I heartily recommend doing so) watch the "Rethinking reactivity" video here: [VIDEO]

tl;dr watch this fantastic intro to svelte talk by it's creator: [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

Rich Harris' excellent talk Rethinking Reactivity has an interesting section where he compares a React Concurrent Mode demo to Svelte: [VIDEO]

I've been using Svelte since inception, and you're 100% right, there's been a significant uptick in user base over the last 6 mos. Basically since Rich did his Rethinking Reactivity talk at YGLF back in April.[1] [1] [VIDEO]

Rich Harris - Rethinking Reactivity Talk about Svelte v3 and the (possible) future of frontend frameworks Video: [VIDEO] HN discussion regarding Svelte 3: [LINK]

Highly recommend this talk [VIDEO] Rich Harris is an excellent speaker and it's worth seeing how Svelte approaches some things

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 [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

This is a good talk on the matter from the creator of Svelte himself, if you're interested: [VIDEO] Basically, it boils down to moving from tracking the DOM state in a VirtualDOM to tracking what DOM updates can happen at the compile stage and then just doing those exact updates to the DOM.

I believe that VisiCalc was the first to ship a functional spreadsheet. I remember watching RichHarris’s “Rich Harris - Rethinking reactivity” video introducing Svelte 3, and he discussed an earlier academic spreadsheet concept. [VIDEO] I used the following “terminal” spreadsheets VisiCalc on a Radio Shack Model III Microsoft MultiPlan on MS-DOS Lotus 1-2-3 on MS-DOS

I was drawn to Svelte by the performance/bundle size but I fell in love with how simple it is to write components and share data between them. Each component is just HTML/CSS/JS in a single file, sort of like Vue but cleaner. If you're curious I recommend either the "rethinking reactivity" talk from the author: [VIDEO] or the tutorial: [LINK] Both are great!

Ooh, if you liked what you saw of Svelte, you might like these videos that do a great job explaining some of its benefits: [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.

i also asked this on twitter so just putting some replies here: - Doug Engelbart [LINK] - Twilio [LINK] - Stripe - "7 lines of code" - Netlify - [LINK] - Heroku - [LINK] and git push heroku master - Cloudflare - [LINK] - Node ( [LINK] ) and Deno ( [LINK] ) - Firebase (reportedly) - [LINK] smaller companies/less impactful pitches that i still like - Redux [LINK] - Stackblitz [LINK] - Comm [LINK] - Mongodb [LINK] - Let's Encrypt [LINK] - Figwheel-Clojurescript [LINK] - Svelte [VIDEO]

> 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) [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).

This talk from Rich Harris should answer most of your Qs: Rethinking reactivity [VIDEO] He goes over the history of spreadsheets, reactive programming, and dunks on react.

The talk, Rethinking Reactivity by Rich Harris[0] is an amazing talk which talks about how spreadsheets were the OG reactivity software. Highly recommended. 0: [VIDEO]

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. [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.

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: [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