svelte-it-will-scale VS js-framework-benchmark

Compiled code logic redundancy. Some readers may worry that if the complexity of the business logic, resulting in a straight line increase in the size of the code file after compilation, whether it will lead to a certain degree of performance degradation?Github on the relevant developers for this problem to analyze svelte-it-will-scale:

That N is very large. E.g. here's a page that talks about it: https://github.com/halfnelson/svelte-it-will-scale. I'll note that was done with Svelte 3 and that with Svelte 4 components are at least 10% smaller, so it's actually even better than that. SvelteKit is also very efficient at JS splitting per-route thanks to Vite. It ensures only the JS that is necessary for a page is loaded and you're extremely unlikely to be using anywhere near that many components. Based on the article above, you'd have to have three entire sites worth of components on a single page.

Sure, performance (bundle size), performance/predictability, simplicity (blog post)

Finding Svelte's Inflection Point

yes am aware, but also in any realistic scenario, code splitting comes in well before the crossover point where that even remotely comes into question. this has been independently verified twice now:

https://twitter.com/sveltesociety/status/1301168598988107776...

https://svelte-scaling.acmion.com/

https://github.com/halfnelson/svelte-it-will-scale

sveltekit has further opportunities for whole-app optimization but honestly given this research i lost interest bc its more than good enough

Svelte lowers the initial size of your app, however the incremental cost of each component creates an inflection point, where the added size of each component exceeds the size of a pre-bundled framework. What actually matters is where this inflection point is. This experiment actually evaluates that https://github.com/halfnelson/svelte-it-will-scale. Essentially, you would need a project equivalent to four times the size of the svelte.dev website to reach this point.

Naturally, the first thing I want to do is put these to the test, but it would be anecdotal at best. The first thing that came to mind was the comparison of Svelte Component Scaling compared to React. Some sort of test to see how much difference a small library that ignored all this compared to a large library that didn't.

Hey everyone! I spent 2.5 years solving the speed problem in the js-framework-benchmark repository, and I don't regret it, because there is a super interesting observation that I recently noticed.

You can compare performance in a more rigorous way by consulting Stefan Krause's js-framework-benchmark project. Here are results based on the latest snapshot:

# Clone the repository git clone https://github.com/krausest/js-framework-benchmark.git cd js-framework-benchmark # Install dependencies and start the server npm ci && npm run install-local npm start # Run the benchmark npm run bench # Generate the results table npm run results

By comparing performance on benchmark, we can see that Svelte outperforms front-end frameworks such as React, Vue, and Angular overall, except for being slightly behind Solid.

JavaScript benchmarks are instruments for measuring the speed and effectiveness with which a JavaScript engine—such as the ones found in web browsers—can complete particular tasks. Benchmarks are used by developers and browser vendors to evaluate various engines, find places in the code where improvements are needed, and make sure JavaScript standards are being followed.

Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark

Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.

And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?