Stop Using Constructors in JS (2012)
ericleads.com
ericleads.com
There are many reasons to keep on using `new`, the biggest one is probably performance, `new Foo` will always outperform `Object.create(FooProto)`.
Really though, this kind of article just grinds my gears. There are so few absolutes in software development, articles like:
"You should always X"
"Stop doing Y"
"I don't actually understand X or Y"If I create an interpreter that changes `new Foo` to `$new(Foo)` where $new is a JS function that uses Object.create to do what the `new` operator does in spec (e.g., treat it as syntactic sugar) then it's unlikely that `new Foo` would outperform `Object.create(FooProto)`. Just because the current interpreters are hyperfocusing on `new` doesn't mean they can't make `Object.create` faster in the future.
All requiring `new` does is add an implicit requirement that the name of your function is actually `new X` instead of `X` with the added requirement that all aliases of the function be prefixed with `new `, which is not composable.
Yeah, `new` might be faster than not using it right now, but that's a bug in the interpreters. And for a lot of objects, your inner loop is not going to be in creation.
`new Foo()` is faster because it can be compiled to more efficient code today and probably always will be. Your argument is a bit like the "given a sufficiently intelligent compiler" one, I don't care about what JS engines of the future might do, I care about my code's performance today.
If you meant that new is faster today, say so. That's not the same as "will always outperform".
`new Foo` has simpler semantics than `Object.create(FooProto)` and therefore I believe it will always be faster. That performance gap can of course narrow, but I think `new` will always be the fastest. Happy to be proved wrong.
He's right, `new` is more than 10x faster in Chrome and Firefox for me at least:
Why would it `always outperform` though? Seems like an implementation detail. Object.create should be faster since it doesn't run a constructor.
For instance, if you want to use any of Google's Javascript libraries like their map api client, you're going to be using "new". So, now you've done a bunch of work to avoid using "new" but as soon as you step outside of your bubble, you're going to have to find a way to deal with "new" anyway. So, what's the point? Just use a good linter and be done with it.
Following an old-school technique just because you might see it in some legacy code doesn't seem like a great argument.
Stop over-engineering. YAGNI!
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".
Use strict. Lint your code. Use a decent build toolchain. Stop over-engineering your code unless you have a damn good justification for it.
Using a constructor in the first place in a language that really doesn't need them is what's dogmatic.
That's not accurate; there are actual, technical reasons for avoiding new hence why some advise against using it.
I really don't want to get into this argument but that's not what dogma means. Dogma is something that comes from an authority as being undeniable but saying you can't or shouldn't use new isn't undeniable, it's deniable as you said yourself there are valid reasons for using new.
and now I hate myself. Thanks.
``` var yourClass = require('your-class');
var myInstance = yourClass(); ```
The only way I'd make the first mistake is if I was unfamiliar with `your-class`'s API, so nothing can save me there.
JSHint would catch the second one.
A file exposing a class SHOULD either wrap it: `module.exports = function () { return new YourClass(); }` or use `if (!(this instanceof YourClass)) return new YourClass()` guards in the constructor to stop users of a class having to worry about whether or not to use new.
At least this seems to be the convention many module publishers seem to adhere to.
If you want the benefits of `new` without exposing your interface, you should totally wrap it.
But if you're going to have boilerplate like that for code that not's performance critical (and most of it is not), why not just go for Object.create() and returning the instance yourself. Less action at a distance.
1. Constructer's are great it's just like language x
2. uncanny valley of realizing it's not actually like language x
3. understanding constructors, use them everywhere
4. get burned by subtler points of this in async functions and forgetting new, decide to go all functional all the time
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.
This article is at stage 4
Object creation has not yet caused my any performance issues, so I've not seen a reason to personally use `new`.
I believe he has some experience of JS.
Basically there is so many different ways to create objects that the only thing that matters is to actually document any piece of code.
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!!!
Learn how javascript constructors and prototypes work,because you just CANT ignore them,wether you want it or not.
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.
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.
2. Language Y gains mindshare, inexperienced hotshots start running into age-old problems and reinvent a few wheels.
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.
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.
5. Language Z pops up...
var x = new Foo()
var x = foo()
A couple more benefits:
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.
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.
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.
What you're describing does not bear much resemblance to Python.
The similarity to Python is limited to syntax — I just wanted to raise the point that in both Python and prototype-free JS, higherOrderFunction(object.method) does what it looks like it will do.
I tend to use constructors like this: https://github.com/mattdesl/module-best-practices/blob/maste...
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).
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.
function User (name, lastname) {
if (!(this instanceof User)) {
return new User(name, lastname);
}
this.name = name || 'Unknown';
this.lastname = lastname || 'Unknown'
}; var Person = User.extend({});
var person = Person();
person instanceof Person; // false!
person instanceof User; // truePersonally, I only use this pattern for cases where it's more convenient not to have to use new (e.g. building declarative APIs for defining things) and let 'use strict'; catch the rest.
if (!(this instanceof User)) {
return new User(name, lastname);
}
The point is - don't forget `new` because tricks like this will not save you, in fact this is arguably worse - you think you're getting a `Person` but you get a `User` with no immediate errors, at least if you forget `new` then you'll get an error straight away in strict mode.
For now, I'll keep using `_.create` to do Inheritance. Of course it means another library to keep using and more verbose. But whatever...
var Person = function(){ User.call(this) };
Person.prototype = _.create(User.prototype, { 'constructor': Person });
var p = new Person();
p instanceof User //true
p instanceof Person //trueI generally just add a `create` method to the prototype so that you can do things like, `_.map(items, Constructor.create)`
1) Someone explains how using modern techniques can make for more maintainable code with less coupling and more reusability.
2) Someone pops in and notes that "Feature X/Y/Z is not available for browsers A, B, C"
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.
I often have the very same problem when I look at https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... or https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 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.
var MyModule = (function() {
function OneImplementation() {}
function OtherImplementation() {}
function factoryMethod() {
if (foobar) {
return new OneImplementation();
}
else {
return new OtherImplementation();
}
}
return {
create: factoryMethod
};
})();
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...
> 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.
> typeof String('abc')
'string'
> typeof new String('abc')
'object'
Seriously though the snippet for the forgetting-new protection in a constructor seems quite handy. It's always good to hear arguments from both sides of the fence.