Plain Vanilla Web

 (plainvanillaweb.com)
2 Punkte von GN⁺ 2025-05-12 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Erklärung grundlegender Webentwicklungstechniken, die nur HTML, CSS und JavaScript verwenden
  • Einführung in Methoden zur Umsetzung von Websites und Anwendungen ausschließlich mit standardisierten Webtechnologien, ohne Build-Tools und Frameworks
  • Behandelt Strukturierung und Styling mit Web Components und modernen CSS-Funktionen
  • Verfolgt eine einfache Entwicklungsumgebung und langfristige Vorteile ohne die Komplexität von Frameworks und den Wartungsaufwand
  • Ein Tutorial, das sich in erster Linie an Entwickler richtet, die Webstandards bereits beherrschen

Überblick über Plain Vanilla Web

Ein Überblick über die wichtigsten Techniken zum Erstellen von Websites und Anwendungen ausschließlich mit standardisierten Webtechnologien, ohne Build-Tools und Frameworks

  • Beschreibt eine Umgebung, die nur Editor, Browser und Webstandards nutzt
  • Stellt eine Struktur vor, die Deployment in Produktionsumgebungen ohne anfängliche Konfiguration und serverseitige Logik ermöglicht

Behandelte Themen

1. Komponenten (Components)

  • Zeigt, wie sich mit Web Components hochstufige Bausteine allein aus HTML, JavaScript und CSS zusammensetzen lassen
  • Eine Methode als Alternative zum Komponentenansatz von Frameworks wie React oder Vue

2. Styling

  • Zeigt, wie sich die Stärken von modernem CSS nutzen lassen, um den Komfort von CSS Modules, PostCSS und SASS zu ersetzen
  • Vermittelt Konzepte für strukturierte und modulare Styles jenseits von klassischem CSS

3. Websites (Sites)

  • Zeigt, wie sich Webprojekte auf Basis von Web Components aufbauen und ohne Build-Tools oder Server-Side-Code deployen lassen
  • Stellt einen praktischen und einfachen Deployment-Workflow vor

4. Anwendungen (Applications)

  • Zeigt, wie sich Single-Page-Webanwendungen nur mit Vanilla-Techniken erstellen lassen
  • Erläutert Routing und State Management

Empfohlene Zielgruppe

Richtet sich an Entwickler, die bereits in gewissem Maß mit HTML, CSS und JavaScript arbeiten können

  • Für Einsteiger in die Webentwicklung werden grundlegende Lernpfade wie Odin Project oder MDN empfohlen

Warum der Vanilla-Ansatz?

Moderne Frameworks liefern schnell strukturierte und leistungsfähige Funktionen, bringen aber auch zunehmende Tool- und Framework-Komplexität sowie kontinuierlichen Wartungsaufwand mit sich

  • Der Plain-Vanilla-Ansatz verzichtet auf einen Teil des kurzfristigen Komforts und bietet dafür langfristige Vorteile wie Einfachheit und praktisch null Wartungsaufwand
  • Dank der hervorragenden Unterstützung von Webstandards in heutigen Browsern ist dieser Ansatz heute tatsächlich praktikabel

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-12
Hacker-News-Kommentare

  • Ich betrachte die Debatte „Vanilla oder Framework“ inzwischen eher aus der Perspektive: „Braucht das hier wirklich überhaupt eine Website?“
    Wenn man anfängt, daran zu zweifeln, ob Web-Apps – besonders im B2B-SaaS-Bereich – tatsächlich nötig sind, stellt man fest, dass sich ein Geschäft ziemlich weit bringen lässt, ohne den Browser anzufassen.
    Der Großteil meiner Zeit für Websites und Apps floss in verwaltete UI/UX, also in den Teil, bei dem Admins Datenbankfelder ändern, damit sich die Anwendung so verhält, wie es die Kunden erwarten.
    In vielen Fällen ist es für ein Unternehmen viel schneller, einfacher und mit weniger unnötiger Arbeit verbunden, einfach Konfigurationsvorlagen bereitzustellen (etwa Excel-Dateien) und die Ergebnisse direkt in SQL-Tabellen einzufügen bzw. zusammenzuführen.
    Das Web bietet nur eine einzige Form von UI/UX. E-Mail oder einfache Textdateien sind oft flexibler.

    • Ich sehe oft, dass Digital-first-Beratungen im B2B-Bereich an unnötig schicken Web-Apps bauen und dadurch an Beweglichkeit verlieren.
      Vor allem bei staatlichen Stellen zahlen Käufer oft zu viel, weil sie nicht wirklich wissen, was sie brauchen.
      Beschaffungsverantwortliche müssten besser geschult werden.
    • Ich verkaufe online Urnennischen. Auf meiner Website gibt es nur einen E-Mail-Link. Keinen Warenkorb.
      Ein echtes Geschäft für Urnennischen hat auch keinen Warenkorb – warum sollte ein virtuelles Geschäft einen brauchen?
      Auch als ich spezielle Holzbearbeitungswerkzeuge online gekauft habe, habe ich einfach ein Formular ausgefüllt und die Teile samt Rechnung bekommen; wenn ich wollte, musste ich nicht einmal sofort bezahlen.
      Es gibt online wie offline viele Formen von Handel, und wenn man genau hinschaut, wie Menschen auf interessante Weise ihren Lebensunterhalt verdienen, entdeckt man das überall.
    • Für interne Tools, die kaum über CRUD hinausgehen, ist das Web vor allem dann nützlich, wenn ein externer Berater sie einmalig erstellt oder wenn ein internes Team sie nicht dauerhaft betreuen kann.
      Sobald ein wenig Wartungskompetenz vorhanden ist, ist der Ansatz mit Excel-Vorlagen plus einfachen Custom-Skripten deutlich flexibler.
      Wenn die Endnutzer ohnehin mit Rohdaten umgehen können, ist das sehr effektiv.
    • Vor SaaS lief B2B zu 100 % auf diese Weise.
      Und auch heute noch funktionieren 99 % von B2B so.

  • Ich bin nicht gegen Frameworks. Ich finde nur, dass sie in vielen Fällen unnötig sind.
    Ich habe mich immer gefragt, warum man 100 KB JavaScript hinzufügen sollte, bevor man auch nur eine einzige Zeile Code geschrieben hat.
    Mein Team und ich haben https://restofworld.org ohne irgendein Framework gebaut.
    Bei Umfragen, Outreach und E-Mail-Feedback war die Resonanz in Bezug auf Bedienbarkeit und Leseerlebnis sehr positiv.
    Später kann man immer noch ein Framework einsetzen, aber bisher passt einfach Vanilla JS sehr gut.

    • Dieser Kommentar ist ein gutes Beispiel für die Trennung, die in solchen Diskussionen immer wieder auftaucht.
      Auf der einen Seite stehen Leute, die große Web-Apps in Teams mit 30+ Personen bauen; wenn dort jemand sagt, man baue ohne Framework, kommen sofort Fragen dazu, wie essenzielle Funktionen in großem Maßstab umgesetzt werden sollen.
      Die Antwort lautet hier aber: Diese Funktionen werden gar nicht gebraucht, und weil es eher um etwas wie einen Blog geht, besteht von vornherein kein Bedarf an einem Framework.
      Umgekehrt fragen sich Leute ohne Erfahrung mit riesigen Web-Apps: „Warum benutzen überhaupt alle Frameworks?“
      Das Web ist wirklich ein Sammelsurium sehr unterschiedlicher Software.
      Wenn man also über Frameworks spricht, sollte man klar benennen, um welche Art von Software es geht.
      In diesem Fall ist es ein WordPress-Blog.
    • Die Seite ist großartig und lädt schnell, aber das hat nichts mit dem zu tun, was der TFA beschrieben hat.
      Es wird ein großes Framework namens WordPress verwendet, nur eben statisch gerendert.
      TFA spricht davon, ganz ohne Build-Tools zu arbeiten und nur moderne Webstandards zu verwenden. Nur Editor, Browser und Webstandards.
    • „Warum sollte ich 100 KB JS hinzufügen, bevor ich überhaupt eine Zeile Code schreibe?“
      Bei den Enterprise-Apps, an denen ich gearbeitet habe, musste sich niemand um 100 KB sorgen.
      Das waren meist große Apps, an denen mehrere Teams gearbeitet haben, oft mit React und Ähnlichem.
      Im Lob/B2B-Bereich interessiert sich niemand für den initialen Page Load.
      Die Nutzer verwenden die App jeden Tag, und die meisten statischen Assets kommen ohnehin direkt aus dem Browser-Cache.
      Mit einem smarten Framework wie Next.js wird der Inhalt pro Route in unveränderliche Chunks aufgeteilt.
      Das initiale Rendering ist statisches HTML, sodass Hydration aus Sicht der Nutzer kaum auffällt.
    • Die Seite sieht toll aus. Ich habe dort auch gute Artikel entdeckt.
      Aber wenn in der Debatte „Vanilla vs. Framework“ solche Beispiele immer News- oder Artikelseiten sind, denke ich mir eben: Das sind keine komplexen Apps, also hätte ich dort von vornherein auch kein Framework eingesetzt.
      Als praktisches Beispiel bräuchte man am Ende eher eine interaktivere App.
      Heutzutage bevorzuge ich Frameworks mit konsistenten Mustern und halte andere Abhängigkeiten möglichst klein.
    • Einer der Vorteile dieser Architektur ist, dass die Vor-/Zurück-Navigation im Browserverlauf sehr schnell ist.
      Auf dem iPhone hatte ich mich schon daran gewöhnt, dass beim Zurückgehen ständig die ganze Seite neu geladen wird.
    • Glückwunsch! Ich finde, gute Usability steht an erster Stelle.
      Entwickler versteifen sich aber aus Spaß oft auf Ladescreens, hydratisierte Komponenten, übertriebene Animationen und nervige Modals.
    • Ich weiß nicht, ob es daran liegt, dass kein Framework verwendet wird, aber beim Zurück-/Vorwärts-Navigieren ändert sich zwar sofort die URL, die Seite wird aber nicht aktualisiert, sodass man beim gleichen Artikel bleibt.
      Außerdem ist Infinite Scroll ein massiver Usability-Nachteil, weil man über die Position der Scrollbar nur schwer verfolgen kann, wo man sich gerade befindet.
    • Rest of World ist selbst in Australien extrem schnell und eine fantastische Nachrichtenseite, die ich vorher noch nie gesehen hatte.
      Kompliment an alle, die am Bau beteiligt waren.
    • Das ist die Ästhetik statisch generierter Seiten mit WordPress.
    • Die meisten Frameworks brauchen keine 100 KB JavaScript.
      Bei Mithril bekommt man alles in 10 KB gzipped.
    • Das Problem mit Vanilla-Beispielen ist, dass die Seiten oft viel zu simpel sind und die UX nur die Grundlagen abdeckt.
      Wenn ich an reaktive Tabellen mit Suche, oder an Formulare mit Labels, Validierung und Fehlerbehandlung denke: Warum sollte ich das alles selbst bauen, wenn ich mit einer Svelte-UI-Bibliothek und 25 KB Overhead ein gut gebautes und bewährtes Produkt haben kann?
    • Das Hauptbild ist über 200 KB groß, also ist die Debatte über 100 KB bedeutungslos.
      Und WordPress ist auch ein Framework.
      Auch mit Frameworks wird nichts automatisch langsam – egal ob WordPress oder etwas anderes.
    • Das ist ein gutes Beispiel für die Aufgeblähtheit des modernen Webs.
      Viel zu schnell.
    • Wirklich schnell!
    • Ich mag Rest of World sehr.
    • „Warum sollte ich 100 KB JS hinzufügen?“
      Für die Produktivität der Entwickler – zumindest theoretisch.
      In der Praxis hilft es oft gar nicht so sehr.
    • Die Seite ist wirklich schnell. Ich habe schon früher Journalismus in dieser Art gesehen.
      Mich würde interessieren, ob es bei diesem Ansatz irgendwelche scharfen Nachteile gab.
    • Was? Das ist unmöglich.
    • Niemand interessiert sich für 100 KB.

  • Ich entwickle gerade ein System für ungefähr 2.000 Nutzer, und die interessieren sich überhaupt nicht für reaktive UIs.
    Am besten baut man einen Monolithen, kümmert sich nicht um Page Refreshes und konzentriert sich einfach darauf, die Arbeit erledigt zu bekommen.

    • Als Gegenargument: Viele klassische Desktop-Apps werden letztlich ins Web verlagert.
      Der Antrieb dafür ist oft nicht besonders technisch, sondern dass die Verteilung nativer Apps einfach zu teuer ist.
      Das Web liefert einen günstigen Standard für App-Verteilung, aber die UI-Technik ist weiterhin eher mittelmäßig.
      Früher gab es schon viele halbherzige Versuche wie X11, Java oder Flash, und ich hoffe, dass es irgendwann einen bequemeren Weg geben wird, Web-Apps zu entwickeln.
    • Mit CSS @view-transition allein sind schon flüssige Übergänge möglich.
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • Das ist für die heutige Zeit eine viiiel zu abgestumpfte Sichtweise.
      Die meiste Software ist deutlich langsamer und reagiert schlechter als mechanische Geräte vor 120 Jahren.
    • Mit nur CSS und JS kann man auch ganz einfach eine extrem simple Refresh-Dynamik bauen.
      Man muss keine npm-Pakete einbinden.
    • Auch die Trennung zwischen React und Server ist chaotisch.
      Das Backend ist express/node, der gesamte Code liegt zusammen, in der Entwicklung läuft der Server aber über den Standard-React-Server, in der echten Bereitstellung wiederum anders – am Ende braucht man seltsame Build- und Betriebsprozesse, die den Komfort des Dev-Servers (Hot Reload usw.) praktisch zunichtemachen.
    • Ich habe viel öfter erlebt, dass SPAs kaputt sind als MPAs.
      Selbst die SPAs großer Unternehmen wie Reddit oder X (Twitter usw.) waren mobil viel zu instabil.
      Wenn man nicht Twitter-Größe oder eine API-basierte Plattform hat, muss man meiner Meinung nach nicht zwanghaft an SPAs festhalten.
      Niemand – selbst Milliardenunternehmen nicht – hat das wirklich sauber hinbekommen; also sollte man vorsichtig sein mit dem Glauben, man selbst könne es besser.
    • Der Vorteil des Vanilla-Ansatzes ist, dass man bestehende SSR-Seiten auch erweitern kann.
      Man muss nicht alles für React auseinanderreißen.
      Die fortgeschrittenen SPA-ähnlichen Funktionen, von denen der Originalautor spricht, sind optional.
    • Pragmatistische Nutzer achten vielleicht nicht darauf, aber Nutzer, die einfach nur drauflosklicken, drücken eher den Zurück-Button, um wieder zum Haupt-Feed zu kommen, statt zu warten – und das passiert schneller, als ein frisches Framework vom CDN zu laden.
    • Wenn ein Seiten-Refresh wirklich schnell ist, stimme ich dieser Meinung zu.
    • Mich würde interessieren, woher man weiß, dass Nutzer sich wirklich überhaupt nicht um Seiten-Refreshs kümmern.
      Wurde auch untersucht, was mit den Leuten ist, die abgesprungen sind?

  • In so einer Welt würde ich gern leben.
    Ich komme noch aus der Zeit vor Frameworks; damals war alles noch unreif, und Leute, die nur jQuery konnten, waren keine Seltenheit.
    Heute erscheint mir das Kosten-Nutzen-Verhältnis von Frameworks in der Zeit nach querySelector fragwürdig (Test-Frameworks sind davon ausgenommen, die finde ich großartig).
    Wir sitzen in einem Framework-Gefängnis namens React, und jedes Scheitern ist das Ergebnis von zu Spaghetti gewordener Komplexität.
    State Machines werden fest verdrahtet und verheddern sich, und übersetzte, komprimierte, transpiliierte Artefakte sind kaum noch lesbar.
    Source Maps sind nur eine weitere Komplexitätsschicht für die Wartung.
    Ich erkenne an, warum Frameworks entstanden sind, aber ich kann mir schwer vorstellen, dass es für neue Engineers leichter ist, dauerhaft Frameworks zu lernen als Vanilla JS.

    • Ich habe diese alten Zeiten auch erlebt, und das größte Problem war für mich, dass wir beschlossen haben, ein ganzes App-Ökosystem auf einem Dokumentformat aufzubauen.
      HTML war letztlich nur Markup, um Text etwas leichter zu rendern, und bei HTTP ist es ähnlich.
      Früher musste das Verhältnis von Text zu Markup hoch sein, heute ist es komplett umgekehrt.
      Trotzdem haben wir geglaubt, die Zukunft bestehe darin, die gesamte App-Entwicklung darauf zu stapeln, und wenn man ins Innere von React schaut, sieht man Jahrzehnte von Workarounds und Tricks.
      Früher wäre das ungefähr so gewesen, als würde man Apps mit Excel+VB oder PDF+PostScript bauen – völlig absurd.
      Deshalb wirken für mich mehrere MB JavaScript einfach maßlos übertrieben.
    • Für mich ist die Killerfunktion von heute Reaktivität.
      Wenn sich Daten ändern und die UI sofort mitzieht – sobald man dafür manuell Listener verdrahtet, Diffs aktualisiert und Events wieder aufräumt, fühlt es sich fast wie manuelle Speicherverwaltung an.
      So war es in den jQuery-Zeiten, und da passierten viele Fehler.
      Wenn man Ansichten komponentenbasiert und deklarativ modularisieren kann, würde ich vielleicht zu Vanilla JS zurückkehren, aber im Moment halte ich das für völlig unrealistisch.
      Es fehlt der entscheidende Baustein.
    • Ich frage mich auch manchmal, ob das nur Nostalgie ist, gespeist vom KISS-Prinzip und Ähnlichem.
      React und Angular hatten vor ES2015 eindeutig ihre Berechtigung.
      Danach war ich die ständigen Veränderungen bei Frontend-Frameworks leid.
      Selbst innerhalb von React ändern sich Komponentenansatz und State-Management laufend.
    • Wenn man einen Dienst mit Hunderten Millionen Views betreibt, stelle ich mir vor, dass die Architektur in Wirklichkeit viel näher an einer statischen Website liegt.

  • Ich bin noch immer nicht von Web Components überzeugt.
    Selbst mit neueren Features wie @scoped, import {type:css} usw. halte ich es für deutlich sinnvoller, Elemente einfach statisch zu rendern und sie dann mit modernem JS dynamisch zu aktualisieren.
    Ich bin gegenüber den meisten Web-Components-Ansätzen skeptisch und glaube weiterhin, dass Innovation außerhalb von Frameworks wie React oder Svelte stattfinden muss.
    Ich hatte nie das Gefühl, dass Web Components für die verschiedenen Websites, die ich betreibe, nützlich wären.

    • Web Components lösen mein Problem nicht, sondern fügen eher neue Probleme hinzu.
      Bei fast jeder Erwähnung taucht Shadow DOM dutzendfach auf, aber das sind meist Probleme, die überhaupt erst durch die Einführung davon entstehen.
      Meine Komponenten sind ohnehin nur für meine eigene App, also habe ich auch keine Shadow-DOM-Probleme.
    • „Elemente statisch rendern und dann mit modernem JS dynamisch aktualisieren“
      Mich würde interessieren, wie Web Components das im Backend behandeln.
    • Web Components bieten eine klare Abstraktionsgrenze.
      Man kann dem eigenen Tag zusätzliche Methoden geben und die Update-Logik innerhalb der Komponente kapseln.
    • Ich finde, wir sollten wieder zu Unobtrusive JS zurückkehren.
      Wir brauchen praktische Ansätze mit leichtgewichtigen Bibliotheken oder Dingen, die man selbst schreiben kann.
      HTMX hat teilweise gute Seiten, verhält sich aber immer noch wie ein script-Tag; URL und Methode sollten klar im HTML stehen, und Dinge wie hx-target könnten genauso gut nur in JS über data--Attribute festgelegt werden.
      Ich möchte nicht alle HTMX-Funktionen mitschleppen, die ich gar nicht benutze.

  • Ich halte Web Components nicht für einen Ersatz für das, was andere Frameworks als Komponenten bezeichnen.
    Man kann keine zusammengesetzten Werte (Objekte, Arrays usw.) in Attribute stecken, es gibt zu viel Boilerplate und keine Reaktivität.
    Ich programmiere mein Vanilla-JS-artiges Zeug mit Signals[1].
    Nicht jeder W3C-Standard ist automatisch die richtige Antwort; man sollte sich den Fehlschlag von XHTML als Beispiel ansehen.
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • Das scheint ein guter Ansatz für Leute zu sein, die aus Hobby Webpages bauen.
    Frameworks dienen Standardisierung, eingebauten Best Practices im Design und einem schnellen Projektstart.
    Die Website selbst hat keinen inhärenten Wert; entscheidend ist, wie effizient man ihren Inhalt ausliefert und sie rechtzeitig korrekt entwickelt.
    In diesem Sinn senken Frameworks aktuelle und zukünftige Kosten.

    • Das ist das „offizielle Narrativ“, aber in der Praxis stimmt es nicht immer.
      In großen Unternehmen werden Entscheidungen oft von Trends, Gewohnheiten und einem defensiven Bedürfnis bestimmt, populäre Frameworks rechtfertigen zu können; Produktivitätsverluste durch steigende Komplexität werden kaum nachverfolgt, und schlechte Entscheidungen passen oft sogar gut zu den Anreizen einzelner Personen oder Teams.
      Man kann die Wahl eines Frameworks also nicht einfach damit rechtfertigen, dass sie „zwangsläufig rational“ sei.
    • Ich habe auch viele Projekte gesehen, die mit React und verwandten Frameworks gebaut wurden und trotzdem alles andere als perfekt gemanagt waren.
      Ein Framework sorgt nicht automatisch dafür, dass Best Practices eingehalten werden, und es kann im Gegenteil auch zu übermäßig aufgeblähten und langsamen Systemen führen.

  • Das ist wirklich großartiges Material.
    Wenn man fürs Web baut, sollte man die Grundprinzipien der Basistechnologien kennen und die Webplattform bestmöglich nutzen können.
    Ob man darüber hinaus ein Build-System oder Framework einsetzt, sollte eine freie Entscheidung sein – solange man die Trade-offs versteht.
    Ich persönlich mag Remix (/React-router v7+), weil es mit der Philosophie der Webstandards verbunden ist.
    Man erreicht mit weniger Entwicklung mehr – etwa indem Änderungen an Serverdaten allein mit HTML-Formularen möglich werden.
    Außerdem empfehle ich https://every-layout.dev . Dort kann man viele Techniken für performante, barrierefreie und flexible Layouts lernen, die allein mit nativem CSS des Browsers umgesetzt werden.
    Ich selbst arbeite seit 1998 professionell in der Webentwicklung.

  • Letzte Woche habe ich ein kleines Projekt komplett in Vanilla umgesetzt, und es funktioniert sehr gut.
    Es ist ein Webtool zum Schreiben langer Mastodon-Threads.
    Während der ganzen Entwicklung dachte ich ständig: „Mache ich ohne Framework irgendetwas falsch?“
    Es wirkt, als würden heute alle erwarten, dass man ein Framework verwendet.
    Splinter, splinter.almonit.club – wer Interesse hat, kann es sich ansehen.