Web Components sind in Ordnung

 (nolanlawson.com)
2 Punkte von GN⁺ 2024-10-01 | 1 Kommentare | Auf WhatsApp teilen
  • In der Web-Components-Debatte geht es nicht darum, sich zwischen höchster Performance und Plattformstandards entscheiden zu müssen; schon die Annahme, sie müssten alle JavaScript-Frameworks ersetzen, ist überzogen
  • Custom Elements nutzen das DOM als Schnittstelle und bringen daher Overhead mit sich, doch in echten Produkten müssen neben Performance auch Wartbarkeit, Sicherheit, Nutzbarkeit und Barrierefreiheit bewertet werden
  • Die Kosten für die Unterstützung von Web Components in Frameworks lassen sich teils durch einfache Prüfungen auffangen; nur weil etwas ein Standard-Feature ist, muss es nicht jedes Framework zwingend übernehmen
  • Web Components haben Schwächen bei Server-Side Rendering (SSR), Barrierefreiheit und Teilen der Interoperabilität, sodass React, Solid und Svelte in manchen Situationen weiterhin besser passen
  • In Umgebungen wie Salesforce, in denen clientseitig gerenderte Apps, Component-Marktplätze und langfristige Abwärtskompatibilität wichtig sind, können Web Components eine realistische Option sein

Ausgangspunkt der Debatte und Position des Autors

  • Die jüngste Debatte schließt an Ryan Carniatos „Web Components Are Not the Future“ und Cory LaViskas „Web Components Are Not the Future — They’re the Present“ an
  • Der Streitpunkt besteht weniger darin, die Gegenseite anzugreifen, sondern eher darin, ob Entwickler mit unterschiedlichen Einschränkungen Gemeinsamkeiten finden können
  • Ryan Carniato wird für seine Arbeit an Solid sowie für die in js-framework-benchmark sichtbare Performance- und Framework-Design-Arbeit hoch geschätzt
  • Auch Web Components haben reale Einsatzbereiche, die mit Framework-Implementierung, Component-Erstellung, der Web Components Community Group, der Accessibility Object Model Group sowie Arbeiten an shadow DOM, custom elements und Barrierefreiheit verbunden sind

Performance: DOM-Kosten sind real, aber nicht alles

  • Die grundlegende Schwäche von Web Components liegt darin, dass sie auf Custom Elements basieren
    • Da alle Schnittstellen über das DOM laufen müssen, entsteht Performance-Overhead
    • Wenn das Ziel das absolut schnellste Framework ist, sollte man DOM-Knoten so weit wie möglich reduzieren; nach diesem Maßstab sind Web Components im Nachteil
  • Performance ist jedoch nicht das einzige Kriterium in der Softwareentwicklung
    • Wartbarkeit, Sicherheit, Nutzbarkeit und Barrierefreiheit müssen ebenfalls berücksichtigt werden
    • Wenn aria-*-Attribute nicht gerendert werden, kann das DOM-Rendering etwas schneller werden, für zugängliche Interfaces können sie aber notwendig sein
    • Mikro-Optimierungen wie for-Schleifen statt .forEach() oder var statt const/let sind den Aufwand meist nicht wert
  • Die Minimierung von DOM-Knoten ist die Kernidee von Virtualisierung
    • Auch wenn es nicht die schnellste Wahl ist, reicht manchmal ein einfacherer Ansatz völlig aus
    • components as elements ist ebenfalls nicht optimal, aber das Optimum muss nicht immer das Ziel sein
  • Auch der gemeinsame Einsatz von Custom Elements, die mit unterschiedlichen Frameworks erstellt wurden, ist in der Praxis sinnvoll
    • Es kann nötig sein, schrittweise von Framework A zu Framework B zu migrieren
    • Manchmal müssen mehrere Micro-Frontends kombiniert werden
    • Es ist nicht das schnellste Interface, kann aber ein notwendiger Trade-off sein
  • Bei realer Web-Performance sind niedrigschwellige Verbesserungsbereiche wie Layout Thrashing, Netzwerk-Waterfalls und unnötiges Re-Rendering häufiger
    • Wettbewerbe wie js-framework-benchmark sind für Framework-Autoren interessant, in typischen Produktsituationen aber nicht immer ausschlaggebend
    • Wenn in einer ressourcenbeschränkten Umgebung jede Millisekunde zählt, kann es auch sinnvoll sein, auf Web Components zu verzichten

Kosten der Framework-Unterstützung und Wahlfreiheit

  • Der Behauptung, die Unterstützung von Web Components sei für Framework-Autoren übermäßig teuer, stimmt der Autor nicht zu
    • Props und Attributes lassen sich mit einer Prüfung wie prop in element erkennen
    • Web Components auszugeben kann mühsam sein, ist aber keine Aufgabe, die jedes Framework zwingend übernehmen muss
    • Vue 2 nutzte eine separate Web-Component-Wrapper-Library, und Remount existiert ohne Input des React-Teams
  • Auch wenn ein Framework Features ignoriert, die seit 2011 zur Webplattform hinzugekommen sind, kann es hervorragend sein
    • jQuery v1 läuft weiterhin auf vielen Websites
    • Da Browser-Performance-Teams die Muster früherer Webentwickler optimieren, kann alter Code in neuen Browsern sogar schneller werden
  • Die Entscheidung, moderne Webplattform-Features zu übernehmen, bringt neue Überlegungen mit sich
    • Features wie Symbol, Proxy und Promises fallen in dieselbe Kategorie
    • Dank der Abwärtskompatibilität des Webs kann geschriebener Code auch in zehn Jahren noch laufen
  • Es ist völlig möglich, dass Frameworks kein Interesse an Web Components haben oder sie nicht unterstützen wollen
    • Man kann die gesamte UI mit Web Components bauen
    • Man kann auch nur einzelne HTML Web Components beimischen
    • Man kann sich ebenso entscheiden, sie gar nicht zu verwenden
    • Auch ein „No Web Components“-Framework kann Fans gewinnen

Standards sind Referenzpunkte, keine Pflicht

  • Wenn ein Feature zum Standard wird, nehmen Entwickler es als grundlegenden Vergleichsmaßstab wahr
    • Component-Autoren müssen entscheiden, ob ihr eigenes <slot> sich wie das native <slot> verhalten soll
    • Ebenso müssen sie wählen, ob sie IntersectionObserver oder <img loading="lazy"> nutzen oder eine eigene Abstraktion bauen
  • Standards bieten gemeinsame Referenzpunkte und ein gemeinsames Vokabular
    • Es entsteht eine Grundlage, auf der verschiedene Ansätze verglichen und gegenübergestellt werden können
    • Nur weil etwas ein Standard ist, muss man es jedoch nicht zwingend verwenden
  • Im Web bleiben Features, die man nicht nutzen muss, und alte APIs gemeinsam bestehen
    • Deprecated APIs wie document.domain, with und <frame> werden weiterhin unterstützt
    • Features der Webplattform kann man selektiv verwenden oder weglassen

Wo Web Components passen und wo nicht

  • Web Components können vieles gut, sind aber kein Werkzeug, das alle JavaScript-Frameworks ersetzt
  • Zu ihren Schwächen zählen Server-Side Rendering (SSR), Barrierefreiheit und Teile der Interoperabilität
  • Frameworks wie React, Solid und Svelte glänzen in vielen Situationen weiterhin stärker
  • Die Aussage „Web Components sind nicht die Zukunft“ kann für bestimmte Entwickler oder Projekte zutreffen
  • Im Kern der Debatte steht die Tatsache, dass unterschiedliche Menschen unter unterschiedlichen Einschränkungen Unterschiedliches bauen

Salesforce-Beispiel und praktische Bewertung

  • Salesforce zeigt eine Umgebung, in der Web Components gut passen können
  • Wenn diese Bedingungen nicht vorliegen, muss man die gesamte UI möglicherweise nicht mit Web Components, shadow DOM und dem gesamten zugehörigen Stack bauen
  • Auf der Webplattform koexistieren Spiele, Kunstprojekte und Enterprise-SaaS-Apps, die mit ganz unterschiedlichen Features wie WebGL, Wasm und Service Workers gebaut wurden
  • Wenn neue Features zur Plattform hinzukommen, wird Kreativität nicht eingeschränkt; vielmehr entstehen mehr Möglichkeiten, sich auf Arten auszudrücken, die zuvor nicht vorstellbar waren
  • Als weiterführende Lektüre gibt es außerdem einen Beitrag von Lea Verou und einen Beitrag von Baldur Bjarnason

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-01
Meinungen auf Hacker News

  • Ich habe versucht, den referenzierten Artikel „Web Components Are Not the Future“ zu verstehen, aber viele überzeugende Argumente gab es nicht.
    Der Zustand der heutigen Frontend-Frameworks ist ein Durcheinander, und ich möchte keine komplexen Frameworks oder Magie lernen, die man ohne Dokumentation nicht versteht (useState, createSignal usw.).
    Wenn man mit Web Components anfängt, fühlt es sich intuitiv an, und man bekommt Fähigkeiten, die es anderswo nicht gibt, etwa Shadow-DOM-Isolation.
    Ich denke, das Einzige, was aus der React-Ära bleiben sollte, ist JSX, und habe eine Bibliothek gebaut, die Web Components zusammen mit JSX nutzt: https://webjsx.org

    • In dem Satz „Ich möchte kein komplexes Framework lernen“ stecken mehrere Gedanken, daher ist er schwer zu interpretieren.
      Unklar ist, ob man das Framework selbst nicht lernen will, ob man etwas möchte, das sich so magisch anfühlt, dass man es gar nicht lernen muss, oder ob man Dokumentation lesen möchte oder nicht.
      Ich habe vor allem Vue verwendet; das SPA-Ökosystem ist zwar komplex, aber wenn man Client-Apps mit komplexem Zustand verwalten will, weiß ich auch nicht recht, welches andere System möglich wäre.
    • Es gibt auch einen Unterschied darin, wie man über UI denkt.
      Das Grundmuster von jQuery ist Side-Effect-orientiert: Elemente auswählen und verändern. React oder Vue.js dagegen ermöglichen Komponenten, deren UI-Zustand durch Daten bestimmt wird.
      Wenn sich Daten ändern, wird mit minimalen DOM-Änderungen aktualisiert, und dieser Ansatz macht UI-Widgets je nach Kontext deutlich besser lesbar und wartbar.
      Heutige Websites und webbasierte Desktop-Apps sind deutlich komplexer als vor 20 Jahren; wenn man also nicht nur einfache UIs bauen will, sind Innovationen beim State Management wichtig.
    • Um eine React-App zu schreiben, muss man nicht wissen, wie useState intern funktioniert, und die Art der Anwendung ist ziemlich intuitiv.
      Die im Gegenzug vorgeschlagene Bibliothek scheint hingegen von Anfang an ein komplexeres mentales Modell zu verlangen.
      Idealerweise versteht man zwar die Details eines Frameworks tiefgehend, aber React war gerade deshalb erfolgreich, weil man auch mit sehr wenig Wissen über das interne Modell recht ausgefeilte Apps bauen konnte.
    • Angular war nicht so schwer; in etwa einer Woche konnte man es so weit lernen, dass man komplexe Sites bauen oder ordentliche PRs einreichen konnte.
      Das lag vielleicht auch daran, dass ich seit der C#-Beta-Zeit und seit den Anfängen von HTML/JS/CSS entwickle, aber es war schnell verständlich.
      Beim Ersatz eines alten, komplexen Verwaltungsportals für Kerninfrastruktur haben wir Angular gewählt; es war stabil, schnell und sah gut aus, und alle waren zufrieden.
      Die „steile Lernkurve“ scheint vor allem von Entwicklern zu kommen, die nur JavaScript und ein wenig React kennen und in die Branche eingestiegen sind; mit mehr Erfahrung kann man es sofort lernen.
    • Ein Entwickler, der wissen will, wie useState intern funktioniert, kann innerhalb von Sekunden zu einer logischen und richtigen Antwort kommen.
      Es ist weder komplex noch Magie, und eine minimale Implementierung ähnlich den React Hooks ist in ein paar hundert Zeilen möglich.
      Eine grundlegende Implementierung von useState und runFunctionComponent ist einfacher als die meisten Aufgaben im dritten Semester eines Informatikstudiums.
      Wenn das der Maßstab für Magie ist, dann ist die Umgebung voller Level-20-Warlocks, die schon beim Frühstück neue Eldritch Invocations erschaffen.

  • Einer der Gründe, warum man in dieser Debatte aneinander vorbeiredet, ist meiner Meinung nach, dass man auf unterschiedliche Ziele optimiert.
    Wenn man in einem VC-finanzierten Startup schnell vorankommt und ein Kernprodukt baut, das kontinuierlich gewartet wird, kann ein Framework gut passen.
    In einem akademischen Forschungslabor gibt es dagegen nicht viel Geld, um bereits gebaute Apps zu warten, und sie müssen weiterlaufen, auch nachdem die Förderung zum nächsten Projekt weitergezogen ist.
    Ich bin fast fertig damit, eine Vue-App als Web Components neu zu schreiben; ihre Dependencies waren verrottet und ließen sich nicht mehr aktualisieren.
    Früher habe ich Zeit damit verbracht, die Dependency-Hölle zu reparieren, und das wäre auch künftig so weitergegangen; als ich Web Components ausprobiert habe, war es sofort besser, also bin ich umgestiegen.
    Die Dependencies sind von etwa 15 auf ungefähr 1 (d3js) gesunken, und ich bereue es nicht.
    Alte App https://bam.iobio.io/, neue App https://bam2.iobio.io/

    • Diese Logik ist manchmal schwer nachzuvollziehen.
      Niemand zwingt einen, ein Framework immer auf die neueste Version zu aktualisieren; man hätte also einfach bei der verwendeten Vue-Version bleiben können.
      Ohne besonderen Grund hätte es vielleicht gereicht, bis zum Ende dieselbe Version zu nutzen.
      Das heißt nicht, dass Vue für diesen Anwendungsfall überhaupt nötig war oder dass es eine schlechte Entscheidung war, Dependencies zu entfernen; aber wenn man Vue mag, sehe ich keinen Zwang, auf der neuesten Version zu bleiben.
    • Wenn man alle Dependencies bis auf d3js entfernen konnte, hätte man dann nicht dasselbe tun und dabei auch die Vue-Dependency beibehalten können?
      Ich frage mich, ob der Grund, warum Vue zusätzliche Dependencies erfordert, im Build-System liegt.
    • Wenn man sich daran gewöhnt hat, dürfte Web-Components-Entwicklung meiner Ansicht nach nicht langsamer sein als mit irgendeinem Framework.
      Deshalb verstehe ich nicht recht, warum das VC-Ökosystem ohne Frameworks nicht auskommen können soll.
    • Es fällt schwer zu glauben, dass alle Web Components von Hand geschrieben werden, und ebenso schwer, dass es keinerlei externe Dependencies gibt.

  • Mir gefällt, dass Svelte unterstützt, Web Components über die Custom Elements API zu erzeugen.
    Da Svelte zu normalem JS/HTML/CSS kompiliert, ist es naheliegend, wiederverwendbare Komponenten zu bauen, die in jedem Framework oder auch mit Vanilla JS funktionieren: https://svelte.dev/docs/custom-elements-api

    • Rich räumt selbst ein, dass dies nicht das oberste Ziel von Svelte ist; daher wäre es nicht überraschend, wenn die Realität hinter dem Versprechen zurückbleibt.
    • Vue bietet diese Funktion ebenfalls: https://vuejs.org/guide/extras/web-components

  • Ich verfolge die Diskussion um Web Components seit Jahren, aber als Full-Stack-Entwickler ist mir immer noch nicht ganz klar, was sie tun können, um mein Leben besser zu machen
    Die meisten Beispiele gingen im Grunde nur so weit, Daten als Templates in HTML einzusetzen, und das kann man schon mit handlebars
    Übersehe ich etwas?

    • Im „Web“ gibt es ein Modell, das HTML als Dokument betrachtet, und ein Modell, das HTML als Szenengraph für komplexere Apps betrachtet
      Wenn man HTML als Dokument verwendet, kann man mit Web Components schickere Echtzeit-Interaktionsfunktionen einbauen
      Beispiele dafür sind ein Terminal-Emulator, der an WebSocket hängt, ein Datepicker, benutzerdefinierte Formularelemente, Karten, Datentabellen, Tab-Widgets und die benutzerdefinierten Komponenten, die früher jquery-ui bereitgestellt hat
      Das geht auch ohne Web Components, aber wenn man es als benutzerdefinierte Komponenten baut, bleibt das HTML viel sauberer und dokumentartiger
      Eine konsistente Web-Components-Bibliothek wäre schön, und mit HTMX und Server-Sent Events scheint auch ziemlich brauchbarer Echtzeit-Chat möglich zu sein
    • Vollständige native Isolation ist möglich
      Der Browser isoliert HTML, CSS und JS komplett, ohne zusätzliche Tricks
      Es ist angenehm, ein Web Component zu bauen, die JS-, HTML- und CSS-API klar anhand von Variablen zu definieren und sie dann in jede Umgebung einsetzen zu können, ohne dass sie kaputtgeht oder man ein Labyrinth aus komplexem CSS-Namespacing und Framework-Abhängigkeiten schaffen muss
    • Sehr gut für progressive Enhancement
      Zum Beispiel kann man mit einem Web Component um eine Tabelle Funktionen wie Filtern oder Drag-and-drop-Sortierung hinzufügen, und wenn JS deaktiviert ist oder nicht geladen werden kann, bekommen Nutzer trotzdem die einfache Tabelle und den Inhalt
      Früher war das viel besser als der weiße Bildschirm eines Frontend-Frameworks, aber inzwischen ist Server-Side Rendering breit verfügbar, sodass der Vorteil kleiner geworden ist
      Style-Kapselung ist ebenfalls gut, aber heute sind Headless-UI-Bibliotheken und scoped styles in Frameworks verbreitet, weshalb das weniger dringlich wirkt als vor zehn Jahren
      Allerdings ist es nervig, dass man sich für Shadow DOM entscheiden muss, wenn man Slots verwenden will, sodass man eigene wiederverwendbare Komponenten nicht einfach dadurch stylen kann, dass man ein Stylesheet in die Seite einbindet
    • Der Grund, warum die Beispiele dynamische APIs vermeiden, dürfte sein, dass dieser Teil sehr hässlich und zustandslastig ist
      Wenn eine Demo 200 Zeilen manuelle DOM-Manipulation zeigt, ist es schwer zu behaupten, Web Components seien die Zukunft
    • Web Components ermöglichen es, UI-Komponenten, die mit einem anderen Framework gebaut wurden, in meinem Framework zu verwenden
      Das ist alles, und für die meisten anderen Zwecke sind sie ziemlich schlecht
      Außerdem kann man UI-Komponenten so veröffentlichen, dass sie in allen Frameworks funktionieren, statt sie in sieben Versionen zu bauen

  • Das Schlimmste an Web Components und Shadow DOM ist, dass sie Browser-Erweiterungen daran hindern können, richtig oder überhaupt zu funktionieren
    Die Browser-Anbieter beeilen sich auch nicht, diese Situation zu beheben

    • Die Konfigurierbarkeit des User Agents ist das Killer-Feature des Webs

  • Einer der größten „Fehler“ von Web Components war meiner Meinung nach, dass sie in den Köpfen der Leute mit Shadow DOM verknüpft wurden
    In der App-Entwicklung werden Web Components zu einer sehr leichten und einfachen Option, wenn man beim Live DOM bleibt
    Man kann weiter die gewünschten CSS-Tools wie bootstrap, tailwind usw. verwenden und bekommt trotzdem nahezu kostenlos eine hervorragende funktionale Kapselung, besonders wenn man etwas wie lit-html als Renderer nutzt
    Teams empfanden die Arbeit mit nativen Web Components meist als erfrischend, und Entwickler aus der Framework-Welt wollten nach etwa einer Woche Eingewöhnung nicht mehr zurück
    Schon mit einfachen Klassen-Properties und dem manuellen Aufruf der Render-Funktion aus set() bekommt man die Vorteile von Reaktivität, ohne den Ballast eines Frameworks
    Das Problem ist, dass es kaum Material gibt, das zeigt, wie man im „Easy Mode“ anfängt
    Die meisten Einführungen stoßen einen direkt in schmerzhafte Techniken wie Shadow DOM und CSS parts, die eher für Bibliotheksautoren als für App-Entwickler gedacht sind
    Vermutlich sollte man einen Leitfaden wie „The Good Parts“ schreiben, der zeigt, wie Web Components das Leben einfacher machen

    • Ich verwende Shadow DOM täglich, aber genau das ist meist auch der Teil von Web Components, der die Leute am meisten verwirrt. Vermutlich, weil sie ihn nicht brauchen
      Als Alternative gibt es „HTML web components“, die nur Live DOM verwenden, Server-Side Rendering priorisieren und gut als Ersatz für „jQuery-Würze“ taugen: https://adactio.com/journal/20618
      Außerdem gibt es „Shadow gristle“, bei dem Shadow DOM nur so wenig wie möglich verwendet wird und Styling oder Komposition im Live DOM bleiben, wenn sie nötig sind: https://glazkov.com/2023/03/02/shadow-gristle/
    • Wenn du darüber schreibst, würde ich es gern lesen. Anhören wäre auch gut
      Diese Technik scheint je nach Einsatzweise sowohl Segen als auch Fluch zu sein, daher sammle ich gerade Material und Kommentare dazu
    • In meinem früheren Job haben wir denselben Stack verwendet, also WC ohne Shadow DOM und nur lit-html, und das war sehr gut
      Das Beste daran ist, dass man nicht alle zwei Wochen in die Dependency Hell gerät
    • Genau das ist der Punkt. Was derzeit fehlt, sind Slots für light DOM

  • Interoperabilität ist aus Nutzersicht der größte Vorteil, aber ich glaube, dabei wird unterschätzt, dass dafür bei jeder verwendeten Komponente Performance-Kosten entstehen können, weil unnötige Runtimes mitgeschleppt werden
    Der empfohlene Weg ist, zusammen mit Web Components Frameworks wie Lit zu verwenden; wenn mit der Zeit neue Frameworks entstehen und Komponenten an alte Versionen gebunden bleiben, summieren sich diese Kosten
    Eine Richtung, in der auf einer Seite mehrere duplizierte Libraries liegen, würde ich niemandem empfehlen; wenn das zu den Best Practices gehört, ist das langfristig nicht gut
    Ich habe über Jahre Artikel, Social-Media-Posts und Videos von Web-Components-Befürwortern gesehen, und eigentlich müsste genau ich zur Zielgruppe gehören, aber zusätzlich zur Interoperabilitätssteuer gibt es jede Menge Nachteile, die Mainstream-Frameworks nicht haben
    Innerhalb der jeweiligen Framework-Ökosysteme funktioniert Interoperabilität gut, und dieselben Dynamiken, die Entwickler nach Interoperabilität suchen lassen, führen dazu, dass sie sich um einige wenige Mainstream-Frameworks sammeln
    Web Components holen technisch nicht auf und fügen der Web-Plattform meiner Ansicht nach viel Komplexität für ein Design aus den frühen 2010ern hinzu: https://x.com/Rich_Harris/status/1840116730716119356

    • Ich habe das in einem anderen Artikel behandelt, aber im Großen und Ganzen ist nicht jede Web-App bei jedem zusätzlichen kB performance-sensibel. E-Commerce ist es, Produktivitätstools normalerweise nicht
      Es gibt viele Frameworks mit kleiner Runtime wie Svelte, und ich sage nicht, dass man 100 davon auf eine Seite packen sollte, aber 5 oder 6 halte ich für in Ordnung
      Das heißt nicht, dass es ideal ist, kann aber bei schrittweiser Migration oder Micro-Frontends hilfreich sein
      Nebenbei: Auch React 17 hat die Möglichkeit eingeführt, mehrere React-Versionen auf derselben Seite zu haben: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • Das stimmt zwar, aber wenn man sich die meisten heute gebauten Web-Apps ansieht, wirkt das Problem mehrerer Libraries fast wie ein Rundungsfehler
      React und react-dom zusammen kommen auf über 100 KB, Svelte und Lit liegen im einstelligen KB-Bereich
      Man könnte ziemlich viele Frameworks einbauen, bevor man auch nur in die Nähe des Ballasts kommt, den Leute täglich ohne nachzudenken verwenden
    • Weiter gefasst müssen Web Components Framework-Autoren überzeugen
      Die Signale, die ich bisher durchgehend gesehen habe, sind nicht gut; diese Community ist auf X, und Web Components lösen ihre Probleme nicht und werden selbst im Optimalfall nicht gut genutzt
      Ich hoffe, die Überzeugungsarbeit gelingt, aber im Großen und Ganzen sagen sie eher, Web Components seien gescheitert und insgesamt schlecht für das Web gewesen
    • Dieses Argument verstehe ich ehrlich gesagt nicht so richtig
      Die meisten Runtimes sind ziemlich klein, und nur weil zwei Runtimes gleichzeitig laufen, entsteht nicht unbedingt ein großer Performance-Overhead
      Moderne Web-Frameworks sind alle reaktiv, sie tun also nichts, wenn es nichts zu reagieren gibt
      Ich sehe kaum einen Grund, warum die User Experience oder der Akkuverbrauch merklich schlechter sein sollte als bei einer Seite mit nur einem Framework, wenn ein Teil der Seite mit React, ein anderer mit Lit und wieder ein anderer mit Svelte gebaut ist
      Der zitierte Tweet dreht sich darum, ob Web Components „nützliche Primitive zum Bauen von Frameworks“ sind; selbst Fans, die sie tatsächlich verwendet haben, würden das wohl meistens nicht behaupten
      Web Components sind ein Distributionsmechanismus, und wenn die Alternative nur darin besteht, dieselbe Library siebenmal für React, Preact, Svelte, Solid, Vue und Vanilla JS zu bauen, ist das furchtbar

  • Ich mag Web Components und bin optimistisch, dass sie uns aus der aktuellen Frontend-Hölle herausführen können, die wir uns selbst geschaffen haben
    Kürzlich habe ich einen kurzen Vortrag über die Zukunft des Frontends gehalten, und es schien, als hofften auch andere auf einen Ausweg
    Ich habe eine Datentabelle für eine DB-GUI gebaut, und selbst beim Laden von Hunderttausenden Zeilen scrollt sie sehr flüssig
    Eine Web-Component-Library will ich ebenfalls bald veröffentlichen; sie ist noch früh und rau, aber ich würde mich freuen, wenn mehr Leute sie sich ansehen: www.astra-ui.com

    • Meiner Ansicht nach ist der einzige Weg aus der aktuellen Frontend-Hölle clientseitiges import: https://github.com/whatwg/html/issues/2791
    • Ich habe mir die Doku angesehen, und auf Safari 18.0 auf einem iPhone 15 Pro Max rendert sie sehr seltsam
      Es wäre gut, die Sidebar mit Blick auf responsives Design für kleine Bildschirme neu anzuordnen und dem body statt width eher max-width zu geben
      Der Button „explore components“ unten auf der Homepage scheint nirgendwohin zu verlinken
      Es heißt, man solle „von gut strukturierten und zugänglichen Komponentenimplementierungen lernen“, aber ich konnte in der Doku keinen Link zur Implementierung finden
      Es heißt, es gebe „keine Abhängigkeiten zu verwalten oder zu aktualisieren“, aber astra-ui selbst ist doch wohl eine Abhängigkeit, und es gibt auch ein Changelog: https://www.astra-ui.com/changes/
      Außerdem heißt es, man habe „vollständige Kontrolle über Code und Styling“, aber ich verstehe nicht, wie vollständige Kontrolle möglich sein soll, wenn man sich auf die von der Library bereitgestellte Implementierung verlässt
      Ich frage mich, warum ihr euch entschieden habt, diese Library zu veröffentlichen. Interne Software als Open Source freizugeben kann nützlich sein, wenn ein Unternehmen bestimmte Ziele hat, wird aber normalerweise leicht zu einem Zeitfresser ohne Gegenleistung
      Komponenten-Libraries müssen um die Akzeptanz im Ökosystem kämpfen; ohne sie gibt es kein Publikum und wenig Grund, sie zu veröffentlichen
    • Warum sollte man das statt etwas wie Vue-Komponenten verwenden?
    • Warum haben sich Web Components noch nicht durchgesetzt oder werden nicht breiter genutzt?
      Sie wirken wie eine hervorragende Lösung
    • Ich habe den Frontend-Anzeigencode des Unternehmens mit Web Components neu geschrieben

  • Vor ein paar Monaten habe ich in meinem neuen Job eine JS-Codebasis mit rund 250.000 Zeilen geerbt.
    Eine einzige riesige Klasse und ein paar Unterklassen machten alles, manche Dateien hatten sogar 30.000 Zeilen.
    Es gab weder Framework noch Reaktivität, sodass man beim Klick auf einen Button per Event Listener alles auf dem Bildschirm manuell aktualisieren musste.
    Es wirkte wie Code, den jemand über Jahre in einer Klosterzelle nur mit einem grundlegenden JavaScript-Buch geschrieben hatte.
    Weil ich schrittweise vorgehen musste, begann ich mit einem Refactoring auf Web Components; das hat sehr geholfen, und bisher habe ich 50.000 Zeilen reduziert.
    Der eigentliche Zweck war allerdings, vor einer Neufassung alles zu lernen, was der bestehende Code tut.

    • Der Schlüssel zum Verständnis einer alten, undurchsichtigen Codebasis ist, sie Stück für Stück zu refaktorisieren.
      Sie mit Web Components neu aufzubauen ist eine Möglichkeit, dieses Ziel zu erreichen, und gut ist, dass nicht alles weggeworfen und von vorn begonnen wurde.
      Allerdings besteht das Risiko, dass man nach einem gewissen Fortschritt auf ein anderes Projekt wechselt, die nächste Person kommt und in ihrem eigenen Stil mit dem Refactoring beginnt – und am Ende eine undurchsichtige Codebasis mit drei verschiedenen Stilen entsteht.
      Trotzdem ist es besser, als 250.000 Zeilen auf einmal neu zu schreiben.

  • Ein Punkt, der mir an Web Components gefallen hat: Zumindest theoretisch können sie auch bei deaktiviertem JS funktionieren.
    Für Progressive Enhancement habe ich das ein paar Mal so gemacht.
    Insgesamt stimme ich Nolan zu. Web Components haben genug raue Kanten, dass sie in ihrem aktuellen Zustand kaum die Welt erobern werden, aber für bestimmte Anwendungsfälle sind sie ziemlich gut.
    Allerdings verstehe ich nicht so recht die Aussage, dass sie nicht gut zu Server-Side Rendering passen; bei mir hat das problemlos funktioniert.

    • Mich würde interessieren, warum du das sagst.
      Soweit ich gesehen habe, braucht man JavaScript, um für ein bestimmtes Tag ein Template zu registrieren: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • Ich weiß nicht, wie das funktionieren soll.
      In ReactJS kann man Komponenten oder Templates serverseitig rendern, und JSX ist aus meiner Sicht eine ziemlich gute Template-Sprache.
      Web Components haben keine eingebaute gute Template-Sprache, soweit ich verstehe, muss man selbst eine mitbringen.
      Ich kenne keinen Standardmechanismus, der das mit einem Tag verknüpfte JS-Komponentenstück nimmt und ohne JS-Ausführung das benötigte HTML rendert.
    • Ich bin der Autor. Ich habe das in einem anderen Beitrag behandelt, aber im Grunde gibt es die Interoperabilitätsvorteile, die man auf dem Client bekommt, auf dem Server noch nicht.
      Wenn man künftig auf dem Server drei verschiedene Web-Component-Frameworks rendern kann, sie sich miteinander komponieren lassen und sauber hydriert werden, dann könnte man das als gelöst betrachten: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/