Well, it’s pretty easy to rig up yourself. Why further pollute the prototypes? Object.keys(obj).forEach(function(key) { var value = obj[key]; }); I think a big reason is that the powers that be want to avoid adding built in properties to Object. Objects are the building blocks of everything in Javascript, but are also the generic key/value … Read more
For you, without using a browser that supports strict mode: A Use Strict Directive is an ExpressionStatement in a Directive Prologue whose StringLiteral is either the exact character sequences “use strict” or ‘use strict’. A Use Strict Directive may not contain an EscapeSequence or LineContinuation.
As far as writing an export that is compatible for both ES5 and ES6, Babel already takes care of that for you. (As communicated in the comments to your question. I’m only clarifying for those who got lost in the dialog.) module.exports = MyClass will work with both var MyClass = require(‘mymodule’) and import MyClass … Read more
You want to assign the value of module.exports to be your default function, and then put all the named exports as properties on that function. const defaultFunction = () => { console.log(‘default!’); }; const namedFunction1 = () => { console.log(‘1!’); }; const namedFunction2 = () => { console.log(‘2!’); }; const myModule = module.exports = defaultFunction; … Read more
UPDATE from 2021 Despite this being the accepted answer, 10 years of experience has taught me this isn’t the best idea. Pretty much anything you can do to avoid polluting the global scope is a very very good thing. Original answer below, for posterity, and because stack overflow will not let me delete an accepted … Read more
“use strict” applies only to function or program scope. So if you have fileA.js with “use strict” at the top, fileA.js executes in strict mode, and all functions defined in it will do the same when called. But fileB.js is a separate program, so the “use strict” from fileA.js doesn’t apply to it — and … Read more
Object(window) will never clone window but new Object(window) might. All current — potentially all known — implementations just return the same reference, although the spec allows for implementation-defined behavior. The steps for 15.2.1.1 say: If value is null, undefined or not supplied, create and return a new Object object exactly as if the standard built-in … Read more
I don’t think the constructor/factory logic is necessary at all, as long as you change how you think about Object-Oriented Programming. In my recent exploration of the topic, I’ve discovered that Prototypical inheritance lends itself more to defining a set of functions that use particular data. This isn’t a foreign concept to those trained in … Read more
In IE<9, .toStringing (function (x) {return x*x;}) gives “(function (x) {return x*x;})” While in chrome it gives: “function (x) {return x*x;}” If you compare: “function (x) {return x*x;}” > “1,2,3” // true “(function (x) {return x*x;})” > “1,2,3” // false Which is effectively the same as comparing: “f” > “1” “(” > “1” Which is … Read more
No, not for now 🙁 From the CoffeeScript FAQ: Q: Will you add feature X where feature X depends on a platform? A: No, implementation-specific features are not allowed as a policy. Everything that you write in CoffeeScript should be supported and runnable on any current JavaScript implementation (in practice, this means the lowest common … Read more