Looks great. I'm looking forwars to experiment with it. I enjoy that you have taken some of the "it's just js" approach from React, some of the reactivity from Vue/Mobx and the good parts of AngularJS (bindings where it makes sense). I am very curious!
Svelte 3: Rethinking Reactivity
121–130 of 186 posts
Re: Svelte 3: Rethinking Reactivity
#122Re: Svelte 3: Rethinking Reactivity
#123One 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. 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: This text is bolded plus I bolded this w…
An important feature of a good framework is to be able to break out when needed to do normal JS, so I imagine you’d do that and grab a regular editor component.
Re: Svelte 3: Rethinking Reactivity
#124Since 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. I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.
I admire Rich Harris' work as well. 4 years ago I was picking my first SPA framework. Narrowed it down to Ractive and Vue. Picked ractive, it had a beautiful documentation and tutorial. Still have an app in production based on ractive. But author abandoned it. Then vue 2 took off. I didn't have a choice but switch. Recently I started playing with Svelte/Sapper again. I like it a bit better than vue for some reason an…
I still use ractive for production apps today, and have legacy ractive apps that are from 2013’ish running great
Re: Svelte 3: Rethinking Reactivity
#125Mithril.js has been doing plain javascript variables for years :) Basically, React'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.
Totally agree.
Multiple frameworks have done this for many years, but nobody will listen as everyone is interested in the next new, shiny thing.
I do like Svelte in its latest incarnation though, especially when it integrates with Sapper.
Re: Svelte 3: Rethinking Reactivity
#126Mithril.js has been doing plain javascript variables for years :) Basically, React'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.
Flutter does its own painting. It's different, and closer to a game engine than what React is doing. That results in different tradeoffs.
Re: Svelte 3: Rethinking Reactivity
#127What 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's dirty checking). 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't wait until Sapper is updated to dig in.
> 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's dirty checking).
I think the VDOM seemed to offer a maxima and people thought it might be a global one (even though in hindsight it seems like a silly proposition). Angular certainly hasn't exactly delivered on performance in any meaningful way that I know of, at least, so maybe the VDOM, even if it was a local maxima, was still the better of the two?
As a basis for a durable design and a way to move forward, clearly we have a better way, though, but that can only be illustrated by a project actually doing well at it.
Re: Svelte 3: Rethinking Reactivity
#128Earlier quoted context omitted.
Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.
Allow me to try and convince you of its importance :) https://svelte.dev/blog/write-less-code
What are your opinions of Go where it is the general idea to only have 1 way to do something, and make that way the best way?
Re: Svelte 3: Rethinking Reactivity
#129What 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's dirty checking). 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't wait until Sapper is updated to dig in.
> 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's dirty checking). I think the VDOM seemed to offer a maxima and people thought it might be a global one (even though in hindsight it seems like a silly proposition). Angular certainly hasn't exactly delivered on performance in any meaningful way that I know of, at least, so…
I think VDOM made sense at the time because DOM elements come with so much overhead that dirty checking thousands of elements (in Angular 1's case) does not scale well.
I think the issue became that the VDOM creates some overhead that making very simple DOM changes can avoid altogether. From what I understand, Svelte sidesteps the VDOM and outputs the smallest amount of code to achieve the desired level of reactivity which might be the better abstraction.
Re: Svelte 3: Rethinking Reactivity
#130Earlier quoted context omitted.
It's really not a little thing. The number of blog posts that talk about why version N+1 of X is great, assuming I know what X or version N did is stupid, and I am immediately churned out.
This is basically v1 though, so it's a bit different.
Uh, it's v3... People are using both 1 and 2 in prod...