Aloha ;)

Außerdem mutet es sowieso skurril an, wenn man im JS-Bereich eine Trennung von GUI und Geschäftslogik fordert, da JS eigentlich an sich ein integraler Bestandteil des GUI-Systems ist.

In der heutigen Anwendung von JavaScript (im Hinblick auf Dinge wie SPAs) ist diese Trennung nicht skurril, sondern essentiell.

Bei SPAs hast du vollkommen recht, das liegt aber daran, dass SPAs einen Spezialfall darstellen, der über die notwendigen Eigenschaften verfügt, die ein entkoppelndes Pattern sehr sinnvoll machen. Das ist, sozusagen, die sprichwörtliche Ausnahme von der Regel. Und, ich denke auch da sind wir uns einig: Der Einsatz von JavaScript, wie er in manchen SPAs geschieht, ist von grenzwertiger Sinnhaftigkeit - oder zumindest mit einem kleinen "Geschmäckle" versehen, dass das keine Anwendung von JavaScript im Sinne des Erfinders ist, wenn die SPA sich zu stark auf JavaScript verlässt. (Bei wenig JavaScript-Einsatz ist auch in SPAs eine solche Trennung nicht unbedingt geboten oder essentiell, es kommt hier auf den jeweiligen Ansatz an...)

So viel allgemein zu Trennung von GUI und Geschäftslogik im JS-Bereich. Und ganz abgesehen davon gibt es in diesem Fall noch mehr spezifische Argumente, die da widersprechen, vor allem: Das vorliegende System ist nicht komplex genug

Sind wir uns nicht einig darüber, dass der Artikel allgemeine Praktiken vermitteln soll und das Tic-Tac-Toe-Spiel nicht mehr und nicht weniger als der Aufhänger dafür ist?

Nein, sind wir nicht - zumindest nicht ohne nähere Spezifizierung. Der Artikel soll grundlegende Techniken vermitteln, die in JavaScript zum Einsatz kommen können. Insbesondere, so meine Lesart, geht es darum, verschiedene Sprachelemente in einem praktischen Beispiel kennen zu lernen. Der Fokus liegt dabei ganz deutlich bei Anfängern, die bisher kaum oder gar keine Erfahrung mit JavaScript als Sprache haben (sonst wäre die Kleinschrittigkeit der Erklärung auch nicht nötig). Allgemeine Praktiken oder gar best practice ist nichts, was darunter fällt, sondern vielmehr Teil des nächsten Schritts, also fortgeschrittener Stoff - denn um best practice verstehen und effektiv anwenden zu können, muss man zunächst die Sprache selbst beherrschen.

Du hast mit vielen von den Dingen, die du im Verlauf dieser Diskussion geschrieben hast, grundsätzlich Recht. Dir fehlt allerdings - meiner Meinung nach - in fast allem was du schreibst gleichzeitig auch der Blick auf den Anfänger oder überhaupt die Unterteilung in verschiedene Stufen des Lernens. Vielleicht macht folgende Überlegung meinen Punkt deutlich: Wenn ein Artikel für Anfänger folgendes vollumfänglich abdeckt

• Sprachelemente und Möglichkeiten
• Umgang mit der Sprache
• best practice

was beleibt dann für einen Artikel für Fortgeschrittene noch übrig? Nichts. Wenn jemand all die Punkte berücksichtigt, die du gerne im Artikel sehen würdest, dann wäre er schon auf dem Level eines Profis angelangt, denn was soll noch kommen, wenn man Barrierefreiheit, progressive enhancement und die zugehörigen Metaüberlegungen verinnerlicht hat?

Die Einordnung des Artikels als Anfängerartikel macht nur dann Sinn, wenn man sich auf ein Subset der möglichen Punkte beschränkt. Die anderen Punkte sollten dann selbstverständlich erwähnt oder weiterverlinkt werden, um den individuellen Lernfluss der Wissbegierigen nicht zu behindern, aber eben nicht direkt thematisiert oder gar in der grundlegenden Architektur berücksichtigt werden - denn sie sind nicht Gegenstand des Artikels für die ausdrücklich gewählte Zielgruppe.

Ob es nun Sinn macht oder nicht, die Zielgruppe zu wählen, darüber lasse ich gerne eine Diskussion zu (auch wenn ich dazu eine klare Meinung habe, das tut aber nichts zur Sache). Fakt ist aber, dass eine solche Einschränkung von Zielgruppe und Lernzielen formulierte Grundprämisse des gesamten Artikels ist und war, es ist also nicht wirklich sinnvoll, Kritik zu formulieren, die nicht von dieser Grundprämisse ausgeht - denn ohne Beachtung der Grundprämisse ist der ganze Artikel hinfällig. Es war ja auch insbesondere Kritik am konkreten Artikel gefragt, nicht Kritik an den zugrunde liegenden Randbedingungen^[1]. Letztere kann auch nicht wirklich Anlass dafür geben, den konkreten Artikel zu verändern, sondern müsste dann unter Aufstellung anderer Randbedingungen in einem anderen Artikel (gerne auch vom ersten inspiriert) beachtet werden.

dass eine Kopplung zu Unübersichtlichkeit führen würde […] Im Gegenteil, es ist sogar ein Gegenbeispiel, da eine solche Entkopplung auch wieder Komplexität erzeugt, die in diesem Fall die Komplexität des Gesamtentwurfs mindestens verdoppelt - ohne, dass das nötig wäre.

Das glaube ich nicht. Wie gesagt würde sich der Code zur Erkennung des Spielendes sogar vereinfachen.

Doch - weil du durch die Entkopplung eine eigenständige Komponente dazuerhältst, nämlich die, die die GUI anhand dessen, was die Geschäftslogik errechnet, steuert. Bisher ist dieser Teil in die Geschäftslogik integriert, was zwangsläufig im Gesamtentwurf weniger komplex ist. Es ging mir nicht darum, dass zwangsläufig der Code jeder Einzelaktion komplizierter wird - tatsächlich hast du Recht, dass die Analyse der Daten bei anderer Repräsentation eventuell (!) weniger komplex ist - sondern es ging mir um die Komplexität der Architektur der Lösung. Und die steigt, weil ein Teil dessen, was bisher geschieht, losgelöst, gekoppelt und entsprechend per Schnittstelle angeschlossen werden muss (denn gerade die Bereitstellung einer Schnittstelle, die GUI und Geschäftslogik verbindet und nötigenfalls auch die Geschäftslogik mit einer anderen GUI verbinden kann, ist ja gerade der Kern des Pudels).

Das ist doch genau der Trade-Off, den man sich mit einem entkoppelnden Pattern zunutze macht: Man erhöht die Komplexität des Entwurfs (Architektur) und erhält dafür einfachere Wartbarkeit und Austauschbarkeit von Code, denn nur um letzteres kann es bei einem solchen Pattern gehen. Und genau das ist in diesem konkreten Fall eben nicht gerechtfertigt, weil sich der Trade-Off nicht auszahlt.

Können wir uns am konkreten Beispiel ansehen, wenn ich (oder jemand anderes?) – wie von Felix angeregt – dazu komme, das beispielhaft zu implementieren.

Wie gesagt - es ging mir vor allem auch um die Komplexität des Entwurfs, nicht so sehr um die Komplexität der Implementierung. Dass der Entwurf komplexer wird, sollte offensichtlich sein, denn jede Funktionalität, die bisher die GUI wie-auch-immer-geartet verändert muss in einem entkoppelten Entwurf nach wie vor existieren (und die austauschbaren GUI-Funktionen aufrufen, Stichwort Schnittstelle) während die gesamte Verwaltung der GUI als handelnde Komponente dazukommt.

Wenn der Nutzen einer Entkopplung gelernt werden soll, dann muss das (wie @Felix Riesterer im Zusammenhang mit der Barrierefreiheit schon richtig sagte) Teil eines (eigenen) Artikels sein,

Wenn es Ziel des Artikels ist, allgemeine best practices zu vermitteln, dann gehört das in den Artikel; nicht in einen anderen.

Dass eben das nicht der Fall ist hatte ich schon ursprünglich angedeutet und oben noch einmal ausführlich begründet. Es ist zwar schon Ziel des Artikels, auf allgemeine best practices zu verweisen, wo sich das anbietet, allerdings nicht, diese direkt zu vermitteln.

Und Barrierefreiheit gehört (wie ich schon richtig sagte) auch rein. Felix irrt an dieser Stelle grundsätzlich. (Sein Posting harrt noch der Beantwortung.)

Wie gesagt - ich bin in dem Fall auch Felix Meinung. Ich glaube eher, dass du nach wie vor die Zielsetzung des Artikels nicht verstanden hast, da die von dir verfolgten Ziele (so richtig sie auch sind) nicht damit übereinstimmen. Das kann auch daran liegen, dass du den Bedarf für einen Artikel mit der Zielsetzung, die hier gewählt wurde, nicht so recht siehst. Meiner Einschätzung nach (ich kann falsch liegen) liegt das aber nicht daran, dass es den Bedarf nicht geben würde, sondern vielmehr damit, dass du eher weniger oft mit blutigen Anfängern zu tun hast, die erstmal die technischen Möglichkeiten kennenlernen müssen und durch weitergehende Überlegungen überfordert bis abgeschreckt werden. Beispiel für jemanden aus dieser Zielgruppe: Ein vierzehnjähriger Schüler, für den JavaScript die erste Programmiersprache überhaupt darstellt. Oder ein Uni-Student, der zwar schon programmiert hat, aber auf einmal was mit Webtechnologien machen soll und keine Ahnung hat, wie man (technisch) mit JavaScript eine Webseite dynamisch verändern kann. Und tatsächlich sind beide auch Teil unserer Zielgruppen als Selfhtml. Natürlich muss man auch denen irgendwann fortgechrittene Konzepte vermitteln - aber nicht von Anfang an ausführlich, weil die Lernkurve sonst viel zu steil ist. Es ist doch gerade unser Ziel, Leute für Webtechnologien zu begeistern - das funktioniert aber nur, wenn am Anfang (Stichwort "Anfänger") nicht Frustration aufkommt, weil der Berg dessen, was man auf einen Schlag vermittelt bekommt, die Kapazitäten übersteigt.

Klar, manche werden damit dennoch gut umgehen können. Andere gar nicht. Gerade deshalb ist es doch sinnvoll, Erwähnungen und weiterführende Links einzubauen, statt direkt im Artikel auf die fortgeschrittenen Konzepte einzugehen - damit jeder Lerner individuell entscheiden kann, ob er sich direkt mit fortgeschrittenen Konzepten befassen möchte oder eben erst später mit mehr Eigenerfahrung und einem Verständnis der Sprachgrundlagen.

Grüße,

RIDER