4 ms·
- The large bundle sizes were recently addressed here. It doesn't seem to be a problem in practice: https://github.com/halfnelson/svelte-it-will-scale https://g
by erokar 6y ago
- The large bundle sizes were recently addressed here. It doesn't seem to be a problem in practice: https://github.com/halfnelson/svelte-it-will-scale https://github.com/halfnelson/svelte-it-will-scale
- You could perfectly fine write update functions á la React for your component state if that is what you prefer. Personally I don't feel that's necessary and prefer Svelte's direct way.
- hajile 6y agoYou hit the problem at 120k unminified. It only takes a couple feature-rich libraries to hit that number. Even medium-sized business apps can hit that number on their own pretty easily (without including any libraries) > In practice, you're unlikely to hit that inflection point on any given page of your app, as long as you're using code-splitting (which Sapper gives you OOTB) That is straight-up fiction. If you bundle split correctly, you put React and other shared libraries in ONE bundle that is shared by all your component bundles. If you're coding an actual app, they'll wind up needing most of those bundles at which point the problem doesn't go away. Detecting similar functions and combining them is possible (though it will probably add substantially to compile time). I have no doubt that if svelte continues to grow, it will have to handle this problem. I somehow doubt they'll say it's just a minor feature update affecting just a few users when they finally get that work done. Don't forget that reusing code more also allows the JIT to optimize it to get you better performance too.