One comment against this that I've read, is that the Javascript engine can optimise inline code better. Using a function like lodash.get would invoke an extra function call (creating a new function scope) and run more complex logic for every statement that uses optional chaining. I'm not all that familiar with runtime optimisations myself, but it sounds plausible to me that checking if foo === null is a lot less expensive than calling a function like lodash.get.
Also, frequently repeated patterns (like === null) can get optimised and pretty heavily with gzip compression, so I doubt it would increase the download size by that much. Especially compared to the other hundreds of kilobytes of dependencies we usually have in our frontend bundles.
I know the Javascript engine can do a lot, but I find it hard to believe that it could optimise a while-loop with object assignments (like the lodash.get function) to be as performant as foo === null checks.
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.
One comment against this that I've read, is that the Javascript engine can optimise inline code better. Using a function like
lodash.getwould invoke an extra function call (creating a new function scope) and run more complex logic for every statement that uses optional chaining. I'm not all that familiar with runtime optimisations myself, but it sounds plausible to me that checking iffoo === nullis a lot less expensive than calling a function likelodash.get.Also, frequently repeated patterns (like
=== null) can get optimised and pretty heavily with gzip compression, so I doubt it would increase the download size by that much. Especially compared to the other hundreds of kilobytes of dependencies we usually have in our frontend bundles.I know the Javascript engine can do a lot, but I find it hard to believe that it could optimise a while-loop with object assignments (like the
lodash.getfunction) to be as performant asfoo === nullchecks.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.