Hallo molily,

wie so oft, hast Du doch bereits die meisten Antworten bei der gewohnt vielschichtigen Durchdringung eines komplexen Problems selbst an Tageslicht gewuchtet. Es kann natürlich auch sein, daß ich Deinen Grabungsansatz mißinterpretiere.

umfangreiches (re)zitieren:

... Diese neue Situation beschäftigt mich bei der Arbeit an einer kleinen Einführung in JavaScript, da sie Fragen aufwirft wie »Soll man noch JavaScript lernen oder gleich jQuery?« und »Wie hängt der Einsatz von Frameworks mit dem Lernen von JavaScript zusammen?«

Zwischen Entwicklern von Bibliotheken-Plugins sowie Fertigscripten und den JavaScript-Theoretikern scheint eine Kluft zu verlaufen. Diese drückt sich darin aus, dass deren Standardwerke oftmals nicht rezipiert wurden ...

... Durch die Verwerfungen liegt aber viel Arbeit vor uns, vor allem im Hinblick auf das Dokumentieren, Vermitteln und Lehren von JavaScript.

... Andererseits gehört es zum notwendigen JavaScript-Grundwissen, Bibliotheken und Frameworks selbstbestimmt einsetzen (und bestenfalls selbst entwickeln) zu können und jederzeit zu wissen, was man dabei tut.

... Den Prozess vom Spaghetticode zum Framework – von der Erfindung von Helferfunktionen wie getElementsByClassName bis hin zu $("beliebige CSS- oder XPath-Selektoren").chainability() – lief über viele Jahre. Diese Entwicklung nachzuvollziehen wäre zum Verständnis aktueller Ansätze nötig, ist den meisten aber nicht ohne weiteres möglich, da sie nie selbst Helferfunktionen entwickelt haben, die den vorherigen Programmierstil grundlegend über den Haufen warfen.

... den Faden mit dem zuletzt zitierten Block aufnehmend ...

Von einem neuen Standardwerk zu den Grundlagen von JavaScript erwarte ich geradezu den historischen Rückblick (Vom DHTML zum DOM-Scritpting), da diese Entwicklung ein direktes Ergebnis der gewachsenen und wachsenden Fähigkeiten des BOM/DOM und des Erkenntnisgewinns beim Ausreizen dieser Features ist.

Gerade eine Einführung in die Grundlagen von JavaScript bietet die ideale Plattform, um anhand nur weniger Beispielscripten (Klassiker: clientseitige Formularvalidierung) stetig deren technisches Niveau zu heben. Aus Gründen der Schreib- und Denkfaulheit kapseln diese Beispiele dann einmal als wiederverwertbar erkannte funktionale Lösungen (z.b. [String].trim oder [Array].contains) als Methoden. Und abstrakte Konzepte wie das Iterieren von Listen können dann auch recht schnell die immer wiederkehrenden "(for ...; ...length; ++i)"-Schleifen ablösen, wobei die Implementationen eines jeden Iterators bzw. Accessors ebenfalls eigenständig erarbeitet wurde. Dieser Schritt könnte auch zum Ende hin geschehen, wenn man sich über komfortablere DOM-query-Methoden gedanken macht.

Da sich bis zum letztgenannten Punkt eine direkt auf der API des JavaScript-Sprachkerns aufsetzende auf atomarer Ebene wunderbar modulare Bibliothek entwickelt hat, manövriert man sich spätestens mit der sich schwieriger gestaltenden Kapselung zur DOM-Manipulation in eine Zwickmühle. DOM-Objekte lassen sich nunmal nicht in jedem Browser prototypisch erweitern.
Sperrt man jetzt die Gesamtheit aller entwickelten Module in einen eigenen Namespace oder nur den DOM-Teil? Wie groß ist die Gefahr, daß die Bibliothek durch den eigenen Namespace zum Monolithen wird? - der umfangreiche Einsatz komplexer DOM-Wrapper, um [Node]s bzw. [NodeList]s abzubilden, erhöht jedenfalls diese Gefahr. Setzt man lieber komplett auf generische Lösungen wie z.b. "Node.doOrGetSomething(elm, [,arg [, ...]])"?
Wie begegnet man all diesen Herausvorderungen konzeptionell?

Ein neues Standardwerk zu den Grundlagen von JavaScript müsste dieses Problem ebenfalls umfassend beleuchten.

@Stafan

» Das Problem ist nur: wer soll all das schreiben? *g*

Wenn sich ein Verlag zu einem zwei- ...eher dreibändigem Werk "JavaScript/DOM Scripting" - "JavaScript 2" mit dem Autorenteam Mathias Schäfer / Peter Seliger hinreißen lassen würde, wäre ich ernsthaft dabei, solange ich meine Familie ernähren könnte.

so long - peterS. - pseliger@gmx.net