JavaScript allein mit HTML ersetzen

• Stellt aktuelle Methoden vor, mit denen sich von JS abhängige Funktionen im Web durch HTML/CSS ersetzen lassen
• Mit Standard-Elementen wie details·summary, datalist und popover lassen sich Akkordeons, Autovervollständigung, Modals und Offscreen-Navigation umsetzen
• Dieser Ansatz reduziert Download-, Auswertungs- und Speichernutzung und verbessert so Performance und User Experience
• Zu jeder Funktion werden CodePen-Beispiele, MDN-Dokumentation und Informationen zur Browser-Kompatibilität bereitgestellt
• JS sollte nur dort eingesetzt werden, wo es wirklich nötig ist, und die fortgeschrittenen Funktionen von HTML/CSS sollten aktiv genutzt werden

---

JS-Funktionen durch HTML und CSS ersetzen

• JavaScript war lange Zeit für Funktionen zuständig, die sich nicht mit HTML und CSS umsetzen ließen
  • Mit dem erweiterten Funktionsumfang von HTML und CSS lassen sich jedoch einige JS-Funktionen heute durch native Webtechnologien ersetzen
• Da JS heruntergeladen, entpackt, ausgewertet und im Speicher gehalten werden muss, ist es effizient, geeignete Funktionen auf HTML/CSS zu verlagern
• Vorgeschlagen wird ein Ansatz, bei dem sich JS auf komplexe Logik konzentriert und einfache UI-Steuerung an HTML/CSS delegiert wird

Akkordeon / erweiterbare Inhaltsbereiche

• Mit den Elementen details und summary lassen sich Akkordeons ohne JS umsetzen
  • Inhalte können per Klick geöffnet und geschlossen werden, und mit dem Attribut open lässt sich der Standardzustand festlegen
  • Wird dasselbe Attribut name verwendet, kann nur ein Panel gleichzeitig geöffnet sein
• Das Styling ist per CSS möglich, ebenso eine Steuerung des Öffnens/Schließens per JS
• Verwandte Ressourcen: MDN-Dokumentation zu details, CodePen-Beispiel, Browser-Kompatibilitätstabelle

Eingabefeld mit Autovervollständigungs-Vorschlägen

• Mit der Kombination aus input und datalist lässt sich ein automatisch gefiltertes Dropdown umsetzen
  • Beim Eingeben wird die Vorschlagsliste automatisch gefiltert
  • Unterstützt neben Text auch verschiedene Eingabetypen wie number, time usw.
• Firefox unterstützt derzeit nur textbasierte Eingaben, außerdem gibt es Einschränkungen bei der mobilen Barrierefreiheit
• Verwandte Ressourcen: MDN-Dokumentation zu datalist, SitePoint-Tutorial, Browser-Kompatibilitätstabelle

Modal / Popover

• Mit den Attributen popover und popovertarget lassen sich Modals und Popover ohne JS umsetzen
  • Es gibt drei Modi: auto, hint und manual
  • auto wird durch Klick außerhalb oder ESC geschlossen, manual nur manuell
• Firefox und iOS unterstützen den Modus hint nicht
• Verwandte Ressourcen: MDN-Dokumentation zu popover, Chrome-Blog, CodePen-Beispiel, Video zur Barrierefreiheit

Offscreen-Navigation / Offscreen-Inhalte

• Mit der popover-Funktion lässt sich ein Offscreen-Navigationsmenü umsetzen
  • Mit dem Element nav wird semantische Bedeutung gegeben, per CSS translate wird es in und aus dem sichtbaren Bereich bewegt
  • Es schließt sich bei Klick außerhalb, und mit popover="manual" kann manuelles Schließen festgelegt werden
  • Mit dem Pseudoelement ::backdrop lässt sich der Hintergrund halbtransparent gestalten
• Verwandte Ressourcen: MDN Popover API, Chrome-Blog, CodePen-Beispiel

Fazit

• Die Stärke von JS wird anerkannt, es sollte jedoch nur dort eingesetzt werden, wo es nötig ist
• Durch die jüngsten Fortschritte bei HTML/CSS sind zahlreiche Alternativen ohne JS entstanden
• Weitere Beispiele finden sich im Blogbeitrag des Autors „Replace JS with No-JS or Lo-JS Options“
• Betont wird eine bessere User Experience durch Minimierung von JS und Performance-Optimierung

[skageektp]

Mit den Elementen ** und ** lässt sich ein Akkordeon ohne JS umsetzen

Irgendwie wirkt es, als würde Inhalt fehlen.

[xguru]

Ich habe es angepasst~!

[shakespeares]

Es gibt offensichtliche Grenzen, und in dem Moment, in dem KI aktiv wird … ist so ein Refactoring dann überhaupt noch nötig?
Wurde dabei auch so etwas wie das Blockieren von JS-Inhalten berücksichtigt?

[GN⁺]

Meinungen auf Hacker News

• Schade, dass nicht alle Beispiele inline eingebettet wurden
  Statt nur auf CodePen zu verlinken, hätte es viel überzeugender gewirkt, die HTML-Alternativen direkt auf der Seite zu zeigen
  • Sehe ich genauso. Oft klickt man auf so etwas wie FooMaker v1.0 und bekommt statt eines normalen Anwendungsbeispiels nur abseitige Sonderfälle zu sehen
  • Ich dachte zuerst, der Artikel sei 25 Jahre alt. Das geditherte GIF hat totalen Retro-Charme
  • Mich hat das Fehlen von Inline-Beispielen auch genervt, aber wenn es ein Gast-Blogpost ist, kann ich es noch einigermaßen nachvollziehen
• Das Potenzial von <details> / <summary> ist wirklich enorm
  Damit kann man fast alles machen, aber die meisten Komponentenbibliotheken ignorieren das komplett
  Man braucht keine aria-Attribute, und Barrierefreiheit ist von Haus aus dabei
  • Früher war ein Nachteil, dass cmd+f Text in geschlossenen Details nicht finden konnte, aber das lässt sich inzwischen mit dem Attribut hidden="until-found" und Events lösen
  • Allerdings ist Animation knifflig. Browser unterstützen Transitions für display-Umschaltungen nicht standardmäßig
  • Es gibt auch die Funktion, dass sich Details bei einer Suche mit ctrl+f automatisch öffnen
  • <details> funktioniert auch auf Markdown-basierten Seiten wie GitHub. Damit kann man lange Logs einklappen und sauber posten
  • Man kann das auch mit reinem CSS umsetzen. In der Go101-Dokumentation kann man zum Beispiel mit „+“ aufklappen. Außerdem gibt es diese Tab-Panel-Demo. Das zeigt die Stärke von Modern CSS
• Der Punkt ist nicht „no JavaScript“, sondern dass HTML bereits vergessene Funktionen abdeckt, etwa Formulare, Dialoge, Validierung und Navigation
  Beim Schreiben des Buchs „You Don’t Need JavaScript“ habe ich gemerkt, dass JS oft nicht neue Funktionen hinzufügt, sondern eher die vorhandenen Fähigkeiten der Plattform ergänzt
  • Ich wünschte, es gäbe mehr Bücher dieser Art. Statt nur Frameworks zu lehren, braucht es Bücher mit Fokus auf Problemlösung
  • Früher war der Browser-Support schwach, deshalb haben Entwickler Workarounds gebaut, die sich dann wie Standards verfestigt haben. Inzwischen erscheinen neue CSS-Features schneller, und selbst Masonry-Layouts sind in die Experimentierphase gekommen
• Die meisten HTML-Funktionen sind großartig, aber <input> und <datalist> reichen für den Praxiseinsatz nicht aus
  Nutzer erwarten Tippfehlertoleranz, Hilfstexte und eine gute Mobile-UX, aber datalist erfüllt das nicht
  • Am nervigsten ist, dass man bei datalist Anzeigetext und tatsächlichen Wert (value) nicht trennen kann
  • In den meisten Fällen ist select passender, aber select hat keine Suchfunktion
  • Das Standard-Styling ist zu klobig und hässlich
  • Auf Android erscheint das Dropdown gar nicht
  • Es verhält sich je nach Gerät unterschiedlich, sodass man am Ende doch JS ergänzen muss. Mit reinem HTML landet man in der Kompatibilitätshölle
• Ich hatte zuletzt mehrere Frontend-Interviews, und immer noch wird fast nur React-zentrierte JS-Kompetenz bewertet
  Auf semantische HTML-Nutzung oder Barrierefreiheit wird kaum geachtet
  • Wenn ein Team React verwendet, kann jemand, der direkt mit der DOM-API arbeitet, bei der Team-Kompatibilität durchs Raster fallen
  • Mit einer separaten CSS-Datei werden Komponenten viel sauberer. Tailwind ist nicht schlecht, aber in einem Interview würde ich es nicht verwenden wollen
  • Außerhalb von HN interessiert sich fast niemand für HTML-Purismus
• Es stört mich, dass nur CodePen-Links gesetzt wurden und die Beispiele nicht direkt auf der Seite stehen
  In einem Artikel mit der Aussage „Lasst es uns nur mit HTML umsetzen“ wirkt die Abhängigkeit von einem externen Dienst widersprüchlich
  • Ich persönlich finde das okay. CodePen ist praktisch für Lesezeichen und Syntax-Highlighting. Es gibt aber das Risiko von Link Rot
  • Trotzdem wäre es schön gewesen, sowohl Inline-Beispiele als auch CodePen-Links beides bereitzustellen
  • Wenn man HTML predigt, aber dafür eine 2-MB-große CodePen-Oberfläche laden muss, ist das aus UX-Sicht paradox
• Ich freue mich auf die bald kommende Funktion für anpassbare select-Elemente
  Sie ist bei WHATWG in Stage 3 und könnte die albtraumhafte Implementierung von JS-basierten Dropdowns ersetzen
  Siehe dazu den Chrome-Blogbeitrag
• Reines HTML ist vertraut und angenehm, aber für funktionale Web-Apps von heute stößt es an Grenzen
  Ich habe auch Alternativen wie HTMX oder Phoenix LiveView ausprobiert, aber sie sind keine vollständige Lösung
  Letztlich scheint es realistischer, modernes JS zu akzeptieren
  • Schon mit ein wenig JS kommt man viel weiter als nur mit HTML. Das heutige Web leidet jedoch stark unter übermäßigem JS-Einsatz, der die Nutzbarkeit verschlechtert
  • HTMX wird wohl zu kompliziert gedacht. Wenn man sich am Serverzustand orientiert und hx-select / hx-target nutzt, kann man es einfach halten
  • Das Tag <marquee> eignete sich gut für horizontal scrollende Elemente in Shopping-Seiten, heute wird das mit Gewalt in JS nachgebaut. Ich wünschte, HTML würde mehr UI-Muster von Haus aus unterstützen
  • Ich habe viel Token verschwendet, als ich versucht habe, in React einen Marquee-Effekt umzusetzen. Es war keine perfekte Schleife, nur ein Animations-Hack
  • Wenn man Elixir und Phoenix nutzt, lohnt sich vielleicht auch ein Blick auf Gleam. Es kompiliert zu JS
• HTML und JS sind Werkzeuge mit unterschiedlichen Zielen
  Für komplexe Web-Apps ist JS unverzichtbar, aber es gibt viele Bereiche, in denen HTML allein ausreicht
  • Für etwas wie Google Earth braucht man natürlich JS, aber auf dem Niveau von Gmail wäre HTML meiner Meinung nach auch möglich. Trends und Hype der Browser-Anbieter bremsen die Weiterentwicklung von HTML
  • htmx steht zu JS in einer ergänzenden Beziehung. Im Kern geht es darum, statt JSON strukturierten Hypertext auszutauschen. Ich habe tatsächlich mit htmx plus etwas JS ziemlich komplexe Apps schnell gebaut
  • HTML sollte mehr Funktionen standardmäßig mitbringen, zum Beispiel Unterstützung für HTTP-Verben oder bessere Input-Controls
  • Viele JS-lastige Seiten ließen sich in Wahrheit gut durch htmx ersetzen. Die Werkzeugwahl ist oft eine Frage der Gewohnheit
• Ich stimme der Aussage zu, dass „JS keine Akkordeons oder Navigationsmenüs verwalten muss“
  Aber JS ist inzwischen zum zentralen Werkzeug für Datensammlung und Werbetracking geworden
  Ich frage mich, ob Big Tech ohne JS dieselbe Art von Überwachung und Werbediensten umsetzen könnte
  Letztlich kommt die Abneigung gegen JS nicht nur aus technischen Gründen, sondern aus Misstrauen gegenüber dem Werbeökosystem

[labeldock]

Solche Versuche lassen mich zwar gelegentlich darüber nachdenken, ob ich vielleicht overengineere, aber aus der Perspektive der praktischen Arbeit mit umfangreichen Anforderungen kommt das einem Zirkuskunststück nahe.