Re:Introducing smap.js, a forward polyfill for ES6 Maps
by FuzzyDunlop on Friday November 09, 2012 @12:51PM
(#4763877)
I'm not sure I understand this. Why assign these to variables?
[ Parent
| on HN ]
Re:Introducing smap.js, a forward polyfill for ES6 Maps
by esrauch on Friday November 09, 2012 @01:26PM
(#4764052)
I think the reason for these is for js minification. With these assignments a simple minifier will replace those three variables with a line like this:
var a=null,b=true,c=false;
Then your minified js will be smaller because all other instances of true, false and null will be one character. Whether or not this is a reasonable optimization is debatable but in terms of pure code size it would be a win.
Re:Introducing smap.js, a forward polyfill for ES6 Maps
by ajanuary on Friday November 09, 2012 @01:35PM
(#4764096)
Couldn't you build it into the minifier rather than polluting the original source?
Re:Introducing smap.js, a forward polyfill for ES6 Maps
by jackmoore on Friday November 09, 2012 @02:49PM
(#4764442)
Yes, stuff like this shouldn't be in the source. UglifyJS and Closure compiler make this optimization, but I've used other js minifiers that did not.
Re:Introducing smap.js, a forward polyfill for ES6 Maps
by wendelinsky on Friday November 09, 2012 @12:57PM
(#4763910)
That is part of the es6-collections polyfill included as part of smap.js. If I understand correctly, it is for safety (for example you cannot override the value of "true").
Re:Introducing smap.js, a forward polyfill for ES6 Maps
by Twisol on Friday November 09, 2012 @01:22PM
(#4764031)
null, true, and false are all keywords. Isn't undefined the only one that can be redefined? (And then it's just equal to void 0.)
Re:Introducing smap.js, a forward polyfill for ES6 Maps
by emwendelin on Friday November 09, 2012 @01:32PM
(#4764080)
Yep, you're right. I forgot about that.