Webentwicklung ohne JavaScript – möglich oder längst unrealistisch?

KlartextKai

Moin, ist Webentwicklung ohne JavaScript heute noch realistisch – oder verbaut man sich damit zu viel? Klassische serverseitig gerenderte Seiten, Formulare und progressive Enhancement funktionieren weiterhin, gerade bei Blogs, Dokumentationen, Shops oder Verwaltungsoberflächen. Für komplexe Echtzeit-Apps, interaktive Dashboards und viele UI-Komponenten wird es ohne clientseitige Logik allerdings schnell unbequem.

Ich frage mich trotzdem, ob JavaScript inzwischen zu oft reflexartig eingesetzt wird, obwohl HTML und CSS reichen würden. Mehr Robustheit, bessere Ladezeiten und weniger Datenschutzbaustellen sprechen dafür. Wie viel Interaktivität braucht eine moderne Website wirklich, und wo zieht ihr die Grenze? Was meint ihr dazu?

Micha

Bei meinen kleinen, selbst erstellten Projekten habe ich bisher so gut wie nie Javascript eingesetzt. Mit dabei waren zwei Blogs, ein Miniforum, der Webauftritt einer kleinen Imbissbude und ein Webring. PHP, HTML, MySQL und CSS waren damals die Mittel zum Ziel.

Mir ging es dabei in erster Linie um die Einfachheit und die Tatsache, dass viele meiner Bekannten und auch ich selbst dauerhaft mit "No Script" als Browser-Addon im Netz unterwegs waren. Vielleicht sollte ich aber auch erwähnen, dass dies bereits vor über 25 Jahren war.

KlartextKai

25 Jahre später ist der Grundgedanke erstaunlich aktuell. Für Blog, Imbissseite oder Forum braucht man wirklich kein JavaScript; serverseitige Formulare, sauberes HTML und etwas CSS erledigen den Job robust. Ich habe bei einer kleinen Vereinsseite testweise erst alles ohne JS gebaut und später nur ein paar Komfortfunktionen ergänzt – am Ende war die Grundversion sogar angenehmer zu warten.

Der Unterschied zu damals ist eher, dass Nutzer heute an Live-Suche, Filter ohne Neuladen, Autovervollständigung und sofortige Rückmeldungen gewöhnt sind. Das heißt aber nicht, dass gleich eine komplette SPA nötig ist. Ich würde JS als optionale Verbesserung behandeln: Die Kernfunktion muss per Link, Formular und Server funktionieren, alles Weitere darf schneller oder bequemer werden. Gerade bei internen Tools sehe ich allerdings kaum noch einen echten Vorteil darin, komplett darauf zu verzichten – dort zählt die Interaktion oft mehr als maximale Einfachheit.

KlartextKai

…Ergänzung behandeln, nicht als Fundament. Die Seite sollte auch ohne funktionieren: Links bleiben Links, Formulare werden serverseitig verarbeitet, und JavaScript verbessert höchstens Suche, Filter oder Vorschauen. Gerade bei Formularen sehe ich oft das Gegenteil: Die clientseitige Validierung ersetzt die serverseitige, obwohl sie sich problemlos umgehen lässt.

Der Knackpunkt ist für mich weniger „JavaScript ja oder nein“, sondern ob die Anwendung ohne JavaScript noch sinnvoll nutzbar bleibt. Mit kleinen Inseln, etwa für Autovervollständigung oder einen Warenkorb, bekommt man meist einen guten Mittelweg hin. Baut ihr solche Funktionen eher selbst mit etwas Vanilla-JS oder greift ihr inzwischen zu HTMX, Alpine.js & Co.?

Kaffeekeks

…solche kleinen Inseln auch bewusst getrennt, oder landet am Ende doch wieder alles in einem großen Frontend-Bundle? Genau da wird es meiner Erfahrung nach schnell ungemütlich: Aus „nur Autovervollständigung“ werden fünf Bibliotheken, ein Build-Schritt und 300 KB JavaScript für ein Eingabefeld.

Für mich ist progressive Enhancement deshalb der vernünftigste Mittelweg. Die serverseitige Version ist die funktionierende Basis, JS darf sie bequemer machen. Bei einem Warenkorb kann das etwa ein schnelles Aktualisieren ohne Seitenreload sein – aber ein normaler Formular-Submit sollte trotzdem noch gehen. Ein bisschen weniger Magie ist im Web oft erstaunlich wartungsfreundlich.

KlartextKai

…oft tatsächlich mehr wert als die vermeintlich moderne Lösung. Ich würde zusätzlich zwischen funktionaler Abhängigkeit und Komfort unterscheiden: Wenn JS nur den Warenkorb schneller aktualisiert, ist ein Ausfall ärgerlich, aber beherrschbar. Wenn ohne JS weder Navigation noch Login noch Bestellabschluss funktionieren, ist das Design schlicht zu eng an den Client gekoppelt.

Bei kleinen Inseln hilft auch eine harte Grenze: kein globales Framework, kein zentraler Zustand, pro Funktion ein kleines Modul und nur dort laden, wo es gebraucht wird. Gerade bei Formularen kann man außerdem mit HTML-Attributen, serverseitigen Redirects und gezieltem Nachladen erstaunlich weit kommen. Die spannende Frage ist dann eher: Ab wann lohnt sich der zusätzliche Komfort wirklich gegenüber der zusätzlichen Komplexität?

Kaffeekeks

…und Fehlermeldungen oft schon erstaunlich weit kommen, bevor überhaupt eine Zeile JavaScript nötig ist. Für mich ist die eigentliche Kunst, den Rückfall nicht nur theoretisch einzubauen, sondern auch mal wirklich zu testen. „Sollte ohne JS funktionieren“ ist schnell gesagt, wenn man den No-Script-Modus seit drei Monaten nicht mehr gesehen hat.

Ganz ohne JS würde ich heute trotzdem nicht mehr als allgemeines Ziel formulieren. Bei einer Anwendung mit Drag-and-drop, Live-Daten oder umfangreicher Tabellenbearbeitung wird serverseitiges Neuladen irgendwann zur Geduldsprobe. Da darf der Browser ruhig ein bisschen arbeiten. Nur sollte man dann auch ehrlich sagen: Das ist eine clientseitige Anwendung und kein Blog mit drei zusätzlichen Skriptdateien.

Interessant finde ich dabei Ansätze wie htmx oder schlicht kleine Fetch-Module. Die liegen irgendwo zwischen klassischem Formular und SPA und können ganz praktisch sein. Aber auch da kann man sich natürlich wieder eine neue Abstraktionsschicht ins Haus holen, die später niemand mehr anfassen möchte. Das Web hat ja eine bemerkenswerte Begabung, aus einer simplen Schaltfläche ein Architekturdiagramm zu machen.

Ich würde als Test inzwischen nicht nur „JavaScript deaktiviert“ nehmen, sondern auch langsames Netz, Tastaturbedienung und einen kaputten Request. Wenn dann noch klar ist, was passiert, ist die Lösung meistens ziemlich solide. Gibt es bei euch einen Punkt, an dem ihr bewusst sagt: Hier ist progressive Enhancement vorbei und wir bauen lieber konsequent eine JS-Anwendung?

KlartextKai

…sollte man dann auch ehrlich sagen: Das ist eine clientseitige Anwendung und keine klassische Website mit ein paar Extras. Für solche Fälle ist „ohne JS“ kein sinnvolles Qualitätsziel, wohl aber ein sauberer Umgang mit Ausfällen, langsamen Geräten und deaktivierten Skripten. Ein verständlicher Fehlerhinweis ist besser als eine leere Oberfläche.

Den No-JS-Rückfall würde ich inzwischen sogar in den Testprozess aufnehmen: wichtige Seiten einmal mit deaktiviertem JavaScript durchklicken, Formulare abschicken, Login und Bestellablauf prüfen. Nicht jede Komfortfunktion muss dabei erhalten bleiben, aber Kernaufgaben schon. Macht ihr solche Tests manuell oder habt ihr dafür schon Checks in der CI?

Kaffeekeks

…macht ihr das wirklich regelmäßig oder bleibt es meistens bei Lighthouse und ein paar automatisierten Tests? Ich erwische mich jedenfalls dabei, den No-JS-Fall erst dann zu prüfen, wenn irgendwo ein Kunde mit leerer Seite auftaucht – sehr wissenschaftlich ist das nicht.

Bei neuen Projekten lege ich inzwischen zuerst fest, welche Kernaktionen ohne Skripte funktionieren müssen, und teste genau diese mit deaktiviertem JavaScript. Für alles andere reicht dann ein sauberer Fehlerzustand. Das ist irgendwie entspannter, als nachträglich aus einem gewachsenen Frontend wieder eine Website herauszuoperieren.

Jetzt mitmachen!