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!
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.
Hi Antonio, Danke für deinen Beitrag. Ich dachte bisher ich kann hier vielleicht mit starten ohne mir so einen Framework und Depenedency Overkill reinzuholen. Und das es auch irgendwie nachhaltiger im Bezug auf Performance und Energie ist. Was denkst du?
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 ...
Ja, Lit finde ich auch ziemlich cool. Ein guter Kompromiss weil mein nicht die gesamte React Library nutzen muss, aber dennoch Components entwickeln kann, die sich selbst aktualisieren etc.
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.
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.
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.
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 RUclips 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 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.
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.
@@thenativeweb Sind gerade dabei „Vanilla“ Web Components (in Typescript geschrieben) in Stencil umzuschreiben - lässt sich echt ne menge aufräumen. LIT habe ich mir nur grob angeschaut, siehe aber ziemlich ähnlich aus :)
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? 🤔😎
Auch wenn ich grundsätzlich zustimme, dass vieles was heute mit JS Frameworks gelöst wird mit Sicherheit das nicht bräuchte und ein Static Site Generator eine deutlich bessere Lösung wäre, so gibt es doch einige Einsatzbereiche wo Clientseitiges JS doch sehr hilfreich ist (hier anzumerken ist aber auch, dass Server gerendertes HTML und CSS und Javascript Frameworks ja kein entweder/oder ist). Wenn ich zum Beispiel meine Web App offline verfügbar machen möchte mit der Option für Push Notifications oder Background Sync oder ich eingaben zwischen zwei Clients synchronisieren möchte oder live Daten anzeigen möchte, dann komme ich um Clientseitiges JS nicht herum. Auch wenn ich zum Beispiel eine Demo in meinem Blog baue, die die aktuellen Coronazahlen für alle Kommunen und Länder in Deutschland anzeigen und der Nutzer eine Region auswählen kann, kann ich natürlich jedes Mal die gesamte Seite neuladen, oder ich nutze einen kleinen Fitzel JS und ersetze den entsprechenden Teil im DOM. Wenn jetzt diese Einsatzgebiete noch komplexer werden und ich quasi eine ganze Applikation im Browser habe wie zum Beispiel Photoshop oder Figma, dann ist es relativ klar, warum sich dann auch JS Frameworks lohnen.
@@zickzack987 Quasi das selbe könnte man aber auch über SSR sagen. Allein wenn ich mal darauf blicke wie viele WordPress Blogs es da draußen gibt, die immer nur statischen Content anzeigen. Da wäre ein SSG Ansatz viel sinniger.
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!
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.
Hi Antonio,
Danke für deinen Beitrag. Ich dachte bisher ich kann hier vielleicht mit starten ohne mir so einen Framework und Depenedency Overkill reinzuholen. Und das es auch irgendwie nachhaltiger im Bezug auf Performance und Energie ist. Was denkst du?
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 ...
Ja, Lit finde ich auch ziemlich cool. Ein guter Kompromiss weil mein nicht die gesamte React Library nutzen muss, aber dennoch Components entwickeln kann, die sich selbst aktualisieren etc.
Ich schaue mir regelmäßig Eure Videos an und finde das sie absolut underrated sind.
, dass
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.
Danke für Deinen Kommentar 😊
Hast Du ruclips.net/video/cttpgBg6pDQ/видео.html schon gesehen?
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.
Tolles Video!
Danke, tolle Inspiration
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.
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 RUclips 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 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.
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.
Stencil JS 👍
Ich persönlich stehe eher auf Lit, aber ja - why not?
@@thenativeweb Sind gerade dabei „Vanilla“ Web Components (in Typescript geschrieben) in Stencil umzuschreiben - lässt sich echt ne menge aufräumen. LIT habe ich mir nur grob angeschaut, siehe aber ziemlich ähnlich aus :)
Bitte mehr programmierpodcasts
Ich glaube kaum, dass GR dafür Ressourcen hat. Dafür ist die Zielgruppe und der Nutzen einfach zu klein.
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!
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? 🤔😎
Auch wenn ich grundsätzlich zustimme, dass vieles was heute mit JS Frameworks gelöst wird mit Sicherheit das nicht bräuchte und ein Static Site Generator eine deutlich bessere Lösung wäre, so gibt es doch einige Einsatzbereiche wo Clientseitiges JS doch sehr hilfreich ist (hier anzumerken ist aber auch, dass Server gerendertes HTML und CSS und Javascript Frameworks ja kein entweder/oder ist). Wenn ich zum Beispiel meine Web App offline verfügbar machen möchte mit der Option für Push Notifications oder Background Sync oder ich eingaben zwischen zwei Clients synchronisieren möchte oder live Daten anzeigen möchte, dann komme ich um Clientseitiges JS nicht herum. Auch wenn ich zum Beispiel eine Demo in meinem Blog baue, die die aktuellen Coronazahlen für alle Kommunen und Länder in Deutschland anzeigen und der Nutzer eine Region auswählen kann, kann ich natürlich jedes Mal die gesamte Seite neuladen, oder ich nutze einen kleinen Fitzel JS und ersetze den entsprechenden Teil im DOM.
Wenn jetzt diese Einsatzgebiete noch komplexer werden und ich quasi eine ganze Applikation im Browser habe wie zum Beispiel Photoshop oder Figma, dann ist es relativ klar, warum sich dann auch JS Frameworks lohnen.
kommt ja gerade wieder, nennt sich SSR. hast nix verpasst.
@@snapstromegon Klar. Aber Fakt ist eben, dass 99% aller Webseiten das nicht brauchen und trotzdem nutzen, weil das halt so muss 😒😁
@@niorad Ist dann doch immer noch ein völlig überladenes Framework mit hyper kompliziertem Build, npm und Tralala. Gruselig.
@@zickzack987 Quasi das selbe könnte man aber auch über SSR sagen. Allein wenn ich mal darauf blicke wie viele WordPress Blogs es da draußen gibt, die immer nur statischen Content anzeigen. Da wäre ein SSG Ansatz viel sinniger.
Nichts übertrifft geschnittenes Brot.
? Warme Semmeln