4 ms·

The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they o

The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering. The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components. React and the Virtual DOM solved this problem, and that's why web apps today use a lot of components. So until Svelte can demonstrate fitness and speed comparable to React on large apps, it just looks like Yet Another JS Framework.

mvindahl 10y ago
Haven't studied the SvelteJS documentation but as far as I can reason there is nothing in their idea that prevents them from shielding the DOM behind a lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed if they don't shield the DOM somehow. It's the #1 bottleneck, after all.
- boubiyeah 10y ago
  Check the generated code in the REPL, it's straight DOM manipulations.
  - mvindahl 10y ago
    Hope they have good reasons, then..
- JDDunn9 10y ago
  The virtual DOM isn't a replacement for the DOM, it's just a string diffing algorithm. It is only needed because of React's "render everywhere" approach, which is a tradeoff sacrificing efficiency for simplicity. If you don't re-render the entire page any time the model changes, you don't need a virtual DOM.
  - mercer 10y ago
    I'd say your mostly right with the one caveat that a virtual DOM also helps out with batching changes to the DOM, but I suppose there are other ways to make that happen.
boubiyeah 10y ago
I don't know, it could work. React almost does the same thing actually, except it batches updates occuring in a single event handler, but otherwise, there is nothing optimized about it, except the reconciliation. A limited string template makes reconciliation a non problem.
rich_harris 10y ago
We'll publish some benchmarks soon showing how much better Svelte's performance is than React's. There's a lot of misconceptions around virtual DOM diffing.
- theasker 10y ago
  Changing a single cell in a table with hundreds of rows and a dozen columns would be a good test.

mvindahl 10y ago

Haven't studied the SvelteJS documentation but as far as I can reason there is nothing in their idea that prevents them from shielding the DOM behind a lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed if they don't shield the DOM somehow. It's the #1 bottleneck, after all.

boubiyeah 10y ago
Check the generated code in the REPL, it's straight DOM manipulations.
- mvindahl 10y ago
  Hope they have good reasons, then..
JDDunn9 10y ago
The virtual DOM isn't a replacement for the DOM, it's just a string diffing algorithm. It is only needed because of React's "render everywhere" approach, which is a tradeoff sacrificing efficiency for simplicity. If you don't re-render the entire page any time the model changes, you don't need a virtual DOM.
- mercer 10y ago
  I'd say your mostly right with the one caveat that a virtual DOM also helps out with batching changes to the DOM, but I suppose there are other ways to make that happen.

boubiyeah 10y ago

I don't know, it could work. React almost does the same thing actually, except it batches updates occuring in a single event handler, but otherwise, there is nothing optimized about it, except the reconciliation. A limited string template makes reconciliation a non problem.

rich_harris 10y ago

We'll publish some benchmarks soon showing how much better Svelte's performance is than React's. There's a lot of misconceptions around virtual DOM diffing.

theasker 10y ago
Changing a single cell in a table with hundreds of rows and a dozen columns would be a good test.