Diskussionszusammenfassung auf Wikipedia

[molily]

Trotzdem ist bleibt es schwierig und nicht umsonst gibt es in YUI, Mootools, protptye, usw. überall diese Funktionen um dem JS Programmierer zu helfen. Und solange du nicht sicher bist, welches das Beste ist, ist es nervig, da alle andere Wege anbieten. Es wäre schöner, wenn es einen Weg gäbe, den die Sprache an sich hätte und wie es aussieht sind diese Dinge auf dem Weg (werden aber vermutlich 10 Jahre brauchen, bis sie allgemein eingesetzt werden können).

Wieso gibt es hunderttausende PHP-Frameworks? Wieso entstehen ständig neue obskure Nischen-Programmiersprachen? Wieso ist Rails Ruby, aber besteht aus mehreren weiteren Domain-Specific Languages? Wieso ist PHP total out, wieso interessieren sich alle plötzlich für Node.JS, wieso für CoffeeScript? Wieso ändert ein Framework von einer Version zur anderen plötzlich seine gesamte API? Wieso will PrototypeJS in der kommenden Version keine Natives mehr erweitern?

Weil: There's more than one way to do it. Es gibt tausend Wege, ein Problem zu lösen, und zehn davon sind wahrscheinlich richtig gut. Und kurze Zeit später kommt jemand mit einer ganz neuen Idee um die Ecke und zeigt auf, dass die alte problematisch ist. Das ist Vielfalt und Fortschritt, ganz normal.

JavaScript hat einen Weg »an sich«. Er lautet: Mutable Objects, einfache Object-Notation, Funktionen als First-Class Objects, Closures, funktionaler Scope, prototypische Delegation. Das ist JavaScript seit dem ersten Tag und das wird es voraussichtlich bleiben.

Dieser Weg wird recht konsequent in ES5 verfeinert: einfachere Delegation, Function Binding, funktionale Listenoperationen, die Zugriffsrechte enumerable/configurable/writable, preventExtensions, Sealing und Freezing, Getter und Setter, Strict Mode.

Und weiter in Harmony: Block Scope, Konstanten, Default-Parameter, »Rest«-Parameter statt »arguments«, Destructuring, lexikalisches this usw.

Wird das alles zehn Jahre dauern? Sicher nicht. ECMAScript ist seit einem Jahr draußen und wird schon recht breit unterstützt. Das können noch nicht alle Browser? Richtig, aber das Problem haben wir jederzeit mit sämtlichen Webtechniken. Siehe HTML5 und CSS3.

Wenn ob man JS wirklich eine OO Sprache nennen will, dann müßten solche Sachen wie Class, private, protected und einen Klassenweite scope geben

Ich bin kein Informatiker, aber bei allem, was ich weiß, ist das falsch. OO definiert sich nicht notwendig über Klassen. Klassen sind eine mögliche Umsetzung von OOP-Konzepten, die m.W. nicht am Anfang von OOP stand.

Denn im Prinzip stimmt es auch, du kannst mit jeder Sprache OO programmieren. Aber ob man JS, mit seinem zwei dafür zu Verfügung gestellten Eigenschaften 'new' und 'prototype', als OOP Sprache bezeichnen kann, halte ich zumindest für überzogen.

Ich würde sie nicht WEGEN sondern TROTZ dieser beiden Eigenschaften als OO bezeichnen.

Genau darum geht es in diesem Thread. Ausgangspunkt der Diskussion, war eine Bibliothek, die versucht hat die Konzepte zu erweitern, wenn JS diese hätte wäre sowas nicht nötig.

JavaScript hat keine Klassen - ist es schon aus diesem Grund heraus nötig, sie nachzubauen? Mit Sicherheit nicht. Klassen sind nicht das Ziel, sondern bloß ein möglicher Weg. Brauchen JavaScript-Programmierer zudem eine Kapselung in genau dieser Form? Das bezweifle ich stark. Ist diese Umsetzung sauber? Sie ist clever, aber gemäß gängigen JavaScript-Konventionen ein Albtraum.

Ihr sagt solche Bibliotheken sind überflüssig,

Ich weiß nicht, wen du mit »ihr« meinst und ich wüsste nicht, wer das in diesem Thread gesagt haben soll. Hingegen wurden viele gute Einwände und Schwierigkeiten geäußert.

was seltsam ist, denn YUI, Mootools usw. bieten genau das auch an. Also kann es nicht überflüssig sein und es scheint also notwendig zu sein JS damit auf die Sprünge zu helfen.

JavaScript hat auch ohne Vererbung mit Klassen sowie Member-Zugriffsrechte (protected/private) genug, um auf die Sprünge zu kommen.

Die genannten Bibliotheken bieten zwei Dinge:

1. Komfort und Einfachheit - das ist notwendig, wenn der Code umfangreicher und komplexer wird,
2. feste Strukturen und Konventionen - auch diese sind notwendig, aber INHALTLICH UNBESTIMMT, also durch die Wahl der Bibliothek bestimmbar.

Und ich stimme da Mathias auch völlig zu, für diese Hilfe benötigt es vor allem einen anderen Ansatz, als in anderen Sprachen wie z.b. Java, der sich mit wenigen Funktionen umsetzen läßt und nicht alle OOP Paradigmen 100% erfüllt. Dann kann man auch in JS OO programmieren.

Es gibt es doch kein grundlegendes Problem damit, komplexere Bibliotheken einzusetzen, die weitere OOP-Konzepte in JS einführen, wenn man dadurch besser programmieren kann. Sei es nun Joose, JS.Class oder class.js. Was sollte dagegen sprechen? Dass es Komplexität hinzufügt? Das gilt für sämtliche Software, die man im Web verwendet: MySQL, CouchDB, Redis. Zend Framework, Django, Ruby on Rails. Joomla, Drupal, TYPO3. Qooxdoo, Ext JS, Dojo. Flash, Flex, Papervision3D. Alles nicht einfach, aber teilweise sinnvoll und nötig.

Wer sagt denn, dass das in JavaScript nicht sein soll? Weil es die Performance bremst? Das tut es, aber immer weniger und weniger. Wenn ich heute auf ein JS-Projekt schaue, was ich vor einem Jahr low-level entwickelt habe, muss ich lachen, was für absurde Performance-Optimierungen ich vornehmen musste. Mit etwas neueren Browsern haben sich die Schwierigkeiten von selbst gelöst. Gut, damals habe ich halt auf etwas Komfort verzichtet, das war für mich kein großes Problem. Anfangen hatte ich da aber mit JS.Class.

Mathias