Browser inconsistencies are much less of an issue than they used to be. There are only a couple of places (e.g. listening for both 'input' and 'change' events on <input type='range'>, to satisfy IE and everyone else) where we need to accommodate differences.
Thank you for having the vision, thank you for making it, and thank you for continuing to improve it.
- 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.
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.
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.
There’s a couple of concerns though:
#1
How are we going to manage browser inconsistencies? We are very much better than what we were when jQuery came out. Yet we aren’t 100% there either. Browser inconsistencies, still do exist and runtime frameworks try to deal with it.
#2
I’ll take Svelte as an example. Say, a component written in Svelte is 2 lines long. The compiled JS file of that component is around 200 lines long (verified). Out of these 200 lines of code, almost a hundred lines are repeating units that occur in every component file.
By the time my app reaches a hundred components, this extra 100 lines gets multiplied by 100 times. This bloat is exactly what we want to avoid with runtime frameworks.
So, let’s think of the simplest solution.
Why not ship these repeating units of code as one module/set/block of code, that gets reused in different places? But wait, isn’t that block of code is what we call “Runtime Frameworks” ?
I still think compile-time frameworks are the best bet we’ve got. Would be helpful if somebody can throw light on these aspects though.