6 ms·

You mean this Sierpinski demo? http://svelte-sierpinski.surge.sh/ http://svelte-sierpinski.surge.sh/ Ok, I'll level with you — that's not actually doing the sa

You mean this Sierpinski demo? http://svelte-sierpinski.surge.sh/ http://svelte-sierpinski.surge.sh/ Ok, I'll level with you — that's not actually doing the same thing as the Fiber version. But that's it's basically impossible to accidentally slow down your Svelte app in the same way as the Fiber demo depends on. Fiber doesn't really speed things up so much as it prevents bad code slowing things down. The innovation isn't templates (though these aren't your grandad's templates), it's compiling those templates to lean, memory-efficient JS code that doesn't depend on virtual DOM reconciliation or anything like that.

mlsarecmg 9y ago
The whole point is the artificial slowdown. Taking it out makes it meaningless, it prints a few blue bubbles. Scheduling is and always will be the biggest bottleneck. It is that kind of innovation that keeps react relative. As for a lean dom representation, i have never seen or heard of memory related problems regarding v-dom. And won't byte-code make it leaner in any case? React-compiled is already being tested.
- vanderZwan 9y ago
  "lean" is not limited to memory though - walking down the vdom reconciliation tree can incur get some pretty large overheads in terms of nested JS calls, just to decide that only a few buttons have to change. PureComponents and things like that are meant to help with this, but it still can take quite a bit of engineering effort to get this right. Mind you, I don't actually know if Svelte avoids this problem, but a statement like "doesn't depend on virtual DOM reconciliation or anything like that" kind of implies that it defaults to less work.