Found in 1 comment on Hacker News
drderidder · 2014-11-06 · Original thread
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...

Fresh book recommendations delivered straight to your inbox every Thursday.