Wird 2023 das Jahr von Web-Components?! // deutsch

Web-Components werden mit schöner Regelmäßigkeit seit einigen Jahren als "das nächste große Ding" bezeichnet. Doch was sind Web-Components überhaupt? Wie funktionieren sie und was können sie? Wo liegen die Grenzen von Web-Components? Und wie sieht ihre Zukunft aus?

00:00 – Einleitung
01:04 – Was sind Web-Components?
02:46 – Komponenten in HTML
04:09 – Web-Components als nativer Ansatz
05:10 – Baustein #1: Das Template-Element
06:29 – Baustein #2: Das Shadow-DOM
08:17 – Baustein #3: Custom-Elements
09:24 – Browserunterstützung
10:30 – Technische Hürden
11:37 – Wenig durchdacht
12:54 – Fehlendes Tooling
13:53 – Fehlender Komfort
14:29 – Frameworks für Web-Components
15:59 – Zukunftsaussichten

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[niorad]

Danke für das Video! Wir arbeiten seit ca. 2, 5 Jahren an diversen CRUD–Apps auf WC/Lit-Basis (#SPA, #Typescript).
Meine Erfahrung deckt sich recht genau mit eurer. Dev-Tooling ist leider etwas clumsy, jedoch gibt es zumindest für VSCode Plugins dafür und man bekommt auch in den Template-Strings vernünftiges Highlighting, Formatting und Typescript-Features.
WebComponents sind low-level APIs zur Erzeugung neuer Elemente, und kein React/Vue/…-Ersatz. Es ist eine Sammlung von Plattform-Standards, nicht der Effort einer (kommerziellen) Instanz, welche Interesse an Adaption und DX hat, wie React oder Ng. Das wird oft nicht verstanden.
Man kann das schon als React-Ersatz benutzen (machen wir ja auch :), aber dann kämpft man leider gegen einige der genannten Drawbacks ggü. den beliebten Frameworks.

[yt]

Danke für das interessante Video. Um es kurz zu machen, fehlt mit einfach die Zeit für solche "Experimente". Und wenn du schon Probleme hast, werde ich einfach warten bis die notwendige Browser-Unterstützung kommt um dies zu vereinfachen. Für jedes Problem ein neues npm Paket ist jedenfalls nicht (mehr) meine Philosophie.
Schöne Woche!

[hgloeckl]

Hallo wir benutzen WebComponent & lit in unserem Projekt. Wir sind sehr zufrieden.
Vielen Dank für deine extrem guten Erklärungen. Du hast echt Talent für diese Art von ...

[MMNewmedia]

Mittlerweile schreiben wir das Jahr 2024 und ich habe dann auch mal Zeit gefunden mich mit dem Thema Web Components auseinander zu setzen. Als Basis habe ich mir ein eigens mit nativem JavaScript umgesetztes Drag and Drop Upload Tool genommen und es auf Web Components umgeschrieben. Als IDE (Editor im weitesten Sinne) habe ich mal VS Code anstatt von PHPStorm heran gezogen. Zu beginn war ich begeistert, weil ich Code und Funktionalität wunderbar kapseln konnte. Dann kam ich aber in den Bereich, den Du auch in Deinem Video angesprochen hast.

- Die Dokumentation von Web Components und den damit zusammenhängenden Custom Elements ist gut, aber irgendwie auch alt. Templates als Strings? Ich bin dazu über gegangen den HTML Code in HTML Dateien zu kapseln und diese wie in einer Art Template Engine zu nutzen. Gut, ein zusätzlicher Request pro Custom Element. Aber hey ... zum lernen ganz geil, aber nirgends dokumentiert.
- Es gibt zwar so eine Art State Mangement für Attribute des Custom Elements, aber irgendwie fühlt sich das alles so schräg ungewohnt und oldschool an. Allerdings bin ich als Entwickler eben auch ein Gewohnheitstierchen. Ich leg 's einfach mal unter "Comfort Zone auch mal verlassen" ab.
- Meine IDE kann das mittlerweile erstaunlich gut. Gut, anonyme Klassen, wie sie in der Dokumentation vorkommen, sind für den Popo. Aber sobald man wirklich mit zu importierenden Klassen innerhalb eines Namensraumes arbeitet, ist das alles ziemlich handy. Da scheint sich doch ein wenig was getan zu haben.
- Vieles an Funktionalität muss selbst hinzugefügt werden. Mitunter gut, weil man so eine Komponente dann nicht überladen ist. Aber irgendwie auch schlecht, weil man so gut wie alles selbst rein hacken muss.

Mein persönliches Fazit: Irgendwie doch ganz geil. Ich werde dran bleiben.

[snapstromegon]

Ich glaube, ich muss meine Einstellung hier zu Web Components und Lit nicht groß erwähnen, nachdem ich in dem viel erwähnten Livestream als Gast eben Lit eingesetzt habe, aber ich möchte dennoch noch ein paar Worte zu dem Video verlieren.

Insgesamt ist das was hier gesagt wird allgemein nicht wirklich falsch und ist auch das, was viele in der JS-Welt denken, aber da gibt es halt noch ein aber...

Ich hangle mich jetzt mal etwas an dem Inhalt des Videos entlang:
Beginnen wir bei 9:55 "Wo sind sie denn?". Und die Antwort überrascht hier sicher viele: "Überall" - na gut, nicht wirklich überall, aber die Statistiken con Chrome sagen das ~18% aller Seitenaufrufe mindestens eine WebComponent nutzen und immerhin über 8% aller Origins nutzen laut HTTP Archive mindestens eine WebComponent. Zum Vergleich: React wird (in allen Versionen) laut W3 Tech nur auf rund 3, 3% aller Seiten genutzt. Dass die % der Seitenaufrufe so hoch ist, hat auch damit zu tun, dass viele große Seiten wie zum Beispiel YouTube auf WebComponents setzen.

Gehen wir weiter zu "WebComponents im Vergleich zu React, Vue, ...". Ich denke persönlich, dass WebComponents kein Ersatz sind für solche Frameworks, sondern (hier ein wenig vorweggreifend) eine Möglichkeit für mehrere Frameworks Komponenten zu entwickeln. Dadurch kann es sich allerdings häufiger ergeben, dass ein Framework insgesamt als komplett überflüssig angesehen wird (wie zum Beispiel im Livestream). Wenn man WebComponents so aufgreift, dann kommt es auch absolut nicht mehr komisch vor, dass es Frameworks für die Erstellung von diesen gibt, da der Vorteil hauptsächlich in der Nutzung liegen soll.

Angelehnt daran auch ein Punkt zum "State Management". Ja, hier gibt es wenig direkte Integrationen, aber wenn man WebComponents "richtig" nutzt, ist das ein wenig wie sich zu beschweren, dass das <input> Element nicht richtig mit dem eigenen State Management integriert ist. Auch wenn es inzwischen da bewusste Integrationen gibt (gerade über sowas wie Lit), so finde ich es sauberer das Konzept des langlebigeren und allgemeineren States aus der Komponente heraus zu ziehen.

Dann kommt ein leider sehr richtiger Punkt: "Registrierung unter dem jeweiligen Namen". Aktuell ist das zum Glück noch selten ein Problem, weil eben der erste Teil des Namens gerne als Namespace genutzt wird, aber es gibt tatsächlich einige Quellen, die es Bevorzugen wenn die Applikation die Registrierung übernimmt. Was hier wirklich der allgemein bessere Weg ist will ich nicht bewerten.

Beim Punkt "HTML als String im JS Code" kommen mir persönlich mehrere Gedanken. Zum einen ist das "einfach so" sicher nicht für den alltagsflow geeignet, aber mit relativ einfachen VSCode Einstellungen kann man schonmal zumindest HTML Syntax Highlighting und Emmet Support bekommen. Gerne lagert man das HTML auch in einen eigene HTML Datei aus und importiert diese dann als Template über weiteres Tooling. Das ist aber auch nicht unbedingt schön. Hier gefällt mir tatsächlich der Ansatz von Lit mit den tagged template literals am Besten.

Insgesamt aber trotzdem ein gutes Video und ich bin gespannt was zum Thema WebComponents (und Begleitwerk) noch so auf diesem Kanal passiert.

[albreax]

Hab das Video erst jetzt gesehen...
Wir arbeiten seit einiger Zeit mit Web-Components. Dafür haben wir bei unterschiedlichen Projekten StencilJS als auch Lit benutzt. Bei Stencil scheint die Entwicklung eingeschlafen. Aber Lit hat schon ganz gut überzeugt.
Dabei ist unserer Ansatz eine Component-Library mit Custom-Elements zu erstellen. Die Library nutzen wir dann als Node-Modul in einer App. In der App kommt dann eins der großen Frameworks zum Einsatz und es werden dann in ihr Pages aus den Elementen zusammen gesetzt. Das Framework übernimmt dann Stage-Management, Routing etc. 
Der kleine Nachteil ist der etwas erhöhte Konfigurationsaufwand.
Wir sind jedoch mittlerweile recht überzeugt von dem Ansatz.

[ES-cfph]

Ich habe vor etwa nem Jahr für meinen Arbeitgeber evaluiert, was für JavaScript Frameworks für uns geeignet wären, und da war Lit tatsächlich auch eine Empfehlung neben Vue, weil es deutlich leichtgewichtiger ist als React. Ich finde außerdem auch nicht, dass WevComponents und Frameworks sich ausschließen, weil 1. Frameworks wie Vue selber WebComponents bereitstellen können und 2. Sie eben ermöglichen, Komponenten Framework Übergreifend zu nutzen. Ne WebComponent kann man, so fern sie ne einfache Low Level Komponente wie z.B. nen selbst gestyleten Butten anbietet, halt sogar in Server gerenderten Seiten außerhalb des JS Ökosystems nutzen, z.B. in PHP, weil es von außen halt wie normales HTML aussieht. Selbst Vue tut sich mit so etwas deutlich schwerer, weil einzelne Styles halt immer noch als Cascaded CSS des Horrors abgebildet werden müssten, damit man z.B. modernes Frontend mit einer Legacy PHP Web App kombinieren kann.

[DogzDeDoggy]

Sehr witzig. Komme aus Videos zu Web Components bzw. Lit und war recht angetan. Nun wollte ich mal schauen, was denn der Golo dazu sagt, und der ist genauso hin- und hergerissen wie ich. Die Infos im Video geben es gut wieder. Ich denke ich probiere mal über Ostern (2023) etwas herum. Mal sehen, wie weit es trägt und wo ich dann für mich die Painpoints identifiziere bzgl. Tooling.

[florianwilhelm]

Ich schaue mir regelmäßig Eure Videos an und finde das sie absolut underrated sind.

[zickzack]

Wenn ich nur endlich mal verstehen würde, warum diese Javascript Frameworks überhaupt nötig sind.
Html und Css auf dem Server generiert tun's nicht mehr? 🤔😎

[devchannel]

4:00 so true die Aussage, gefühlt bestehen Seite aus 80% Divs :D. Selbst Buttons mit Icons sind manchmal Divs mit click-Event xD.

Top Video!