Comment by carshodev
9 days ago
Yeah this article is only about React. But it makes sense that someone would think this way because many dev's think JS web apps==react only.
The problem is react is "good enough" for most cases and the performance degradations happen slow enough that the devs/project leads don't see it until it's too late and they are already overly invested in there project and switching would be too compliated/costly for them.
Svelte/kit and properly optimized packages solve almost all of the "problems" this article tries to bring up.
To be fair though, even with Svelte et al bundle sizes can balloon quickly when using UI toolkits and other libraries.
Yes but this is again nothing to do with svelte.
This is just how Node works, it's not a compiled language and you are not tree shaking all the components from libraries so this is bound to occur.
You can solve this by making your own libraries or just copying the individual source code for specific components into your project instead of including the whole package.
With sveltekit(and maybe nextjs aswell) you are only serving the necessary files to the client instead of including full library source code.
Wouldn't tree-shaking take care of this? i.e. If I only use 'Button' (from the UI library), nothing else should be included in the (production) bundle.
Not in practice, because these UI libraries usually have many intertwined interdependencies. <Button /> probably still imports all of the context providers, which also import their own dependencies, etc. So you end up including half of the library if not more just for a button, but if you use multiple components from the library the cost is amortised.
And typically if you're just using a single component it's one that is more complex than a button, like a popover or colour picker. Which then pulls in other components, etc.