Aloha ;)

Eins hatte ich in meinen Betrachtungen bislang ausgespart: die Logik. Aber auch hier stellt sich eine Frage nach den grundsätzlichen Lernzielen. Es sollten doch sicher von Anfang an Daten und Darstellung getrennt sein; dem Anfänger das EVA-Prinzip vermittelt werden.

Ist es vor diesem Hintergrund wirklich ratsam, die Logik ans DOM zu koppeln? Also die Erkennung „3 in einer Reihe?“ anhand von Klassen der DOM-Elemente vorzunehmen?

Das Argument geht an der Realität vorbei. Vergiss nicht, dass wir hier von JavaScript sprechen, und gerade in diesem Beispiel von eindeutig clientseitigem JavaScript.

Abgesehen davon ist das, was du (denke ich) meinst, nicht wirklich das EVA-Prinzip - denn EVA ist ein Prinzip, dass grundsätzlich gilt, bei jeder Verwendung von JavaScript (egal, wie man programmiert) kommt EVA zum Tragen, das ist eine Frage der Architektur und nicht der Programmierung oder des zur Programmierung herangezogenen Pattern.

Du meinst wahrscheinlich eher die Trennung zwischen GUI und Geschäftslogik (sowie nötigenfalls [persistenter] Datenhaltung), die im Software Engineering oft günstig ist. Aber auch da würde ich im Fall von JavaScript - und besonders in diesem Beispiel - widersprechen. Die Trennung erfolgt aus dem praktischen Grund, dass ein Teil des Codes wiederverwendbar sein soll, selbst wenn die GUI ausgetauscht werden muss (also wenn z.B. eine native Smartphone-App und eine Weboberfläche auf die selbe Implementierung der Geschäftslogik zugreifen sollen). Im Fall von JavaScript ist das Grundsystem der GUI aber immer gleich - der Browser (denn im Allgemeinen sind clientseitige Skripte bzw. deren Aufgaben nicht identisch mit serverseitigen Aufgaben); lediglich die konkrete Darstellung kann sich ändern. Es fallen also schon viele gewichtige Gründe weg, da mit allzu großen Veränderungen auf der GUI-Seite gar nicht zu rechnen ist. Entkopplung ist immer aufwändig und lohnt sich nur dann, wenn auch ein entsprechender Nutzen zu erwarten ist. 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.

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, dass eine Kopplung zu Unübersichtlichkeit führen würde - selbst bei GUI-Änderung wären alle zu machenden Änderungen noch einfach nachvollziehbar; es ist also eben gerade kein Beispiel, an dem man den Sinn einer solchen Trennung erkennen kann. 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.

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, der auch tatsächlich genau dieses Ziel hat. Dann aber auch mit einer Diskussion, wann das zu verwenden sinnvoll ist und mit einem Beispiel, bei dem die Verwendung tatsächlich angebracht ist. Auch ein entkoppelndes Pattern ist mehr Gegenstand von best practice als tatsächlich Teil der Grundlagen oder des Anfängerwissens - und gerade hier noch viel stärker als bei der Barrierefreiheit, da letztere immer sinnvoll anzuwenden ist, ein entkoppelndes Pattern aber nur, wenn eine Verwendung auch sinnvoll ist (was hier, wie gesagt, nicht der Fall ist).

Grüße,

RIDER