"Stop writing prescriptive articles about software development when you're speaking from a position of ignorance"<p>There are many reasons to keep on using `new`, the biggest one is probably performance, `new Foo` will always outperform `Object.create(FooProto)`.<p>Really though, this kind of article just grinds my gears. There are so few absolutes in software development, articles like:<p><pre><code> "You should always X"
"Stop doing Y"
</code></pre>
almost always really mean<p><pre><code> "I don't actually understand X or Y"</code></pre>
No.<p>Stop over-engineering. YAGNI!<p>Most JS codebases are light on polymorphism. I think I've used one UI framework that had any kind of inheritance at all. I've never (ever) had a bug caused by "forgetting to type new".<p>Use strict. Lint your code. Use a decent build toolchain. Stop over-engineering your code unless you have a damn good justification for it.
Timeline of learning JavaScript<p>1. Constructer's are great it's just like language x<p>2. uncanny valley of realizing it's not actually like language x<p>3. understanding constructors, use them everywhere<p>4. get burned by subtler points of this in async functions and forgetting new, decide to go all functional all the time<p>5. have enough experience to avoid the foot guns, use constructors all the time as they tend to be the fastest method and have the best support.<p>This article is at stage 4
Here is the problem with Javascript.<p>Basically there is so many different ways to create objects that the only thing that matters is to actually document any piece of code.<p>Dont use constructors if you want.But somewhere you'll have to write "new FileReader" in the browser or "new XMLHttpRequest" because that's how an api you are consuming works!!!<p>Learn how javascript constructors and prototypes work,because you just CANT ignore them,wether you want it or not.<p>Truth is everybody wants to see what they wants to see in javascript.Some want to write pure Java like OOP,some think it looks like Haskell enough to try to write Haskell in Javascript. Javascript is no Java nor Haskell,one cant ignore one part of Javascript just because it looks "ugly" or whatever. Javascript is going to get classes and python like features and meta features like proxies. Javascript doesnt fit one paradigm, and never did.
0. Language X dominates development, but rigidly enforced design patterns and other universal conventions make the code confusing, hard to learn, hard to refactor, and generally slow to respond to new requirements.<p>1. New language Y pops up, thrilling small-scale devs, early adopters, and inexperienced hotshots with faster, cleaner ways of getting their jobs done without having to deal with all the cruft of old language X.<p>2. Language Y gains mindshare, inexperienced hotshots start running into age-old problems and reinvent a few wheels.<p>3. Language Y achieves dominance over the zeitgeist. Experienced software engineers start learning it. They see all the places where design patterns and rigid conventions could solve the potential problems they see, having run into it all before. They proselytize how these improvements will ensure high quality code and save all kinds of time in the future. These new patterns become standard and adoption of Language Y grows, even in larger corporate environments.<p>4. Language Y dominates development, but rigidly enforced design patterns and other universal conventions make the code confusing, hard to learn, hard to refactor, and generally slow to respond to new requirements.<p>5. Language Z pops up...
Here's a counter-argument.<p><pre><code> var x = new Foo()
</code></pre>
...is almost universally recognizable, and leaves little guesswork about the intent and meaning of the code. There's a lot more ambiguity encountering this:<p><pre><code> var x = foo()
</code></pre>
What am I getting back? A primitive value? An instance? A singleton? I have to go peruse the docs. `new` can definitely be abused to do non-intuitive things, but it's still a powerful signal to future readers of the code.
I stopped using constructors (and prototypes) a couple of years ago and it's improved my relationship with JS tremendously.<p>A couple more benefits:<p>1. You never need to see "this" again. You can refer to a method as object.method, and when you call that reference, you're calling the method on that object, just like in, say, Python. No "apply" madness needed.<p>2. If you decide your object might take some time to construct, you can change your "makeObject" function to be asynchronous (using promises or Node-style callbacks). With a constructor you just can't do this.<p>I've come to think of the constructor/prototype system as one of those bits that was bolted on to the rather clean "base" language of JS to meet Netscape's demand for a "java-like" language. You can really do without it.
I wouldn't say constructors are the problem -- the problem is with the "new" keyword.<p>I tend to use constructors like this:
<a href="https://github.com/mattdesl/module-best-practices/blob/master/README.md#constructor-best-practices" rel="nofollow">https://github.com/mattdesl/module-best-practices/blob/maste...</a><p>Which leads to clear debugging (named constructors and their prototypes showing in console) and also works well in the off chance that you need to use "inherits" (eg on node EventEmitter).<p>Regarding case; it comes down to preference. I tend to name my factories CamelCase or createCamelCase, so that the return value "camelCase" is clearly an instance.
The curse of Javascript:<p>1) Someone explains how using modern techniques can make for more maintainable code with less coupling and more reusability.<p>2) Someone pops in and notes that "Feature X/Y/Z is not available for browsers A, B, C"<p>In the end, people will keep on using the old constructors because they work all the time everywhere. And this is bad because this article does make a whole lot of sense.<p>I often have the very same problem when I look at <a href="https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/prototype" rel="nofollow">https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...</a> or <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/prototype" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a> where lots of the most interesting functions of said prototypes are marked as "experimental" and most likely won't be universally available before 2016 or so.
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.<p>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 <i>Programming JavaScript Applications</i>[4] (which looks excellent otherwise) doesn't cover testing, either, but devotes a chapter to using <i>logging</i> for debugging. I'd rather advocate using lint-on-save, test-driven development, test coverage, and continual integration.<p>Also, for a deep dive into OO criticism, Thomas Neimann's article <i>Nuts to OOP!</i> is a must-read. [5]<p>[1] <a href="http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-ya/" rel="nofollow">http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-...</a><p>[2] <a href="http://en.wikipedia.org/wiki/Open/closed_principle" rel="nofollow">http://en.wikipedia.org/wiki/Open/closed_principle</a><p>[3] <a href="http://underscorejs.org/#extend" rel="nofollow">http://underscorejs.org/#extend</a><p>[4] <a href="http://shop.oreilly.com/product/0636920033141.do" rel="nofollow">http://shop.oreilly.com/product/0636920033141.do</a><p>[5] <a href="http://www.embedded.com/design/prototyping-and-development/4216597/Nuts-to-OOP" rel="nofollow">http://www.embedded.com/design/prototyping-and-development/4...</a>
Another interesting point of view about constructors:<p><a href="http://www.2ality.com/2013/07/defending-constructors.html" rel="nofollow">http://www.2ality.com/2013/07/defending-constructors.html</a>
The biggest reason for using "new" in my practice is to keep the value of the "this" keyword on the instance within the function scope. Ihave to agree with the other commenters here. We all know JavaScript isn't OO. I just wish OO programers would stop trying to force their concepts and patterns on it. It makes maintenance a nightmare for those who didn't write it and didn't code Java/C#/Lisp or whatever OO language their concept originated in before picking up JavaScript.
It makes me so glad to see that the Javascript community will spend the next decade making all of the same stupid mistakes of useless overdesign that were made by the Java community (and probably others). Tangentially, what is it about the software community that makes us waste time with new and different - but not necessarily better - implementation technologies? Is this common in other fields?