3 ms·

Some of these concerns were already mentioned in HN when Svelte itself got discussed (https://news.ycombinator.com/item?id=13069841 https://news.ycombinator.com

Some of these concerns were already mentioned in HN when Svelte itself got discussed (https://news.ycombinator.com/item?id=13069841 https://news.ycombinator.com/item?id=13069841), and the suggested solutions for problem #2 were (kudos to user callumlocke): - Bundling and gzipping several Svelte components together might compress well – a lot of their size comes from repetitive substrings like `.parentNode.removeChild` and `.setAttribute` etc. - Once downloaded, the Svelte approach would probably be faster than React (at both rendering and updating) and would use less memory (no virtual DOM, no diffing, just fast granular updates). - The self-contained nature of Svelte components makes it easier to treat them as atomic downloads and use them as needed. For example, you could get to a working UI extremely fast, and then download more components for below-the-fold or other pages in the background. This could work well with HTTP/2.

rich_harris 9y ago
According to js-framework-benchmark (http://www.stefankrause.net/wp/?p=431 http://www.stefankrause.net/wp/?p=431) it doesn't just use much less memory than React, it uses less memory than any other framework, because we don't have the overhead of a virtual DOM. And yes, it's significantly faster. I answered the deduplication point in another reply to the parent, but you make a great point about code-splitting. If you're using a convention runtime framework it doesn't matter how aggressively you code-split — your smallest chunk will be at least as large as your framework. Self-contained components solve that problem.
- hectorlorenzo 9y ago
  That is fantastic, thanks for the clarification. The problem with calling self-contained components on demand is more of a mindset one: we've grown too used to compiling everything into one single file and calling it a day.
krptos 9y ago
Thanks for sharing! That's a lot of good news. Yet, I find it unsettling, that there's always going to be a minimal(after compressing/gzipping) amount of repeating code for every component. >The self-contained nature of Svelte components makes it easier to treat them as atomic downloads and use them as needed. For example, you could get to a working UI extremely fast, and then download more components for below-the-fold or other pages in the background. This could work well with HTTP/2. This is a huge win though - if I can load the first component extremely fast with no extra code.

rich_harris 9y ago

According to js-framework-benchmark (http://www.stefankrause.net/wp/?p=431 http://www.stefankrause.net/wp/?p=431) it doesn't just use much less memory than React, it uses less memory than any other framework, because we don't have the overhead of a virtual DOM. And yes, it's significantly faster. I answered the deduplication point in another reply to the parent, but you make a great point about code-splitting. If you're using a convention runtime framework it doesn't matter how aggressively you code-split — your smallest chunk will be at least as large as your framework. Self-contained components solve that problem.

hectorlorenzo 9y ago
That is fantastic, thanks for the clarification. The problem with calling self-contained components on demand is more of a mindset one: we've grown too used to compiling everything into one single file and calling it a day.

krptos 9y ago

Thanks for sharing! That's a lot of good news. Yet, I find it unsettling, that there's always going to be a minimal(after compressing/gzipping) amount of repeating code for every component. >The self-contained nature of Svelte components makes it easier to treat them as atomic downloads and use them as needed. For example, you could get to a working UI extremely fast, and then download more components for below-the-fold or other pages in the background. This could work well with HTTP/2. This is a huge win though - if I can load the first component extremely fast with no extra code.