I agree with that, using a function call is not the optimise solution.
As you point out, the compression made by Gzip can compensate for the use of this plugin. However, I think that on a large web application, the entropy generated by these ternaries will still generate many KB.
For use with NodeJS, this polyfill remains a great solution.
I was trying to set up a little test case to see which one is smaller, and then I looked at lodash a bit more closely.
In the lodash.get function, they use two other Lodash functions: castPath and toKey. The castPath function uses isKey and stringToPath. And so on. So in the end, for that one function you're importing all of this: github.com/lodash/lodash/blob/4.4....
Of course there are probably better, more concise options than the Lodash implementation, so I set up a quick test case with just the one function body as listed in your post: github.com/woubuc/optional-chainin...
Even here, Babel still comes out ahead.
I know this test case is far from perfect, and if you notice any mistakes I made, be sure to let me know so we can keep this accurate. But it shows that gzip compression really does optimise away most of the size of the repeated inline if statements, along with some optimisations that Babel itself does (see the bundles/babel.js file, it creates intermediate variables).
So I still believe Babel is the better option, both in terms of performance and bundle size.
That's not to say that it won't add any size to your bundle, but then all polyfills do.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with that, using a function call is not the optimise solution.
As you point out, the compression made by Gzip can compensate for the use of this plugin. However, I think that on a large web application, the entropy generated by these ternaries will still generate many KB.
For use with NodeJS, this polyfill remains a great solution.
I was trying to set up a little test case to see which one is smaller, and then I looked at lodash a bit more closely.
In the
lodash.getfunction, they use two other Lodash functions:castPathandtoKey. ThecastPathfunction usesisKeyandstringToPath. And so on. So in the end, for that one function you're importing all of this: github.com/lodash/lodash/blob/4.4....Of course there are probably better, more concise options than the Lodash implementation, so I set up a quick test case with just the one function body as listed in your post: github.com/woubuc/optional-chainin...
Even here, Babel still comes out ahead.
I know this test case is far from perfect, and if you notice any mistakes I made, be sure to let me know so we can keep this accurate. But it shows that gzip compression really does optimise away most of the size of the repeated inline if statements, along with some optimisations that Babel itself does (see the
bundles/babel.jsfile, it creates intermediate variables).So I still believe Babel is the better option, both in terms of performance and bundle size.
That's not to say that it won't add any size to your bundle, but then all polyfills do.