hi tami,
Will jetzt keine Grundsatzdiskussion, "aber" dass Crockford meint, "new" wäre fehlerträchtig und könne seines Kenntnis standes immer umgangen werden, weißt du ja vermutlich. Keine Ahnung, ob "new" bei den von Dir verlinkten Libraries auftaucht, oder ob das "wirklich" "unnötig" ist.
Wichtig ist es die Diskussion um das new-Keyword und native JavaScript-Konstruktoren zu vertehen und dann für den eigenen Anwendungsfall eine Abwägung vorzunehmen, ob ein Konstruktor oder eine Factory angebracht ist. Die Wahl pro "new" ist keinesfalls ein Indiz für schlechten Programmierstil. Dr. Axel Rauschmayer, den molily hier auch schon erwähnt hat, liefert zum Beispiel ein paar Argumente für Konstruktoren und gegen Factories.
Da dann mal den Kommentar von Eric Elliot http://www.2ality.com/2013/07/defending-constructors.html#comment-977234354.
Zudem: "I believe the Crockford style of avoiding
new
at all costs comes mostly from protecting people who don't really know how to write JavaScript in projects at large.This used to be good advice because pretty much no-one who built web applications really knew or liked JavaScript. In recent years we've seen a rise in complaints against the "avoid newing up objects" style."
Ich kapiere die wirklich ellenlange Diskussion nicht wirklich. Wenn "new" fehlerträchtig ist (oder auch nur sein kann, wenn der Kenntnisstand der Programmierer (=Mitarbeiter, zukünftiger Mitarbeiter, Nachfolger, sonstige) nicht ausreichend ist) und leicht umgangen werden kann, warum nicht? Eine Sorge weniger. Wenn das auch Douglas Crockford, Kyle Simpson und Eric Elliot so sehen ...;
Und: "The issue for me is not about the non-safety or the inflexibility of constructors. The issue is more that constructors force the usage of two whole concepts new
and this
that the object-constructor pattern (and extending for inheritance) does not. Worse, these are two keywords that don't do what the vast majority of javascript developers think that they do.
Yes, it's a Crockford-style argument.
Admittedly, there are certainly advantages to using constructors - speed, memory, traceability, prototype inheritance. But, in building dozens of javascript-heavy SPAs I've seen a use case where these benefits actually matter maybe...once?
In the meantime I've had mountains of sessions with junior and even mid-level devs (which, let's be honest, in javascript world is most people) who can't figure out why the component they're trying to reuse won't work in their specific situation. It is almost always the fault of misunderstanding this
. If the original developer had created a simple object rather than using constructors none of this would have been an issue.
For jQuery, underscore, any sort of reusable framework-building I perfectly understand, go ahead and use constructors. For applications other than the complicated in-browser SPAs? I can see your point. But in this specific but very popular use-case, how can you possibly justify that differential?
My own ranting blog post. Mostly against the use of this
: https://github.com/togakangaroo/Blog/blob/master/javascript-on-this-and-new.md"
mfg
tami