Introducing smap.js, a forward polyfill for ES6 Maps | Hacker News Reader

Introducing smap.js, a forward polyfill for ES6 Maps

eriwen.com

13 pointsdevnulled9 comments

I have quite a few questions about this implementation, but here are two bigger ones:

1. Why are constructed Maps here having delete, get, has, set, size, keys, values, and iterate added outside of the prototype? I guess I don't see why you wouldn't just put these on the prototype. That said, .call seems to be unnecessary in a lot of this code.

2. Why isn't there any attempt to make lookups for primitives faster. It's all O(n).

For anyone confused, like me, about what a forward polyfill is, here's an explanation:

http://www.jonathantneal.com/blog/polyfills-and-prototypes/

    var NULL = null, TRUE = true, FALSE = false

I'm not sure I understand this. Why assign these to variables?

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").

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.)

Yep, you're right. I forgot about that.

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.

Couldn't you build it into the minifier rather than polluting the original source?

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.

Reply on news.ycombinator.com