Crockford has good recommendations on when to use `new`, or not, in his 2006 post on the topic[1]. I like most of what the author says re. classical OO in JS, but would stop short of not using `new` at all. Its a long-established standard and the open/close principle[2] is probably not enough of a concern in most applications to warrant using a different / slower / sometimes unsupported method. And there are functional programming libraries for extending objects[3]. Just encourage people to use idiomatic JS and then layer on solutions when and if they become a problem.
The article uses stories of obscure bugs as justification. These stories get used an awful lot to justify dogma on everything from strict typing to Promises to whatever. I feel that's misguided - there will always be enough rope to hang oneself with in any language, and those errors should have been mitigated by diligent use of static code analysis (linting) and unit testing. The author's book Programming JavaScript Applications[4] (which looks excellent otherwise) doesn't cover testing, either, but devotes a chapter to using logging for debugging. I'd rather advocate using lint-on-save, test-driven development, test coverage, and continual integration.
Also, for a deep dive into OO criticism, Thomas Neimann's article Nuts to OOP! is a must-read. [5]
These stories get used an awful lot to justify dogma on everything from strict typing to Promises to whatever. I feel that's misguided - there will always be enough rope to hang oneself with in any language, and those errors should have been mitigated by diligent use of static code analysis (linting) and unit testing.
Paraphrasing the talk I just linked to, it's always better to have a language which will guide you away from writing the bug in the first place than to have to come back with a linter and fix it up.
Comments
Crockford has good recommendations on when to use `new`, or not, in his 2006 post on the topic[1]. I like most of what the author says re. classical OO in JS, but would stop short of not using `new` at all. Its a long-established standard and the open/close principle[2] is probably not enough of a concern in most applications to warrant using a different / slower / sometimes unsupported method. And there are functional programming libraries for extending objects[3]. Just encourage people to use idiomatic JS and then layer on solutions when and if they become a problem.
The article uses stories of obscure bugs as justification. These stories get used an awful lot to justify dogma on everything from strict typing to Promises to whatever. I feel that's misguided - there will always be enough rope to hang oneself with in any language, and those errors should have been mitigated by diligent use of static code analysis (linting) and unit testing. The author's book Programming JavaScript Applications[4] (which looks excellent otherwise) doesn't cover testing, either, but devotes a chapter to using logging for debugging. I'd rather advocate using lint-on-save, test-driven development, test coverage, and continual integration.
Also, for a deep dive into OO criticism, Thomas Neimann's article Nuts to OOP! is a must-read. [5]
[1] http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-...
[2] http://en.wikipedia.org/wiki/Open/closed_principle
[3] http://underscorejs.org/#extend
[4] http://shop.oreilly.com/product/0636920033141.do
[5] http://www.embedded.com/design/prototyping-and-development/4...
Douglas Crockford's been making this argument this year at conferences: http://www.youtube.com/watch?v=bo36MrBfTk4&t=19m (linked to the `new` bit, but the whole thing's worth watching).
Paraphrasing the talk I just linked to, it's always better to have a language which will guide you away from writing the bug in the first place than to have to come back with a linter and fix it up.