Web Components werden dein JavaScript-Framework überdauern

• Ein Artikel über die Langlebigkeit und Flexibilität von Web Components im Vergleich zu JavaScript-Frameworks
• Der Autor argumentiert, dass die Technologiewahl eines Projekts nicht durch Standardoptionen, sondern durch die Einschränkungen des Projekts bestimmt werden sollte
• Gründe des Autors für die Wahl von Web Components mit Vanilla JS für sein Projekt: Portabilität und die Fähigkeit, HTML zu rendern
• Der Blog des Autors wurde mit verschiedenen Tools aufgebaut, darunter Astro, Hugo, ein benutzerdefiniertes CMS in PHP, Tumblr, Movable Type und WordPress
• Hervorgehoben werden die Vorteile, Inhalte in einfachen Textdateien zu halten, die in Markdown geschrieben sind, was den Wechsel von Inhalten zwischen Systemen vereinfacht
• Der Autor sagt, dass bestimmte Astro-Funktionen zwar praktisch sind, im Projekt jedoch nicht verwendet wurden, da sie nicht portabel sind
• Web Components können als HTML innerhalb von Markdown geschrieben werden und sind dadurch genauso portabel wie der restliche Markdown-Inhalt
• Web Components sind ein W3C-Standardset zum Erstellen wiederverwendbarer HTML-Elemente, das HTML, CSS und JS in einer einzigen Datei kapselt und kein Build-System erfordert
• Der Autor weist darauf hin, dass Web Components Attribute bereitstellen können, um von außen konfiguriert zu werden, ähnlich wie native Props
• Aus Sorge über Kompromisse bei Wartung und Abhängigkeiten entschied sich der Autor für Vanilla JS statt für Frameworks wie Lit, Stencil oder Svelte, die zu Web Components kompilieren
• Der Autor argumentiert, dass Abhängigkeiten wie TypeScript zwar nützliche Funktionen bieten können, aber Zeit und Aufwand erfordern, um die Kompatibilität mit neuen Versionen und APIs aufrechtzuerhalten
• Betont wird, wie wichtig es ist, Abhängigkeiten zu vermeiden, die Nutzer nicht kontrollieren, und für langfristige Zugänglichkeit sowie die Widerstandsfähigkeit von Webinhalten bei stabilen, bewährten Standards zu bleiben
• Abschließend lobt der Autor das Web als die widerstandsfähigste, portabelste und zukunftssicherste Computing-Plattform, wenn man es mit Blick auf Langlebigkeit nutzt

[GN⁺]

Hacker-News-Kommentare

• Ein Artikel über die Langlebigkeit von Web Components im Vergleich zu JavaScript-Frameworks
• Die Kommentierenden weisen darauf hin, dass die htmx-Bibliothek im Artikel nicht erwähnt wurde und sich von Web Components dadurch unterscheidet, dass sie sich auf die Synchronisierung von Server und Zustand konzentriert
• htmx wird dafür gelobt, keine Abhängigkeiten zu haben und auf Abwärtskompatibilität zu setzen, anders als viele JavaScript-Bibliotheken
• Das State-Management von Web Components wird als ungelöstes Problem genannt, das Entwickler ohne Wrapper-Framework direkt selbst handhaben müssen
• Die Performance von Web Components sei nicht so wichtig wie erwartet; einige kleinere Elemente wurden wegen der Instanziierungskosten wieder von Web Components weg migriert
• Web Components werden dafür gelobt, dass sie sich unabhängig vom verwendeten Framework leicht zu neuen Seiten hinzufügen lassen, sowie für ihre Style-Kapselung
• Einige Kommentierende äußern, dass sie den Fortschritt und die Verbesserungen von JS-Frameworks statischen Lösungen wie Web Components vorziehen
• Betont wird, wie wichtig es ist, beim Start eines neuen Projekts das Wissen und die Fähigkeiten des Teams zu berücksichtigen
• Serverseitige Lösungen wie Rails Hotwire, Phoenix Liveviews und Laravel Livewire werden als interessante Entwicklungen erwähnt
• Web Components werden dafür kritisiert, dass sie nicht auf dem Server ausgeführt werden können und clientseitiges JS zum Rendern benötigen
• Die Verwendung von Slots in Web Components wird als verwirrend und komplex kritisiert, was sie für den Aufbau von Anwendungen weniger attraktiv macht
• Die DOM API wird dafür kritisiert, nicht gut dafür geeignet zu sein, Komponenten zusammenzufügen, damit eine Anwendung funktioniert
• Web Components werden für die mangelnde Editor-Unterstützung bei Funktionen wie Autovervollständigung von Attributen und Event-Namen kritisiert
• Einige grundlegende Funktionen in Web Components, etwa Buttons innerhalb von Formularen, bleiben weiterhin ungelöste Probleme