svelte-kit-koa-boilerplate VS svelte-it-will-scale

- once released and popular, they cease getting frequent updates

Now, yes this is a generalization. It doesn't apply to all of their packages, and not at the same point in time. But there is a pattern there. Some quick diving into the author's Github account, and their more popular repos shows the pattern. It's also clear that this was a choice made by a Svelte contributor to use their own package for "official" support in Svelte Kit.

When it comes to polka itself, I just don't get why a maturing framework like Svelte would choose something whose only real advantage lies in micro-benchmarking porn [1]. Speculation aside, I'm surprised the Svelte team didn't look at that choice through a lens of higher scrutiny. Koa would have been an infinitely better choice in my personal opinion, and there are several community-driven setups [2][3] for it.

[1] https://github.com/lukeed/polka#benchmarks

[2] https://github.com/kaladivo/svelte-kit-koa-boilerplate

[3] https://blog.logrocket.com/sapper-svelte-tutorial-2021/

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.