2 ms·

https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html Preact diffs against the real dom and

by hajile 7y ago

https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity. InfernoJS is massively faster than Svelte or Preact (the benchmark author had to do some rather convoluted re-writes of vanillaJS over the years to keep ahead) and it uses a virtual DOM, but has a few optimizations that React doesn't have or can't use due to its external API. stdweb is the real thing to keep your eye on as it seems to show that WASM can be every fast. They still haven't gotten the vanilla benchmark up to the same speed. https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html React's Fibers do some cool batching behind the scenes which means that large updates (especially constant ones like animations) don't have large negative impacts on user interaction. I doubt this would be possible without a vdom or something very similar to track all changes before deciding batches and update priority. Also, remember that vdoms have gotten a lot more efficient too. Newer ones can do things like re-use existing sub-trees or recycle vdom objects (they can also recycle the associated real DOM nodes too). Preventing all that extra garbage goes a huge way toward keeping those vdoms efficient. As to svelte in particular, you aren't "just using an equals". It actually compiles behind the scenes into a completely different set of reactive code. This gets at my biggest issue with such frameworks. Their abstractions aren't free. I have to learn their proprietary syntax and markup. I then have to learn how their compiler works behind the scenes when its time to debug the code I wrote. When I compile a React-style component into ES7 and run it in the brower, I have to deal with webpack for imports and I have to understand that JSX is really just JS functions. Otherwise, what I wrote is what I'll see. https://cdnjs.cloudflare.com/ajax/libs/preact/8.5.2/preact.min.js https://cdnjs.cloudflare.com/ajax/libs/preact/8.5.2/preact.m...

arxpoetica 7y ago
This statement makes no sense: > I have to learn their proprietary syntax and markup. One of Svelte's raison d'etre is to "use the language" and err on less proprietary syntax / api / markup. Of the big three (not including Svelte), Svelte uses far less proprietary syntax, boilerplate, and API coverage. It errs on using as much native JS, CSS, and HTML as possible.
- hajile 7y ago
  React has one and only one syntactic conceit which is JSX. Truth be told, that is based on a subset of the now deprecated e4x standard. Let's look at Svelte's special syntax going over the docs. Everything mentioned here is NOT part of either the HTML or JS spec. * Uppercase HTML is special (I really don't understand this one as this seems like the perfect opportunity to go all-in on web components) * Interpolation using curly braces * magical $$props object * custom if..else..end syntax * multiple variants of the custom loop syntax * custom await, promise, and handler syntax * custom HTML escape syntax * custom debugger syntax * custom element directive syntax * tons of stuff using the element directive syntax (especially events and data binding) * 4 non-standard pseudo-DOM events * magical <slot> (lowercase) HTML element * magical <svelte> (lowercase) HTML element * magical $: syntax for binding updates That's a ton of magic and doesn't include all the magical code generated to wire everything together. That wouldn't be important except that you can't really avoid it. In React, I can just step over library calls, but since there's no Svelte library, I have to step through the spaghetti it creates from my code (spaghetti because efficient machine-generated code is always spaghetti).
dsissitka 7y ago
> https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- hajile 7y ago
  Comparing average numbers in that chart, Preact is 22% faster than React, Svelte is 12.6% faster than Preact and Inferno is 14.5% faster than Svelte. (note: Preact 10.1 is out and this uses 10.0) Vanilla JS 1.04 (5.8% faster than Inferno) Inferno JS 1.10 (14.5% faster than Svelte) Svelte JS 1.26 (12.6% faster than Preact) Preact JS 1.42 (22% faster than React) Total Size isn't that different either. That's an 11% payload difference between Inferno and Svelte and a less than 5% difference with Preact and Svelte. This isn't surprising since Preact is about 9kb unzipped (less than 4k zipped) and Inferno is about 21kb unzipped (less than 9k zipped). Vanilla JS 144kb Inferno JS 163kb Svelte JS 146kb Preact JS 153kb Maximum memory difference between Svelte and Inferno is negligible too at only 9%. I'd argue that memory usage for any of these will be dwarfed by actual data and the DOM itself. Preact memory usage is interesting as it uses more than Inferno despite not having to diff against a vdom. Vanilla JS 3.3mb Inferno JS 4.8mb Svelte JS 4.4mb Preact JS 7.5mb Startup time (parse to first load) is also completely unimportant with Svelte at about 1.2ms faster than Inferno, but 1ms slower than Preact (which even beats out the fastest vanillaJS version). Vanilla JS 20.3ms Inferno JS 21.6ms Svelte JS 20.4ms Preact JS 19.4ms Even the pessimistic responsiveness isn't very different with svelte being about 8% faster than Preact or Inferno. Vanilla JS 1882ms Inferno JS 2033ms Svelte JS 1883ms Preact JS 2031ms Inferno and Preact both have access to the wide support of the React ecosystem and tooling. Inferno is faster overall while not being particularly worse in any single area and better in others compared to Svelte. Why would I want to choose Svelte?
  - mcbits 7y ago
    Your total size numbers are almost entirely dominated by Bootstrap and a font, which are the same for all the tests (and not something that would be used on a site where payload size matters). Svelte's JS output, gzipped, is about 40% smaller than Preact and 65% smaller than Inferno. Assuming those ratios hold up for larger apps, that would be one reason to consider Svelte.

by hajile 7y ago

arxpoetica 7y ago

This statement makes no sense: > I have to learn their proprietary syntax and markup. One of Svelte's raison d'etre is to "use the language" and err on less proprietary syntax / api / markup. Of the big three (not including Svelte), Svelte uses far less proprietary syntax, boilerplate, and API coverage. It errs on using as much native JS, CSS, and HTML as possible.

hajile 7y ago
React has one and only one syntactic conceit which is JSX. Truth be told, that is based on a subset of the now deprecated e4x standard. Let's look at Svelte's special syntax going over the docs. Everything mentioned here is NOT part of either the HTML or JS spec. * Uppercase HTML is special (I really don't understand this one as this seems like the perfect opportunity to go all-in on web components) * Interpolation using curly braces * magical $$props object * custom if..else..end syntax * multiple variants of the custom loop syntax * custom await, promise, and handler syntax * custom HTML escape syntax * custom debugger syntax * custom element directive syntax * tons of stuff using the element directive syntax (especially events and data binding) * 4 non-standard pseudo-DOM events * magical <slot> (lowercase) HTML element * magical <svelte> (lowercase) HTML element * magical $: syntax for binding updates That's a ton of magic and doesn't include all the magical code generated to wire everything together. That wouldn't be important except that you can't really avoid it. In React, I can just step over library calls, but since there's no Svelte library, I have to step through the spaghetti it creates from my code (spaghetti because efficient machine-generated code is always spaghetti).

dsissitka 7y ago

> https://stefankrause.net/js-frameworks-benchmark8/table.html https://stefankrause.net/js-frameworks-benchmark8/table.html The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's. https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

hajile 7y ago
Comparing average numbers in that chart, Preact is 22% faster than React, Svelte is 12.6% faster than Preact and Inferno is 14.5% faster than Svelte. (note: Preact 10.1 is out and this uses 10.0) Vanilla JS 1.04 (5.8% faster than Inferno) Inferno JS 1.10 (14.5% faster than Svelte) Svelte JS 1.26 (12.6% faster than Preact) Preact JS 1.42 (22% faster than React) Total Size isn't that different either. That's an 11% payload difference between Inferno and Svelte and a less than 5% difference with Preact and Svelte. This isn't surprising since Preact is about 9kb unzipped (less than 4k zipped) and Inferno is about 21kb unzipped (less than 9k zipped). Vanilla JS 144kb Inferno JS 163kb Svelte JS 146kb Preact JS 153kb Maximum memory difference between Svelte and Inferno is negligible too at only 9%. I'd argue that memory usage for any of these will be dwarfed by actual data and the DOM itself. Preact memory usage is interesting as it uses more than Inferno despite not having to diff against a vdom. Vanilla JS 3.3mb Inferno JS 4.8mb Svelte JS 4.4mb Preact JS 7.5mb Startup time (parse to first load) is also completely unimportant with Svelte at about 1.2ms faster than Inferno, but 1ms slower than Preact (which even beats out the fastest vanillaJS version). Vanilla JS 20.3ms Inferno JS 21.6ms Svelte JS 20.4ms Preact JS 19.4ms Even the pessimistic responsiveness isn't very different with svelte being about 8% faster than Preact or Inferno. Vanilla JS 1882ms Inferno JS 2033ms Svelte JS 1883ms Preact JS 2031ms Inferno and Preact both have access to the wide support of the React ecosystem and tooling. Inferno is faster overall while not being particularly worse in any single area and better in others compared to Svelte. Why would I want to choose Svelte?
- mcbits 7y ago
  Your total size numbers are almost entirely dominated by Bootstrap and a font, which are the same for all the tests (and not something that would be used on a site where payload size matters). Svelte's JS output, gzipped, is about 40% smaller than Preact and 65% smaller than Inferno. Assuming those ratios hold up for larger apps, that would be one reason to consider Svelte.