4 ms·

Svelte(https://svelte.technology/ https://svelte.technology/) is one similar idea. It’s a framework that compiles down to plain JS before being shipped out to b

Svelte(https://svelte.technology/ https://svelte.technology/) is one similar idea. It’s a framework that compiles down to plain JS before being shipped out to browsers. 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.

rich_harris 9y ago
Svelte author here. If you're using a bundler integration like rollup-plugin-svelte or svelte-loader (for webpack), those repeating lines of code are deduplicated across components. There's a bare minimum of repetition, and we're in the process of reducing it further. You'd be surprised at just how well it scales! 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.
- fron 9y ago
  Just wanted to say that I've been using svelte a bit at work to create widgets that our clients can embed on their websites, and I absolutely love it. Creating svelte components is super easy and consuming them is even easier. Thank you for having the vision, thank you for making it, and thank you for continuing to improve it.
hectorlorenzo 9y ago
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

Svelte author here. If you're using a bundler integration like rollup-plugin-svelte or svelte-loader (for webpack), those repeating lines of code are deduplicated across components. There's a bare minimum of repetition, and we're in the process of reducing it further. You'd be surprised at just how well it scales! 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.

fron 9y ago
Just wanted to say that I've been using svelte a bit at work to create widgets that our clients can embed on their websites, and I absolutely love it. Creating svelte components is super easy and consuming them is even easier. Thank you for having the vision, thank you for making it, and thank you for continuing to improve it.

hectorlorenzo 9y ago

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.