11–20 of 116 posts
> Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages "Only".
That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.
items = items.filter(i => i !== item);
$$invalidate('items', items = items.filter(i => i !== item));
The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?
(thanks to whoever bothered to do this writeup).
https://github.com/gactjs/gact/blob/master/docs/long-live-th...
EDIT: if anyone has proof this is not true, I'd love to hear their counterargument.
The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?
Also, Svelte has keys like React which can help out. See this example in the tutorial for that: https://svelte.dev/tutorial/keyed-each-blocks
The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?
The TL;DR is that Svelte overpromises. They can't possibly write code for every transformation combination as code size would grow exponentially (I'm not completely sure, but I think predicting transforms would involve the halting problem). (thanks to whoever bothered to do this writeup). https://github.com/gactjs/gact/blob/master/docs/long-live-th... EDIT: if anyone has proof this is not true, I'd love to hear their…
For example, even changing a single value in a big list requires the whole VDOM to be recreated, but should be very efficient in Svelte as it can directly modify the specific DOM node. On the other hand, as pointed out in the article you linked, if changing a value affects a large part of the DOM, but does not actually change that much, then value-comparing frameworks (e.g. Svelte) probably do a lot of unnecessary work compared to VDOM-based approaches (intuitively I would think that this case does not occur that often).
"Theres a new JS framework, it must be Tuesday".
The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?
To actually answer your question, no, $$invalidate doesn't mean all the DOM nodes get recreated. You can see that in this example: https://svelte.dev/repl/d3898004792c467d8eacefb054d8263a?ver... Also, Svelte has keys like React which can help out. See this example in the tutorial for that: https://svelte.dev/tutorial/keyed-each-blocks
> Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages "Only".
That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.
Fwiw though, even a 250MB node_modules would pale in comparison to my Rust version lol.
The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?
The TL;DR is that Svelte overpromises. They can't possibly write code for every transformation combination as code size would grow exponentially (I'm not completely sure, but I think predicting transforms would involve the halting problem). (thanks to whoever bothered to do this writeup). https://github.com/gactjs/gact/blob/master/docs/long-live-th... EDIT: if anyone has proof this is not true, I'd love to hear their…
Here is the repl of the code you posted.
https://svelte.dev/repl/1a70f2f38af94ed7ac8bd032feea52f9?ver...
A Svelte component is mutable & manages the related DOM elements which are also mutable. In the conditional, the tree is re-rendered.
Would React's diff algorithm be able to recycle the `
surgical
` DOM Node? How much more performant would detaching & reattaching `surgical
` be than recreating `surgical
`?Assuming the `
surgical
` can be recycled, the use case having the largest effect is a large inner tree being wrapped/unwrapped; where the inner tree would simply be moved instead of recreated.In Svelte, this can be optimized by using a subcomponent, as seen in the repl example. You can examine the compiled js.