21–30 of 293 posts
(I wonder what happened to Featherstitch.)
[1]: https://lwn.net/Articles/354861/
It's a common pattern that you have a list of items of work to be done which in principle you could know ahead of time, but in practice it's better to track at runtime (even though it means the computer ends up repeating the same calculation again and again).
The most important line: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Declarative, state-driven UI development is a valuable abstraction. I really hope readers take this to heart, rather than the article title becoming a new meme.
The most important line: > It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Declarative, state-driven UI development is a valuable abstraction. I really hope readers take this to heart, rather than the article title becoming a new meme.
> it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in
The abstraction is valuable, but its cost need not be so high. I do wish they'd elaborate on what Svelte does differently though, or link to another post which elaborates.
While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html
I thought most of the JS world know that virtual DOM is slow and ahead-of-time direct binding is the way forward at this point - why do something expensive inside your users browser when it should be done on the developer's machine? Svelte will either take over, or React will get patched to start doing this in a major new release. It could go either way at this point.
Earlier quoted context omitted.
> This article avoids the fact that declarative programming has proven to be more pleasant for most people. No it doesn't. Second-to-last paragraph: "It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is…
You're right! Seems like I skimmed over that part. My point still stands, though.
There's many good reasons to use React - mainly the React ecosystem - but simplicity is not one of them.
The blog ends with > But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?
The blog ends with > But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?
Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like that eat into your frame budget and tax the garbage collector.
Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.