[DISKUSSION] Ist die Zukunft von JavaScript Klassenbasiert oder Prototypenbasiert? ES6 und folgend

[Darry]

Moin.

Folgende Frage möchte ich mal in den Raum stellen:

Ist die Zukunft von JavaScript Klassenbasiert?

Wird JavaScript in den kommenden Jahren vom bishereigen Prototypenbasierten Modell auf ein "Echtes" Klassenbasiertes Modell umgestellt?

In ECMA-script6 sind ja jetzt auch Klassen und klassenbasierte Vererbung möglich. Aber ist das denn schon "Nativ"unterstützt oder wird intern auf das Prototypenbasierte System umgesetzt?
ActionScript hat damals ja auch gewechselt von Prototypenbasiert auf Klassenbasiert.

In den bisherigen Versionen von JavaScript versuchten viele Entwickler ja, ein Klassenbasiertes System über irgendwelchen Kniffen "Nachzubilden" oder es wurden irgendwelche Frameworks benutzt. Weil die Leute das Klassenbasierte System halt aus anderen Programmiersprachen kannten.

Leider werden auch in vielen "Grundlagentotorials " gerne Begrifflichkeiten aus dem Klassenbasierten Umfeld verwendet oder es werden gleich Substitutionen gebracht, statt das Prototypenbasierte System vernünftig zu erklären.

Ich lerne gerade JS "From the root", ohne nennenswert aus anderen Objektorientierten Programmiersprachen mit dem "Klassenbasierten" System vorbelastet zu sein. Es macht mir also nichts aus, direkt Prototypenbasiert zu lernen und zu arbeiten.

Allerdings, falls sich abzeichnen sollte, das JS in Zukunft Nativ auf ein Klassenbasiertes System wechselt, und das Prototypenbasierte System nur aus "Kompatibilitätsgründen" weiterhin unterstützt wird, (Durch interne Umsetzung auf Klassen usw) würde ich auch ehr auf die Klassenbasierte Programmierweise gehen, was mit ES6 ja jetzt möglich ist.
Da ich eben das nutzen will, was in Zukunft nativ unterstützt werden wird.

Also:
Ist ECMA-Script 6 Intern weiterhin Prototypenbasiert und das mit den Klassen nur durch interne "Umsetzung" realisiert? Oder ist ECMA-Script 6 intern schon Klassenbasiert und das Prototypenbasierte System wird per interner Umsetzung weiter unterstützt?
Und wie sieht eurer Meinung nach die Zukunft für JS aus, bezüglich Nativer Unterstüzung im Sprachkern? Weiterhin Prototypenbasiert oder Klassenbasiert?

 

[tsseh]

Ist ECMA-Script 6 Intern weiterhin Prototypenbasiert und das mit den Klassen nur durch interne "Umsetzung" realisiert? Oder ist ECMA-Script 6 intern schon Klassenbasiert und das Prototypenbasierte System wird per interner Umsetzung weiter unterstützt?

was heißt intern? mit der class-syntax in es 6 kannst du ja nichts, was du nicht bisher auch schon kontest, es sieht nur besser aus.

Und wie sieht eurer Meinung nach die Zukunft für JS aus, bezüglich Nativer Unterstüzung im Sprachkern? Weiterhin Prototypenbasiert oder Klassenbasiert?

was verstehst du denn unter klassenbasiert?
kapselung? hat nichts mit prototype zu tun.
vererbung? geht mit prototype.
mehrfachvererbung? da hörts auf, aber das können auch nicht alle andere sprachen, z.b. java.
schnittstellen? hat eher was mit typisierung zu tun.

 

[Darry]

Mit Intern meine ich die Umsetzung auf Parserebene. Also ob die mit ES6 geschaffenen Möglichkeiten zukünftig auch die "Native Arbeitsweise" sein wird wird.
Oder ob es intern auch auf lange Sicht weiterhin Prototypisch arbeiteten wird. (Im Hinblick auf ES 7, ES 8 ....)

Bei ES5 gab es ja auch schon einige Frameworks, die "Klassenbasierte Programmierweise" ermöglichten, die haben aber auch nur umgesetzt.

 

[tsseh]

Mit Intern meine ich die Umsetzung auf Parserebene.

"auf Parserebene", ja da spielt sich die änderung ab (und die vieler anderen es6 features). willst du auf die browserunterstützung hinaus? die abwärtskompatibilität? da ist es leider so, daß einige es6 features nicht durch polyfills realisiert werden können.

Also ob die mit ES6 geschaffenen Möglichkeiten zukünftig auch die "Native Arbeitsweise" sein wird wird.
Oder ob es intern auch auf lange Sicht weiterhin Prototypisch arbeiteten wird. (Im Hinblick auf ES 7, ES 8 ....)

nochmal, alles was in es6 mit klassen eingeführt wurde ist nur eine kürzere/sauberere/schönerere/übersichtlichere schreibweise. es ist wie du selbst sagst "auf Parserebene".

Bei ES5 gab es ja auch schon einige Frameworks, die "Klassenbasierte Programmierweise" ermöglichten, die haben aber auch nur umgesetzt.

um was zu erreichen?

 

[Darry]

Die Frameworks, die ein "Klassenbasiertes" Look-And-Feel erzeugten, sind meiner Meinung nach dafür da, Leuten, die Erfahrungen aus Klassenbasierten Sprachen haben, das Leben etwas leichter zu machen. Teilweise wurde das auch durch spezielle "Formulierungen" erreicht, was man in einigen Tutorials gerne sieht. Da werden dann Begrifflichkeiten aus Klassenbasierten Sprachen benutzt, und die Konstruktoren und Prototypen auch so geschrieben, dass gewisse "Ähnlichkeiten" zu Klassenbasierten Sprachen entstehen. Und das finde ich persönlich relativ verwirrend.

Wenn ich es aber lerne, will ich es möglichst "Nativ" lernen, und auch in der Grundlegenden Form nutzen, und erstmal auch nicht auf Frameworks oder Helferlein zurückgreifen.

Wenn ich eine Syntax will, die Klassenbasierten Sprachen nahekommt, dann nur ES6.

Worauf ich hinaus will:

Ich bin mir aber nicht sicher, ob der "Syntaktische Zucker" von ES6 auch immer nur syntaktischer Zucker bleibt, oder ob nicht irgendwann (Mit ES7 oder späteren Releases) doch mal ein "Systemwechsel" im Kern kommt, wie es z.B. bei ActionScript war. Auch wenn es dann bestimmt keinen harten Cut gibt, und Abwärtskompatibilität sicherlich erhalten bleibt, ich will jetzt aber so lernen, dass es auch in ein paar Jahren noch "State of the art" ist und nicht irgendwas im "Kompatibilitätsmodus" ist.

Sprich: Spezialisiere ich mich jetzt, was OOP in JS betrifft, voll auf die Formulierungen aus ES6, weil diese vielleicht die langfristige Zukunft und nicht nur syntaktischer Zucker sein könnten?
Nebenbei vereinfacht der "Syntaktische Zucker" aus ES6 einiges.

Oder lerne ich das "Klassische" System und verinnerliche es so, dass ich es im Schlaf beherrsche?


Achja: Das Thema Abwärtskompatibilität zu alten Browsern ist mir nicht so wichtig. Ich richte meinen Blick lieber in die Zukunft, nicht auf die Vergangenheit.



LG

 

[tsseh]

Sprich: Spezialisiere ich mich jetzt, was OOP in JS betrifft, voll auf die Formulierungen aus ES6, weil diese vielleicht die langfristige Zukunft und nicht nur syntaktischer Zucker sein könnten?

die syntax aus ES6 wird langfristige(wobei langfristig keine 5 jahre sein werden) die zukunft sein, aber ist nur syntaktischer zucker

Oder lerne ich das "Klassische" System und verinnerliche es so, dass ich es im Schlaf beherrsche?

ja, natürlich, da das die grundlage ist