HTML First

 (html-first.com)
2 Punkte von GN⁺ 2023-11-13 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn man zuerst die vom Browser nativ bereitgestellten Funktionen nutzt, kann man beim Erstellen von Web-Apps die Abhängigkeit von zusätzlichen Sprachen und Toolchains verringern.
  • React hat mit Mustern wie props, state und Komponenten die Zuverlässigkeit der UI-Entwicklung erhöht, den Schwerpunkt der Entwicklung aber von HTML auf JavaScript verlagert.
  • In der Zwischenzeit haben W3C, WHATWG, IETF und TC fineC den Grundsprachen des Webs Tausende von Verbesserungen hinzugefügt; da die wichtigsten Browser diese integriert haben, ist ein Teil der Gründe für den Einsatz von React schwächer geworden.
  • HTML First ist weniger eine Strömung, die Entwickler überzeugen will, die mit React zufrieden sind, sondern will Menschen mit Interesse an einem HTML-zentrierten Ansatz eine Sprache geben, um ihre Gedanken zu ordnen und mit Kollegen zu diskutieren.
  • Es ist eher ein praxisnahes Problembewusstsein: Wir sollten erneut prüfen, ob sich mit den Grundsprachen des Webs und den Browserfunktionen allein schnelle und barrierefreie Software bauen lässt.

Die von HTML First angestrebte Entwicklungsweise

  • HTML First priorisiert beim Erstellen von Web-Software HTML, CSS, JavaScript und die nativen Funktionen des Browsers.
  • Der Kern besteht darin, die Abstraktionsschichten zu reduzieren, die auf die Webplattform aufgesetzt werden.
    • Dazu zählen auch zusätzliche Sprachen und Toolchains als Schichten, die möglichst reduziert werden sollten.
  • Ziel ist eine Entwicklungsweise, die die bereits vom Browser bereitgestellten Funktionen ins Zentrum stellt und Werkzeuge nur dann darüberlegt, wenn sie wirklich nötig sind.

Webentwicklung wurde nach React komplexer

  • Vor React war es üblich, Interfaces in HTML zu schreiben und Bereiche, die HTML nicht standardmäßig unterstützte, mit Werkzeugen wie jQuery zu ergänzen.
    • Typische Beispiele sind das Senden asynchroner Anfragen und DOM-Updates.
  • Bibliotheken wie React haben mehrere Probleme der bisherigen Webentwicklung gelöst.
    • Das props- und state-Muster, bei dem Daten explizit von Elternelementen an Kindelemente weitergegeben werden, hat bestimmte Arten von Bugs reduziert.
    • UI, Stil und Verhalten konnten in Komponenten gebündelt werden, sodass sich von anderen erstellte Bausteine leicht in die eigene Codebasis integrieren ließen.
  • Um diese Vorteile zu erhalten, musste man von einer überwiegend HTML-basierten Arbeitsweise zu einer überwiegend JavaScript-basierten wechseln.
    • JavaScript gilt als komplexere Sprache.
    • Viele von React eingeführte Konzepte und Werkzeuge mussten ebenfalls mitgelernt werden.
  • Die Branche hat diesen Kompromiss trotz der gestiegenen Komplexität akzeptiert, und solche Bibliotheken wurden zur Standardmethode, Web-Apps zu bauen.
    • Vor React lernten neue Entwickler zuerst HTML und CSS und danach JavaScript.
    • Nach React verlagerte sich der Lernpfad dahin, zuerst JavaScript und React zu lernen und danach den Rest.

Warum Verbesserungen der Webplattform eine Neubewertung auslösen

  • W3C, WHATWG, IETF und TC39 haben während der Verbreitung des React-Ansatzes Tausende von Verbesserungen an den nativen Sprachen des Webs vorgenommen.
    • Diese Verbesserungen wurden in Chrome, Safari, Firefox und Edge integriert.
    • Viele davon behandeln direkt einige der Gründe, warum Menschen React eingesetzt haben.
  • Da die Kosten der Softwareentwicklung gestiegen sind und Browser-Verbesserungen breit ausgerollt wurden, fragen sich immer mehr Menschen, ob diese zusätzlichen Schichten heute noch wirklich nötig sind.
  • Die Idee von HTML First ist in der Branche weiterhin eine Minderheitenposition.
  • Dieser Ansatz konzentriert sich darauf, Menschen, die bereits an HTML-zentrierter Entwicklung interessiert sind, dabei zu helfen, ihre Gedanken zu schärfen und Sprache und Konzepte für die Kommunikation mit Kollegen zu gewinnen.
  • Die Kernbotschaft lautet, dass es möglich, praktikabel und vernünftig ist, schönes, schnelles, leicht nutzbares und barrierefreies Web-Software hauptsächlich mit den nativen Sprachen und Funktionen des Webs zu bauen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-13
Hacker-News-Meinungen

  • Mir gefällt die Idee dahinter, aber ehrlich gesagt sind die Beispiele eher schwach.
    Das Beispiel zu „Definiere Styles und Verhalten, wenn möglich, als Inline-HTML-Attribute“ scheint in der Praxis nicht wirklich zu funktionieren, und wenn man weitere Styles hinzufügen will, wächst einfach nur der String-Parameter weiter, den man an ClassList.add übergibt.
    Persönlich finde ich button:active { background: green; } deutlich lesbarer, aber der Autor scheint das wegen des Ansatzes der „Locality of Behaviour“ als kompliziert anzusehen.
    Der Aussage „Wenn du eine Library brauchst, nimm eine, die HTML-Attribute nutzt, statt auf JavaScript oder eigene Syntax zu setzen“ stimme ich zu, aber das empfohlene Beispiel „on input put me into #output“ wirkt noch seltsamer als die Library, die als Negativbeispiel dient, und scheint auch ohne Framework mit einfachem JavaScript völlig machbar.
    Als Beispiel für „Bevorzuge ‚rohes‘ HTML gegenüber versteckten Schichten, die zu HTML kompiliert werden“ wird empfohlen, Rails-ERB-Tag-Helper nicht zu verwenden; diese Helper übernehmen aber ziemlich viel, was in einem direkt geschriebenen Minimal-Template schnell unordentlich würde. Das Beispiel lässt realistische Aspekte wie eindeutige DOM-IDs, Turbo-Tags und Iteration aus.

    • An der Stelle „Definiere Styles und Verhalten, wenn möglich, als Inline-HTML-Attribute“ bin ich auch hängengeblieben.
      Styling und Verhalten sollten getrennt sein, und dass sie nur über Referenzen miteinander verbunden sind, ist ab einer sinnvollen Größe der einzige Ansatz, der Sinn ergibt.
      Technisch kann man in einer Python-App auch alle SQL-Datenbankverbindungen und hartcodiertes SQL in eine lange Datei packen, aber das ist eine schlechte Gewohnheit; dieses Prinzip wirkt ähnlich.

  • Dieser Teil ist verwirrend: „Wenn du eine Library brauchst, nimm eine, die HTML-Attribute nutzt, statt auf JavaScript oder eigene Syntax zu setzen.“
    Als empfohlenes Beispiel wird aber _hyperscript [0] gezeigt. Das ist eine Library mit eigener Syntax; man schreibt nur Skripte in einer neu zu lernenden Sprache in HTML-Attribute. Ich weiß nicht, ob das ernst gemeint ist.
    [0] https://hyperscript.org

    • Das wirkt, als sei es als Tippliste zur Werbung für hyperscript geschrieben.
      Auch die Beispiele sind ziemlich schwach. Die reine Lösung, also schon der erste Tipp allein, funktioniert genauso gut.
    • Stimme zu. Das Beispiel, in dem ein schwer verständlicher DSL-Satz als Wert in ein Attribut namens _ geschrieben wird, sieht wirklich merkwürdig und verwirrend aus.
      Da wäre es besser, explizit reines JavaScript in onclick oder andere Event-Attribute zu schreiben, sodass man sofort erkennt, was passiert.
    • Nach dem Rat des Autors wäre Alpine.js wohl die bessere Empfehlung gewesen, weil es HTML-Attribute und intuitives JavaScript verwendet.
    • hyperscript ist mit HTMX verbunden, daher scheint es Leute zu geben, die es pushen wollen, aber meiner Meinung nach ist es eher ein interessantes Spielzeug.
    • Vielleicht hat der Autor die empfohlenen und nicht empfohlenen Beispiele einfach vertauscht.

  • Ich verstehe die Absicht. Die eingebauten Funktionen von HTML zu nutzen, ist sauber und einfach.
    Aber vor 10 Jahren war das schon nicht praktikabel, und heute ist es das auch nicht. Ich habe auch nicht das Gefühl, dass etwas wie htmx besonders viel besser ist als schwergewichtigere Lösungen wie React.
    Wenn ich solche Ansätze sehe, stelle ich immer dieselbe Frage: Wie sehen Dropdowns, Mehrfachauswahl und Datepicker aus? Gibt es inzwischen Datepicker in allen Browsern? Ja. Sind Aussehen und Verhalten browserübergreifend konsistent? Nein. Kann man das per Styling angleichen? Ebenfalls nein.
    Bei Mehrfachauswahl ist es ähnlich. Nutzer zu zwingen, für die Auswahl mehrerer Einträge Shift/Ctrl zu klicken, ist aus UX-Sicht völlig inakzeptabel. Das Basiselement funktioniert immer noch so und lässt sich nicht ändern. Nicht nur Mehrfachauswahl, auch normale Select-Elemente sehen schlecht aus und sind generell schwer anzupassen.
    Es gibt einen Grund, warum für jedes neue Framework solche Third-Party-Komponenten entstehen: Die eingebauten Elemente reichen nicht aus. Das ist derselbe Grund, warum 90 % meiner Projekte immer noch von lodash abhängen, obwohl auf der MDN-Seite zu Array jedes Jahr neue eingebaute Funktionen hinzukommen. Es ist besser als vor 10 Jahren, aber noch nicht genug.

    • Wenn ich kurz nur an Datepicker denke: Websites werden für Nutzer gestaltet.
      Nutzer können unterschiedliche Browser verwenden, aber ein einzelner Nutzer verwendet wahrscheinlich denselben Browser auf allen Websites, die er besucht.
      Deshalb ist meiner Meinung nach wichtiger, dass ein Datepicker innerhalb eines Browsers über alle Websites hinweg konsistent ist, als dass er auf einer Website über alle Browser hinweg konsistent ist. Natürlich ist es etwas anderes, wenn man Custom-Funktionen braucht.
    • Bedeutet die Aussage „Nutzer zu zwingen, für die Auswahl mehrerer Einträge Shift/Ctrl zu klicken, ist aus UX-Sicht völlig inakzeptabel“, dass man Mehrfachauswahl nicht so umsetzen sollte? Falls ja, würde mich interessieren, wie man es machen sollte.
      Wenn ich in einer Liste 10 oder 15 aufeinanderfolgende Einträge auswählen will, kenne ich derzeit keine bessere UI als Shift+Klick.
    • „Sind Aussehen und Verhalten browserübergreifend konsistent? Nein“ — das wirkt seltsam, wenn man bedenkt, dass früher ein nativer Look and Feel als Pflichtmerkmal von Desktop-Apps galt.
      Es wäre viel besser, wenn die UI-Komponenten aller Websites dem nativen Look and Feel des Browsers folgen würden, abgesehen vom eigentlichen Site-Design, statt dass jede Website ihre eigenen dummen Styles neu erfindet. Natürlich müssten die Browser darauf achten, dass das gut aussieht.
    • Wenn man die restliche Diskussion betrachtet, sind input-Elemente berüchtigt dafür, dass sich ihre Interaktionsweise je nach Browser stark unterscheidet, während die meisten anderen HTML-Elemente ein klar festgelegtes Standardverhalten haben.

  • Den meisten Aussagen stimme ich zu, aber dieser Text wirkt ein wenig widersprüchlich. Denn er empfiehlt Tailwind und sagt gleichzeitig: „Vermeidet Build-Schritte“
    Riesige CSS/JS-Ressourcen auszuliefern widerspricht auch dem Prinzip der Inklusivität. Viele Menschen haben weder schnelles Internet noch einen ausreichend leistungsfähigen Computer

    • Ich nutze Tailwind derzeit nicht, aber meiner Erfahrung nach hat Tailwind nicht dazu geführt, dass riesige CSS/JS-Ressourcen ausgeliefert wurden
      Tatsächlich wüsste ich nicht, dass Tailwind überhaupt clientseitiges JavaScript ausgibt. Meine letzte Erfahrung war mit 2.x, daher bin ich nicht sicher, ob sich da etwas geändert hat
      Auch bei der CSS-Größe war meine Erfahrung das Gegenteil: Tailwind-Output war meist deutlich kleiner als handgeschriebenes CSS
      Natürlich habe ich auch nichts gegen reines CSS, aber auch das lässt sich mindestens genauso leicht vermurksen
    • Ich habe eine Atomic-CSS-Library gebaut, die keinen Build-Schritt braucht. Falls jemand so etwas möchte, hier ist sie. Spoiler: Natürlich will sie niemand: https://casscss.github.io/cass/
    • Deno Fresh nutzt Twind, um den Build-Schritt zu vermeiden: https://twind.dev/
      Soweit ich mich erinnere, bietet es allerdings nicht alle Funktionen, die vollständiges Tailwind bietet. Insgesamt fand ich frustrierend, dass Fresh im Grunde stark auf Preact und Twind aufbaut und nicht ehrlich genug offenlegt, dass man zuerst diese Libraries akzeptieren muss
    • Tailwind hat eine eigenständige CLI, die man als Build-Schritt verwenden kann
      Ich stimme gewissermaßen zu, dass es im Kontext dieses Artikels etwas seltsam ist, es zu empfehlen. Aber der Build-Schritt kann extrem minimal sein, und es ist auch gut, dass das Ergebnis weiterhin einsehbares CSS ist
      Ich nutze Tailwind auf meiner persönlichen Website, der Rest ist komplett reines HTML. Beim Schreiben von Styles die CLI im Watch-Modus laufen zu lassen, stört mich nicht besonders
    • Als No-Build-Optionen finde ich zwei gut: Tailwind v3 CDN selbst hosten oder https://github.com/gnat/css-scope-inline verwenden
      Beide sind überraschend schnell und parsen auch mehr als 10.000 Einträge

  • In der Theorie oder bei einfachen Beispielen ist das interessant, aber ich würde gern ein großes Projekt sehen, das das anwendet, und was es in der Praxis tatsächlich verändert hat
    Die Ziele am Anfang des Textes sind großartig, aber die Ratschläge selbst fand ich etwas enttäuschend. Ich sehe kaum, wie das außerhalb sehr grundlegender Situationen funktionieren soll, und noch weniger, wie diese Ziele damit erreicht werden sollen
    Ich bin dafür, die Web-Plattform möglichst gut auszunutzen, und absolut dafür, Komplexität so weit wie möglich zu reduzieren. Aber ich bin sehr skeptisch, ob diese Prinzipien das leisten, und es wirkt eher so, als könnten sie durch mehrere Wege für dieselbe Sache zusätzliche Komplexität schaffen
    Wohlwollend gesagt: Allein anhand dieser Liste kann man nicht erkennen, ob diese Prinzipien in der Praxis wirklich erprobt wurden oder ob nur angenommen wird, dass sie wie erhofft funktionieren

    • Ich verstehe nicht, warum eine Praktik erst für große Projekte gut sein muss, um eine gute Praktik zu sein
      Das meine ich wirklich ernst. Leute bringen dieses Argument oft vor, und ich habe es nie verstanden
      Aus meiner Sicht bestehen 95 % des Webs aus kleinen bis mittelgroßen Projekten. Die meisten Technologien sollten darauf ausgerichtet sein. Für einfache Projekte nutzt man einfache Lösungen und fügt Komplexität später hinzu
    • Ich habe versucht, bei der Arbeit ein HTML-first-Frontend durchzusetzen, aber als wir normale Frontend-Entwickler einstellten, verstanden sie es im Grunde nicht und wollten alles mit divs bauen und VueJS die gesamte Logik und alle Inhalte kontrollieren lassen
      Eine halbwegs objektive Sache, die wir verloren haben, ist Barrierefreiheit. Weil Links naiv als divs mit Click-Event-Listenern neu implementiert wurden, lässt sich der Großteil der Website nicht per Tastatur bedienen
      Das ist ziemlich beunruhigend. Wenn Regulierung kommt, werden wir hektisch versuchen, das zurückzuholen, was wir weggeworfen haben
      Trotzdem stimme ich bis zu einem gewissen Grad zu, dass es schwer ist, bekannte Beispiele für „HTML-first“-Websites zu finden. Ich glaube daran, habe aber noch kein wirklich gut ausgearbeitetes Beispiel gesehen. Der Grund könnte allerdings rein in der Ausbildung liegen. Als HTML mächtig wurde, war die Frontend-Entwicklungsausbildung bereits stark auf Frameworks festgelegt
    • Wenn man ein Frontend-Entwickler ist, der jünger ist als jQuery, wäre es eine gute Gelegenheit, ein Projekt nach diesem Rat zu starten, um zu lernen, warum wir Dinge wie Build-Schritte verwenden und wie mühsam Entwicklung vor HMR war
      Es wirkt nicht so, als hätte der Autor das tatsächlich in einem Projekt ausprobiert, an dem mehr als zwei Personen beteiligt sind und das 99 % der existierenden Browser unterstützt. Außerdem scheint er nicht einmal seinen eigenen Code ausgeführt zu haben. Vielleicht liegt es daran, dass mein Bildschirm nicht lecker ist, aber onlick ist kein Handler für divs
    • Wir haben alte Lektionen vergessen. Backend-first war ein Abwehrmechanismus gegen Menschen, die nur dem Sichtbaren glauben und Experten nicht vertrauen
      Wenn man ein Produkt baut, das so aussieht, als würde es funktionieren, tatsächlich aber nicht funktioniert, verstehen sie das nicht. Dann wird man auf den Weg gedrängt, zu viel zu versprechen und zu wenig zu liefern
      Einer der weniger bekannten Vorteile von Unit-Tests ist, dass Code, den das Management nicht sehen kann, mehr Qualitätssicherung bekommt, bevor er verbunden wird. Sie verkürzen die unangenehme Phase zwischen dem ersten sichtbaren Screen und dem Release
    • Stimme zu
      1999 habe ich meine erste Website mit reinem HTML, CSS und purem JS gebaut und auf Geocities gehostet
      Danach habe ich Websites und Apps mit PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript und ClojureScript gebaut
      Heute fühlen sich React, TSX-Komponenten, CSS-in-TS, Effects und Context wie ein vertrautes Zuhause an. Es fühlt sich an, als hätten wir endlich eine vollständige Programmiersprache für Web/Frontend. Eine Sprache, die ausdrücklich für Frontends geschaffen wurde, auf modernen Prinzipien wie funktionaler und reaktiver Programmierung
      Erst jetzt kann man wirklich Softwareentwicklung betreiben. HTML, CSS, pures JS und PHP davor waren eher Hackerei. Rails war gut für Fullstack, glänzte aber im Frontend nicht
      Wenn der Web-Stack auch für Apps bereit ist, lasse ich Frameworks weg. Für Websites reicht er heute vielleicht schon, das gebe ich zu

  • Dieses Jahr habe ich aufgegeben. Es ist inzwischen unmöglich geworden, weiter gegen die React-, Vue- und Angular-Monster mit Bundlern, Transpilern und all dem mitgeschleppten Kram anzukämpfen.
    Node und npm werfen selbst bei einem Projekt, das erst vor ein paar Sekunden neu erstellt wurde, „7 schwerwiegende und 8 kritische Schwachstellen“ aus. Man muss Tausende Dateien herunterladen, und darunter kann sogar so etwas wie ein Wrapper für boolesche Werte sein.
    Die Zeiten, in denen mein Python-Backend-Server auch gleich das Frontend mit ausgeliefert hat, scheinen für mich vorbei zu sein.

    • Wut! Wut gegen die Maschine!
      Tatsächlich brauchen weder du noch irgendjemand sonst dieses schwere JavaScript-Frontend-Bloat wirklich. Man kann einfach Nein sagen.
      Liefere schlanke Seiten aus dem Backend oder Cache aus, und wenn nötig, erledige die schicken Dinge mit CSS.
      Dann bekommst du schnelle Renderzeiten und weltweite Zugänglichkeit.
    • Drück den Escape-Knopf. Ein großer Teil dessen, was am Web gut ist, steckt in Phoenix Liveview. Damit kann man sexy, reaktive Websites bauen, ohne diesen verrückten React/Node-Kram.
      Ehrlich gesagt sind die Beispiele in diesem Artikel allerdings seltsam. Ich verstehe nicht, warum man reine Tags von Hand schreiben sollte, statt die Phoenix-Form-Helper zu verwenden, die Fehler und diverse Komfortfunktionen automatisch ausgeben. Den Geist dahinter verstehe ich.
    • Das geht. Probier einfach htmx aus.

  • Die Kernthese scheint zu sein, dass Nutzer auf View Source klicken und verstehen können sollten, was passiert. Bei einer Website stimme ich zu.
    Bei einer Web-App, zumindest wenn sie mehr als 50 Zeilen hat, will man vermutlich eine Sprache mit Typen verwenden. Technisch könnte man .js mit Typannotationen in speziellen Kommentaren und dem TypeScript-Compiler nutzen, aber besonders angenehm war das nicht.
    Früher hat mich diese Idee ziemlich stark angezogen, und es macht mich traurig, dass die meisten heutigen Sites aus einem einzigen unlesbaren HTML-Zeilenklumpen bestehen. Es hat etwas Schönes und Elegantes, alles als eine einzige HTML-Datei ohne Abhängigkeiten auszuliefern. Ein Netzwerk-Request genügt.
    Am Ende habe ich für bequemes Editieren zwar ein „Build-System“ gebaut, aber mein Build-System ist cat. Damit wird es zu in sich geschlossener, portabler Software in einer einzigen menschenlesbaren Datei.
    In ähnlicher Weise ist das Coolste an Webentwicklung, dass man mit Notepad und einem Standardbrowser sein erstes interaktives Programm bauen kann. Man zieht einfach die HTML-Datei in den Browser. Es fühlt sich magisch an.
    Nachtrag: Ich habe einen unerwarteten Vorteil von in sich geschlossenem HTML entdeckt. Die Software wird immun gegen Bitrot. Ich habe ein altes Projekt im Web Archive geöffnet, und die externe JS-Datei war nicht archiviert. Traurig. Diese hier lädt dagegen problemlos, weil das gesamte JS im HTML steckt. Ein Sieg.
    https://web.archive.org/web/20210508133239id_/https://andai....
    Das ist eine Hommage an den alten SodaPlay Constructor. Den Editor habe ich nicht gebaut. Source ansehen ist erlaubt.

    • Bei diesem Punkt bin ich skeptisch. Inzwischen gibt es in den Developer Tools viele Möglichkeiten, „hinter den Vorhang“ zu schauen.
      Es gibt DOM-Ansicht, Network-Tab, Heap-Ansicht und eine eingebaute Funktion, um JavaScript hübsch zu formatieren.
      Natürlich ist „View Source“ weiterhin wichtig, aber ich bezweifle, dass seine Bedeutung noch so absolut ist, wie die HTMX-Leute es darstellen.
    • „Es hat etwas Schönes und Elegantes, alles als eine einzige HTML-Datei ohne Abhängigkeiten auszuliefern. Ein Netzwerk-Request genügt.“
      Mit data:-URLs ist das jetzt noch einfacher. Sie sind auch nützlich, um die Probleme von file://-URLs zu vermeiden, bei denen man nicht einmal einen HTTP-Server braucht.
    • Nachtrag: Es gibt einen Vorschlag, JavaScript um Typannotationen zu erweitern, sodass ein „ziemlich großer Teilmengenbereich“ von TypeScript direkt im Browser laufen könnte. Schön!
      https://github.com/tc39/proposal-type-annotations
    • Ich glaube nicht, dass der Autor für ein Ein-Datei-System plädiert. Stattdessen will er sagen, aber nicht unbedingt aussprechen, dass

  • „Locality of Behaviour“ ist eine viel zu lose definierte Regel. Es ist nur ein neuer Name für etwas, das der Trennung von Belangen widerspricht.
    CSS als spukhafte Fernwirkung zu bezeichnen, ist ebenfalls stark übertrieben. Es gibt zwar gute Prinzipien, aber die Argumentation ist ziemlich schwach und hätte sich viel einfacher ausdrücken lassen.

    • Aus der Perspektive von jemandem, der aus einer C#-Organisation mit viel zu vielen Interfaces kommt, sehe ich das als natürliche Gegenreaktion auf übermäßig abstrahierte Systeme.
      Wenn man, um „einen roten, federnden Button in einen blauen, wackelnden Button zu ändern“, sich durch ein Labyrinth aus 3 bis 7 Interfaces und Klassen hangeln muss, um herauszufinden, welche Klasse eine neue Implementierung braucht und was wiederverwendet werden kann, wird aus einer Änderung, die nach 10 Minuten klingt, ein halber Tag, an dem man innerlich den Compiler oder den früheren Entwickler verflucht.
      Natürlich sollte man abstrahieren, aber es muss auch eine Möglichkeit geben, Verhalten an einer Stelle zu bündeln, damit man nicht sechs Dateien anfassen muss, nur um eine Komponente zu ändern.
      https://htmx.org/essays/locality-of-behaviour/#conflict-with...
    • Tailwind ist ebenfalls ein Build-Schritt und hat genauso viel „spukhafte Fernwirkung“. Wenn nicht, würde man einfach Inline-CSS verwenden.
      Mit Tailwind vertraut man darauf, dass eine Drittanbieter-Bibliothek die CSS-Spezifikation abstrahiert und dass diese abstrahierte Quasi-Spezifikation je nach Build-Konfiguration eingehalten wird.
    • Wenn „Locality of Behaviour“ eine lose definierte Regel ist, gilt das dann nicht auch für Separation of Concerns?
      Was soll getrennt werden? Entlang welcher Linien soll man schneiden? Wie bestimmt man diese Linien? Wann ist es sinnvoll, einen Concern in eine andere Klasse, ein Framework, Markup usw. auszulagern? Und wann ist es besser, ihn beisammenzulassen?
      Die Antwort lautet: „Es kommt darauf an.“
      Wenn man gar nichts trennt, entsteht Spaghetti-Code; wenn man immer und überall maximal trennt, entsteht überabstrahierter Code, der genauso schwer zu warten ist wie Spaghetti-Code.
    • Das ausdrücklich genannte Hauptziel ist, „den Kreis der Menschen, die an Web-Software-Codebases arbeiten können, stark zu erweitern“. Das unterscheidet sich ziemlich von allgemeinem Rat für Programmierer.
      Wenn die Defaults gut funktionieren, ist Customizing nicht zwingend nötig. Deshalb treten Effizienzgewinne durch CSS und Ähnliches hinter Einfachheit zurück.
    • Das Problem ist mehrdimensional.
      Wenn man HTML als Dokument-/Präsentationssprache betrachtet, lässt sich Styling nicht negieren. CSS fügt nicht nur Styling, sondern auch Animationen hinzu.
      So oder so kann man CSS auch als aspektorientierte Programmierung sehen.
      Das eigentliche hier beschriebene Problem ist der Mangel an guten Tools über Sprachen und Frameworks hinweg.

  • Es ergibt Sinn, sich nach Möglichkeit auf einfachere Frameworks zu stützen. Aber die Idee, Build-Schritte abzuschaffen, ist nahezu ein kompletter Witz.
    Man sollte Build-Schritte effizienter machen und sie, falls nötig, nicht in die Produktion einbeziehen.
    Außerdem verstehe ich nicht, warum das Hinzufügen von Attributen zu HTML bevorzugt werden sollte. Erstellt man Dokumente und hostet sie als Website? In welcher anderen Welt wäre das vorzuziehen? CSS ist nicht schwer zu navigieren; vielmehr sollte man bessere CSS-Praktiken fördern.
    Frontend-Skripte können Styling zwar vernebeln, aber wenn man das nicht braucht, sollte man sich nicht auf diese Methode stützen. Es ist ohnehin selbstverständlich, dass es einfacher ist, Styling in ein Stylesheet zu schreiben, als per JavaScript Attribute einzufügen.
    Einige Ratschläge nach dem Motto „verwende nur, was du brauchst“ sind sinnvoll und offensichtlich. Der Rest ist jedoch verwirrend oder offen absurd. Ich verstehe auch nicht, warum es als gut vorausgesetzt wird, ganze HTML-Seiten kopieren zu können. Ehrlich gesagt ist mir das egal, und selbst wenn man den HTML-Code einiger Seiten nicht sehen könnte, gibt es buchstäblich schon Millionen von Ressourcen, um HTML zu lernen.
    Insgesamt lässt mich das eher ratlos zurück.

    • Ein erheblicher Teil davon ist eine Reaktion auf den Komplexitätskult in der Webentwicklungsbranche.

  • Dieser ganze Artikel ist ein Antipattern und schlechter Rat. Er liest sich, als hätte ihn jemand geschrieben, der beim Bauen komplexer Websites nie die Wachstumsschmerzen erlebt hat.
    Am Anfang haben wir Websites auch so gebaut, aber dann begann alles wegen Seiteneffekten, kollidierender Klassennamen und schlechter interner Beobachtbarkeit zu zerbrechen, und React kam zur Rettung.
    Das gewünschte Pattern ist Progressive Enhancement, und die Ausgabe sollte sauberes, komprimiertes HTML sein, das durch JavaScript erweitert wird. Das heißt: Man braucht einen Build-Schritt. Das ist das genaue Gegenteil der Ratschläge in diesem Artikel.

    • Auch beim Bauen von Websites mit React gibt es Fallstricke, und React zu verwenden bedeutet, eine Menge Komplexität einzuführen.
      Wenn man im Backend nicht ohnehin bereits NodeJS verwendet, sollte man ReactJS besser vermeiden, solange man es nicht wirklich braucht.