Good point. I tested the demos and found the output (compiled down to ES5 and minified) is around 2-3KB for the minimal demos, and 9KB for the complex SVG clock demo.
The equivalent JSX output for that clock demo is about 1KB. So yes, I would guess that apps with many components would end up bigger (in total JS bundle size) than equivalent React apps.
Possible counterarguments:
- 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.
Storing state in Dom and reading from it could be dangerous. It's very easy to force layouts when you don't need. Frameworks like react and preact essentially do this. Abstract updating the view in a performant manner. Preact is 3kb. Magnitudes smaller than React.
I don't think it stores state on the DOM and reads from it. Pretty sure it just stores state in an object, and it updates the DOM granularly when that state changes. (That said, I did notice a bit of DOM traversal (node.parentNode...), which doesn't count as reading state from the DOM, but does rely on the structure of the DOM not having been altered by someone else since the last render – not sure why it needs to do this.)
The equivalent JSX output for that clock demo is about 1KB. So yes, I would guess that apps with many components would end up bigger (in total JS bundle size) than equivalent React apps.
Possible counterarguments:
- 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.