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.
Over-engineering sounds a bit of a stretch in this case. The article compares using a normal function that returns an object vs using a special function that needs to be called with different syntax and that magically returns `this`. The former doesn't seem more over-engineered to me, in fact is seems simpler than the later.
JavaScript code rarely uses inheritance because it's completely out of place. Most non-trivial JS apps I've worked on make heavy use of duck-typing polymorphism. It works great because you don't need to deal with arcane class hierarchies: just make sure the object has what it needs to get its own job done.
Using a constructor in the first place in a language that really doesn't need them is what's dogmatic.
There are equally valid technical reasons for using `new`, so it's dogma
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.
How is writing a function to build an object "over-engineering"? It doesn't seem more complicated, and it appears it can help mitigate a particular human error (forgetting new).
A linter to catch the bugs and then go back and fix them is more work than just making it not possible to have the bug exist. Also, the lint you are talking about is based on a typographic convention that you could easily get wrong. For instance, the linter won't catch the bug in this snippet:
In your example you have two "bugs", you're not capitalizing the constructor name and you're not using `new`. I would have to make two separate mistakes to reproduce the issue you're talking about.
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.
Nitpick, on the nothing can save me there part. This is arguably a failure of `your-class`'s API.
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.
Yeah, but that falls under epediaman's "Stop over-engineering. YAGNI!" quote.
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.
Comments
No.
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.
Over-engineering sounds a bit of a stretch in this case. The article compares using a normal function that returns an object vs using a special function that needs to be called with different syntax and that magically returns `this`. The former doesn't seem more over-engineered to me, in fact is seems simpler than the later.
Avoiding the use of 'new' isn't overengineering, it's idiomatic JS.
It's dogmatic not idiomatic.
JavaScript code rarely uses inheritance because it's completely out of place. Most non-trivial JS apps I've worked on make heavy use of duck-typing polymorphism. It works great because you don't need to deal with arcane class hierarchies: just make sure the object has what it needs to get its own job done.
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.
There are equally valid technical reasons for using `new`, so it's dogma
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.
damn, I've been using that word slightly incorrectly for years, and now I hate myself. Thanks.
Whoa a pleasant exchange on the internet. Yay.
What are the technical reasons to avoid using new?
How is writing a function to build an object "over-engineering"? It doesn't seem more complicated, and it appears it can help mitigate a particular human error (forgetting new).
The linter would catch the missing new
A linter to catch the bugs and then go back and fix them is more work than just making it not possible to have the bug exist. Also, the lint you are talking about is based on a typographic convention that you could easily get wrong. For instance, the linter won't catch the bug in this snippet:
``` var yourClass = require('your-class');
var myInstance = yourClass(); ```
In your example you have two "bugs", you're not capitalizing the constructor name and you're not using `new`. I would have to make two separate mistakes to reproduce the issue you're talking about.
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.
Nitpick, on the nothing can save me there part. This is arguably a failure of `your-class`'s API.
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.
Yeah, but that falls under epediaman's "Stop over-engineering. YAGNI!" quote.
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.