Aloha ;)

Du meinst vermutlich nicht primitiv sondern sowas wie "allgemein". Und damit gehören sie mehr zum Kern der Sprache, weil sie neben den Kontrollstrukturen einigermaßen essentiell sind. Ohne sie kann man keine Javascript-Programme erstellen, ohne die anderen APIs aber schon.

Genau das, mir fehlt nur der passende/griffige Bezeichner dafür, deshalb habe ich zu "primitive Objekte" gegriffen, finde aber z.B. "Kernobjekte" oder "Sprachkern" auch gut/besser - oder gerne auch einen anderen Begriff, der die Aussage griffig rüberbringt :)

Da wir uns aber vorwiegend um im Browser ablaufendes Javascript und weniger um serverseitiges kümmern werden, würde ich neben diesen allgemeinen auch noch die anderen allgemeinen browserspezifischen Objekte zumindest in ihrer unmittelbaren Nähe aufführen. Etwas abseits davon kämen die themenorientierten APIs an die Reihe.

Ja, halte ich für sinnvoll.

Man kann ja mal einen Abstecher ins PHP-Manual werfen. Auch da gibts die allgemeinen Sprachelemente (Language Reference) und mehr oder weniger themenspezifisch die Function Reference. Der Anfänger mag da noch keine große Unterscheidung treffen, aber als Fortgeschrittener wird man diese schätzen.

Das war ungefähr das, was ich meinte mit

Wir müssen nicht darüber diskutieren, dass die Vielzahl von Objekten strukturiert werden sollte, nein, muss.

​

Es wäre auch schön, nicht nur die Anfänger anzusprechen, sondern auch den Fortgeschrittenen noch einen Grund zu bieten, nicht gleich zum MDN zu verschwinden. Insofern sollten wir nicht nur eine homogene Masse sondern unterschiedliche Bedürfnisse berücksichtigen und da einen guten Kompromiss finden.

Selbstverständlich. Ich habe absichtlich nicht von "Anfänger" sondern von "Endanwender" gesprochen - auch wenn sich das vielleicht in meinem Vorschlag eher wie "Anfänger" angehört hat. Natürlich sollten wir beide ins Boot holen.

Allerdings ist die Unterscheidung zwischen ECMAScript und APIs mMn auch für einen Fortgeschrittenen nicht von großer Bedeutung, da darf man aber gerne auch anderer Meinung sein ;)

AFAIS ist der einzige Punkt, an dem man als Anwender diese Unterscheidung benötigt der, an dem man selbst was in einer Spec nachschlagen möchte. Und das betrifft dann, so wie ich das sehe, wirklich erst die Profis; die profitieren dann aber gar nicht mehr von einer Abbildung der Spec-Realität in der Struktur, weil sie im Zweifelsfall ja dann doch eher nicht bei uns ins Wiki schauen. Deshalb: Spec-Zuordnung in den Inhalt des Artikels, gerne auch gut sichtbar, sodass man im Zweifelsfall auch herausfindet in welcher Spec man nachschauen muss, aber nicht überrepräsentieren und die Struktur da unbedingt reinpressen.

Vielleicht nicht ganz flach, denn davon hängt auch die Brotkrümelnavigation ab, bei der es durchaus bei einigen Themen sinnvoll ist, nicht nur generell zu "Javascript" zurückspringen zu können. Zu lang sollte die URL und damit die Navigation aber auch nicht werden. Insofern ist sicherlich der URL-Bestandteil Browser-API verzichtbar, DOM aber eher nicht.

FACK. Der "ganz flache" Gegenvorschlag war auch nur das andere Extrem, ein wohl durchdachter Mittelweg wäre wünschenswert.

Grüße,

RIDER