21–30 of 116 posts
This looks much more germane to the Web than the other frameworks du jour. Will be interesting to see how it develops, but this was a pretty interesting look at how it works.
Ins't /Svelte/ the framework du jour? :)
Earlier quoted context omitted.
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…
I guess whether a structural comparison (VDOM) or a value comparison (Svelte) is more efficient really depends on the concrete use-case. 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 p…
Changing branches in a component is extremely common in code I write (very large business application with lots of rules).
Another important optimization is caching and re-using DOM nodes. With a vdom, you know exactly which properties and attributes differ from the default node. To reuse a node you need only update these properties to their new values or restore their original values. Without that tracking, it would be computationally cheaper to just create a new node.
One important example of this is our use of flyweight scroller patterns in lists. The content of the sub-tree changes, but most of the sub-components stay the same, so a vdom could keep most of the dom nodes around.
I've been building something with Svelte 3 for about 6 months now. - As should be clear in the article, it's very easy to pick up. In the first couple of weeks I got compiler errors, and kept having to look at how props and binding worked in the tutorial, but now I just make components without having to really think about Svelte. - TS support is on the way (yaay) - I'd like to know more about server-side rendering on…
If you pass generate: 'ssr' to the compile function https://svelte.dev/docs#svelte_compile you get JS that can be used to generate static HTML in a Lambda or anywhere else
Earlier quoted context omitted.
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…
> Each second Svelte will completely destroy the tree from the previous second, and completely rebuild the tree for this second 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 `…
I may be wrong, but I believe hyperapp recycles both the physical DOM node and the attached vdom node together (IIRC, they mark reused vdom nodes as "recycled" instead of directly comparing objects so they don't have to construct as many new vdom objects).
Preact kinda cheats here because they diff against the DOM directly.
Earlier quoted context omitted.
That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.
I've never heard it described like that but you're right. Interesting counter point.
Our ondemand cloud build servers download the code, restore nuget packages and download node modules. Most of the build time is spent downloading. Compiling generally takes an order of magnitude less time compared to those 2 steps.
This especially effects scenarios where end-to-end testing can only be done in a staging environment due to complexity of the product.
Earlier quoted context omitted.
I've never heard it described like that but you're right. Interesting counter point.
Even though these are compile/build time requirements, their size ends up slowing down CI/CD process. Our ondemand cloud build servers download the code, restore nuget packages and download node modules. Most of the build time is spent downloading. Compiling generally takes an order of magnitude less time compared to those 2 steps. This especially effects scenarios where end-to-end testing can only be done in a stagi…
I've been building something with Svelte 3 for about 6 months now. - As should be clear in the article, it's very easy to pick up. In the first couple of weeks I got compiler errors, and kept having to look at how props and binding worked in the tutorial, but now I just make components without having to really think about Svelte. - TS support is on the way (yaay) - I'd like to know more about server-side rendering on…
In fact the ideal way to use Sapper is without express/polka.
Earlier quoted context omitted.
That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.
It can matter though; fwiw. I love Rust, but my "node_modules" in Rust is absolutely huge. Not a problem on Desktop, but because I am full-time Rust these days my next laptops have to have lots of storage. Gone are the days where I can have a small SSD in my laptop. Fwiw though, even a 250MB node_modules would pale in comparison to my Rust version lol.
Why does Rust need a node_modules folder?
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…
> 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.