3 ms·

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 de

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.

recursive 5y ago
Declarative state-driven UI is great, but personally, I really prefer the way e.g. knockout does it over react. It uses observables and publish/subscribe to issue updates to DOM elements directly where they're needed. You may not like knockout, but it shows how virtual DOM isn't a requirement for declarative state-driven UI.
WillDaSilva 5y ago
They note right after that: > 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.
- slumdev 5y ago
  The front page of their website proclaims Svelte to be "Cybernetically enhanced web apps", whatever that means. The "Rethinking" post gives a little more detail: > 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. https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity Seems like a great idea, if it can gain the critical mass required and build a community of people developing code for it.
wruza 5y ago
Declarative, state-driven UI development is a valuable abstraction. Which browsers do not support natively for decades and entire markets of ecosystems grow to work around that stupidest fact. Browsers could detect, batch and “reconcile” (whatever that means) the changes to the js runtime with much less runtime and devtime overhead than it is done in js by manual state tracking and updates.

recursive 5y ago

Declarative state-driven UI is great, but personally, I really prefer the way e.g. knockout does it over react. It uses observables and publish/subscribe to issue updates to DOM elements directly where they're needed. You may not like knockout, but it shows how virtual DOM isn't a requirement for declarative state-driven UI.

WillDaSilva 5y ago

They note right after that: > 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.

slumdev 5y ago
The front page of their website proclaims Svelte to be "Cybernetically enhanced web apps", whatever that means. The "Rethinking" post gives a little more detail: > 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. https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity Seems like a great idea, if it can gain the critical mass required and build a community of people developing code for it.

wruza 5y ago

Declarative, state-driven UI development is a valuable abstraction. Which browsers do not support natively for decades and entire markets of ecosystems grow to work around that stupidest fact. Browsers could detect, batch and “reconcile” (whatever that means) the changes to the js runtime with much less runtime and devtime overhead than it is done in js by manual state tracking and updates.