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?

Jetzt mitmachen!