Sorry for not directly writing back, was busy these days 🙂
So tree shaking can be performed by e.g. webpack and this is a strategy to minimize your bundled code
If you only import something like import { myFunctionA } from 'moduleX';, only myFunctionA will be bundled in the output code but e.g. myFunctionB would not.
If you now have my.functionA and my.functionB and you use import { my } from 'moduleX'; you are forced to bundle both functions into output code, also if you only need functionA
This hugely increases your bundled output, cause you are forced to import everything from allow in your example.
I may be wrong and @SeanAllinNewell may have another idea how you can still benefit from tree shaking. But currently that is what I understand under the term tree shaking and plugins can show the imported kb of an import statement in e.g. VSCode.
OK. I know what tree-shaking is. But I didn't understand what exactly you were getting at. A few thoughts on this:
I understand the need to import components separately. But I think it can sometimes get kinda silly when you're talking about functions. For example, my allow library is used throughout my entire app. Most of the functions in that library will be used somewhere in the app. So it's needlessly specific to force the coder to import each one of those functions independently.
The allow library has 169 LoC that encompass 19 functions. The raw file is 6.59 KB. I haven't even tried to look up how small this becomes once it's minified. But the point is that it will be tiny.
But you bring up a good point about bundle size. Specifically, I've found that, too often, JS devs make choices that undermine the readability (and thus, the maintainability) of their own code in the name of bundle size. So... a few more thoughts on that thought:
If you have absolute control over your app and how it's rendered, then I can kinda understand the desire to minimize bundle size. But this is rarely the case in corporate apps. Typically, once your app is deployed, it's put in a wrapper that has a ton of ads, trackers, analytics, images, video, and other such detritus. For example, if you go to espn.com with no ad blockers, their homepage currently uses up 6.5 mega bytes. And this is not unique in corporate environments. I just can't get too worked up about 5KB here-or-there in an app's bundle when the sites we frequent nowadays are often multiple megabytes.
IMHO, tweaking bundle size is usually a micro-optimization. I understand that there are some situations with some apps where bundle size can be critical. I also understand that, for most apps, the functional difference between a 100k bundle and a 105k bundle is... nothing. And even if you want to take the stance that all those things add up, well then... so what? Because, again, the functional difference between a 100k bundle and a 300k bundle is typically... nothing.
Although this article may feel a bit esoteric to most, I wrote it because this is another of those little issues that gnaws at me because it affects the readability of code. And readability isn't a "nice to have". More readable code is more maintainable code. If devs are consciously sacrificing readability for bundle size, then for most apps in most environments, they're making the wrong choice.
Totally understand your POV
Just wanted to say this so newbies that read your article don't follow it blindly without thinking about the consequences 🙂
Sorry for not directly writing back, was busy these days 🙂
So tree shaking can be performed by e.g. webpack and this is a strategy to minimize your bundled code
If you only import something like
import { myFunctionA } from 'moduleX';, onlymyFunctionAwill be bundled in the output code but e.g.myFunctionBwould not.If you now have
my.functionAandmy.functionBand you useimport { my } from 'moduleX';you are forced to bundle both functions into output code, also if you only needfunctionAThis hugely increases your bundled output, cause you are forced to import everything from
allowin your example.I may be wrong and @SeanAllinNewell may have another idea how you can still benefit from tree shaking. But currently that is what I understand under the term tree shaking and plugins can show the imported
kbof an import statement in e.g. VSCode.OK. I know what tree-shaking is. But I didn't understand what exactly you were getting at. A few thoughts on this:
I understand the need to import components separately. But I think it can sometimes get kinda silly when you're talking about functions. For example, my
allowlibrary is used throughout my entire app. Most of the functions in that library will be used somewhere in the app. So it's needlessly specific to force the coder to import each one of those functions independently.The
allowlibrary has 169 LoC that encompass 19 functions. The raw file is 6.59 KB. I haven't even tried to look up how small this becomes once it's minified. But the point is that it will be tiny.But you bring up a good point about bundle size. Specifically, I've found that, too often, JS devs make choices that undermine the readability (and thus, the maintainability) of their own code in the name of bundle size. So... a few more thoughts on that thought:
If you have absolute control over your app and how it's rendered, then I can kinda understand the desire to minimize bundle size. But this is rarely the case in corporate apps. Typically, once your app is deployed, it's put in a wrapper that has a ton of ads, trackers, analytics, images, video, and other such detritus. For example, if you go to espn.com with no ad blockers, their homepage currently uses up 6.5 mega bytes. And this is not unique in corporate environments. I just can't get too worked up about 5KB here-or-there in an app's bundle when the sites we frequent nowadays are often multiple megabytes.
IMHO, tweaking bundle size is usually a micro-optimization. I understand that there are some situations with some apps where bundle size can be critical. I also understand that, for most apps, the functional difference between a 100k bundle and a 105k bundle is... nothing. And even if you want to take the stance that all those things add up, well then... so what? Because, again, the functional difference between a 100k bundle and a 300k bundle is typically... nothing.
Although this article may feel a bit esoteric to most, I wrote it because this is another of those little issues that gnaws at me because it affects the readability of code. And readability isn't a "nice to have". More readable code is more maintainable code. If devs are consciously sacrificing readability for bundle size, then for most apps in most environments, they're making the wrong choice.
Totally understand your POV
Just wanted to say this so newbies that read your article don't follow it blindly without thinking about the consequences 🙂
Good point!