Aloha ;)

Abgesehen davon: Du machst es einem nicht einfach :P Versuch mal, dich kürzer zu fassen - nötigenfalls auch wenn das bedeutet, dass du nicht jeden relevanten Aspekt beleuchten kannst. Es ist nicht zielführend, die Leser so mit Fakten zu bombardieren - und selbst ich hab manchmal Probleme, die Aufmerksamkeit dann lange genug aufrecht zu erhalten, um den springenden Punkt wirklich zu erkennen.

Ich versuche mich kürzer zu fassen.

Sehr gut, der Effekt ist spürbar ;) Tut mir leid, dass ich dafür jetzt so viel in die Tasten haue.

Wie ich sowohl in meinem Eröffnungsbeitrag als auch schon bei früherer Gelegenheit deutlich gemacht hatte, halte ich eine strikte Trennung zwischen dem ‚Sprachkern‘ von JavaScript (ECMAScript) und den verschiedenen nicht zur Sprache selbst gehörenden Schnittstellen für absolut unabdingbar, und ich hoffe, dass, zumindest was dieses Ziel angeht, soweit Konsens besteht.

Leider nein. Zumindest nicht mit mir. Leider wirklich absolut nicht.

Ok.

Worauf du rausmöchtest, wenn ich mal etwas übertrieben formulieren darf ist, dass wir im Wiki in Zukunft eine Einführung in ECMAScript haben und eine Einführung in die diversen APIs haben werden.

Das habe ich an keiner Stelle behauptet. Allgemein gefasste Artikel wie Tutorials oder solche zum Thema Anwendung und Praxis beziehen natürlich Aspekte aus den verschiedensten Teilbereichen mit ein. Das ist so und sollte sich auch nicht ändern.

Okay, dann ist der Extremfall, den meine Kritik unter anderem beschreibt, vom Tisch.

JavaScript mag aus diesen Bestandteilen bestehen, daraus lässt sich aber keine Notwendigkeit ableiten, die Bestandteile einzeln zu behandeln.

Wieso entweder oder? Die Bestandteile sollten einerseits einzeln behandelt, andererseits aber natürlich auch in allgemeineren Artikeln im Gesamtkontext dargestellt werden. Wo ist da der Widerspruch?

Darin steckt kein Widerspruch. Die Frage ist nur, nach welchem Leitbild (Einzelteile vs. Gesamtkonzept) sich die Struktur richten sollte (was aber auch von weiteren Faktoren abhängt). Dass der Inhalt der Artikel nicht nur differenzieren darf, sondern sogar sollte, hatte ich ja durchaus auch geschrieben.

TL;DR: Tut mir leid, ich bin an allen Stellen dagegen, die Trennung zwischen den Einzelteilen zu thematisieren, in denen die Zugänglichkeit zum Verständnis des Gesamtbilds dadurch verkompliziert wird - was der Fall ist, wenn die Struktur darauf angepasst wird.

Also um noch mal kurz zum Vergleich meinen Vorschlag einzufügen:

Ich springe schon hier, vor dem Vorschlag, ein. Ich möchte noch einmal betonen, dass mein vehementer Widerspruch sich vor allem gegen das von dir formulierte Grundprinzip "strikte Trennung zwischen ECMAScript und APIs" richtet - sinngemäß und Hervorhebung von mir.

Strikte Trennung zu fordern (Stichwort unabdingbar) ist nämlich das, was ich an anderer Stelle mit dem Wort "zelebrieren" bedacht habe.

Wenn es darum geht, den Unterschied zwischen ECMAScript und APIs zu thematisieren, egal in welcher Form, wäre ich grundsätzlich schon bei dir.

Eine strikte Trennung, auch in der Struktur, ist aber nur dann sinnvoll, wenn die Dinge auch getrennt gehören. Also, strikte Trennung wie in "strikte Trennung zwischen Inhalt und Darstellung" oder so. Im Fall JavaScript ist es aber doch so, dass ECMAScript und APIs nur zwei Teile eines Ganzen sind, die nur in ihrer Gesamtheit die Bezeichnung JavaScript rechtfertigen.

Man kann in so einem Fall vielleicht Unterschiede herausarbeiten oder die Herkunft einzelner Eigenschaften/Methoden klarmachen, aber sicher keine strikte Trennung begründen.

Darauf vor Allem war mein vehementer Protest bezogen, vielleicht habe ich mich auch zu stark an dieser einen Aussage (die ich so einfach nicht stehen lassen konnte/kann) aufgehängt. Sollte ich deine Aussage hier in ihrer Schärfe (strictness :P) überbewertet haben, tut es mir leid.

Eine Anpassung der Struktur dahingehend, dass sie Elemente zugunsten der Übersichtlichkeit gruppiert (auch anhand der Spec, in der die jeweiligen Elemente definiert sind) ist nicht per se schlecht; das muss konkret beleuchtet werden (was ich bisher nicht getan habe).

Nun konkret zu deinem Vorschlag, zu dem ich mich bisher nicht geäußert hatte.

[...Vorschlag...] Dadurch findest du wird die „Zugänglichkeit zum Verständnis des Gesamtbildes verkompliziert“?

Ja, in gewisser Weise, siehe unten.

Ich nehmen an, du hättest es also lieber nach dem Schema:

Objekte

[...alles in einem Topf...]

Nein.

Ich würde meinen, hier geht die Übersicht flöten.

Richtig.

Wir müssen nicht darüber diskutieren, dass die Vielzahl von Objekten strukturiert werden sollte, nein, muss. Wir müssen auch nicht darüber diskutieren, dass deine Anordnung der Objekte fachlich sinnvoll ist.

Wir müssen aber darüber diskutieren, wie weit die Strukturänderung gehen muss und ob diese Strukturänderung auch didaktisch sinnvoll ist. Für die Portalseite halte ich eine Struktur, wie du sie vorschlägst für prinzipiell denkbar. Hier wird man sonst, wie du richtig sagst, von der Vielzahl unstrukturierter Objekte überrannt. Ich bin prinzipiell also durchaus bei dir - allerdings nicht weil ich denke, dass das aus Prinzip getrennt werden muss (so hatte ich dich verstanden), sondern weil ich überzeugt bin, dass man sonst von der Fülle der Einträge unnötig überwältigt wird und die Trennung nach ECMAScript und APIs eine sinnvolle Möglichkeit (von mehreren) ist, wenn man denn trennen muss.

Jetzt dazu, warum ich die Trennung wie du sie vorschlägst für potenziell unzugänglich halte.

Sobald wir uns auch nur einen Millimeter von den unterschiedlichen Specs weg und zur tatsächlichen Praxis hinbewegen, wird die Verflechtung vom JavaScript-Sprachkern mit dem DOM sehr stark. window entspricht in der Praxis de facto dem globalen Objekt und die Objekte der APIs befinden sich damit auf Augenhöhe mit den Objekten des Sprachkerns.

Ich hatte vorher, was vielleicht untergegangen ist, die Frage in den Raum gestellt, welcher praktische Unterschied zwischen ECMAScript-Objekten wie String und DOM-Objekten wie document besteht. Und die Antwort ist mMn: eigentlich keiner. Natürlich gibt es viele Unterschiede in Funktionalität , Ursprung, Benutzbarkeit außerhalb des Browsers, aber im Browser sind es im Prinzip einfach nur zwei unterschiedliche Objekte im globalen Raum.

Da also die Frage, aus welchem Spezifikationssatz ein Objekt stammt, nicht weiter relevant zu sein scheint ist doch die Frage, warum wir unsere Struktur daran ausrichten sollen - und nicht an anderen Kriterien, die vielleicht näher am Endanwender sind, der sich nicht zwangsläufig für die Spezifikationshierarchie interessiert (und das, mangels praktischer Relevanz, eigentlich auch nicht muss).

Einfaches Beispiel zur Illustration: JavaScript/Browser_APIs/DOM/Event ist für mich nicht besonders zugänglich oder intuitiv - das ist schon sehr tief in der Hierarchie für ein Element von JavaScript, das in der Praxis eine sehr große Bedeutung hat. Ich gehe soweit mit, dass JavaScript/Event (die aktuelle Lösung) auch nicht optimal ist. Für intuitiv würde ich hier halten: JavaScript/DOM/Event. Die Zuordnung von Event zu DOM ist sinnvoll, aber die Information, dass DOM streng genommen eine API ist, ist weder intuitiv noch Endbenutzer-relevant.

Aus dem selben Grund würde ich die Drag & Drop-API intuitiv wohl eher unter JavaScript/Drag & Drop einordnen, als unter (wie im Moment) JavaScript/API/Drag & Drop. Auch hier halte ich die Information, dass es sich um eine API handelt, für irrelevant.

Tatsächlich würde ich auch all die Objekte, die du unter Standard_APIs zusammengefasst hast, so zusammenfassen - allerdings aus anderen Gründen. Mir geht es nicht darum, wo die Objekte definiert sind, sondern was sie tun - und diese Objekte erfüllen einen ganz bestimmten Zweck, sie stellen elementare Funktionalitäten bereit. Ich würde sie deshalb aber nicht Standard_APIs nennen, sondern, nach ihrer Funktion, ganz banal "Sprachkern", oder "Kernobjekte" oder "primitive Objekte" (wegen mir auch "Standardobjekte") - darunter kann man sich als Endanwender dann auch deutlich mehr praktisch vorstellen.

Vielleicht an dieser Stelle nochmal, weil meine Kritik jetzt vielleicht etwas klarer wird: Ich kritisiere nicht die Idee, eine (Um-)Strukturierung vorzunehmen, sondern ich kritisiere, dass sich eine Strukturierung nach Spec sehr viel weniger eignet als eine Strukturierung, die sich tatsächlich am Bedürfnis des Endanwenders orientiert.

Umrissen könnte ich mir einen ähnlichen Vorschlag wie deinen vorstellen, allerdings von anderen Motiven geleitet:

Primitive Objekte

• Array
• ArrayBuffer
• Boolean
• DataView
• Date
• Function
• Generator
• Map
• Math
• Number
• Object
• Promise
• Reflect
• RegExp
• String
• Symbol
• TypedArray

DOM

• Document
• Element
• Event
• EventTarget
• Node
• Range
• Selection

Browser-Objekte

• Window
• Screen
• Navigator
• History
• Location

Schnittstellen

• Canvas 2D
• Console
• Drag & Drop
• File Upload
• Geolocation (usw.)

Wie gesagt, nur mal ins Blaue geschossen, mit eher Funktions-orientierter Sortierung bzw. Bezeichnung, orientiert an dem Endanwender, der die Portalseite nachher besucht.

Und auch da ist dann die Frage: Reicht es nicht vielleicht sogar, die Übersichtsseite so zu strukturieren und die URLs ganz simpel, flach zu machen, also tatsächlich alles mit

Javascript/...
...Array
...document
...event
...Navigator
...Drag & Drop
...usw-usf.

Denn während mir für die Portalseite einleuchtet, dass eine Nutzerführung und Ordnung der Objekte sinnvoll ist, so muss das nicht unbedingt auch für die tatsächliche Strukturierung gelten. Hier greift das Argument der Übersichtlichkeit mMn nicht mehr - und damit gewinnt für mich im Fall der URLs/Seitentitel die Sichtweise "Event ist genauso ein Sprachelement von JavaScript wie Array" die Oberhand, aber wie gesagt, nur weil mir da kein Grund einfällt, der für die Änderung der Seitentitel spricht, heißt nicht, dass es keinen gibt...

In meinen Augen stellt eine rein optische, nach Sichtweise der Funktionalität geordnete Struktur der Links auf der Portalseite gepaart mit konsequent flacher Hierarchie einen Zustand dar, der alle Bedürfnisse befriedigen sollte - außer dem nach einer Widerspiegelung der Trennung zwischen ECMAScript und APIs, welches aber mMn so gut wie nichts mit Gründen aus der Praxis zu tun hat.

[...] sollte dein Ansatz wirklich die Mehrheitsmeinung hier darstellen [...]

Mein Ansatz und meine Meinung sind gewöhnlich nicht deckungsgleich mit der Mehrheitsmeinung und zudem grundsätzlich offen für Diskussionen.

Grüße,

RIDER