Web Components und Co.: Zwischen Konsternation und Glückseligkeit

Robin LöffelOktober 2019

Filip Rakowski hat dieses Jahr an der Front Conference über ein Thema referiert, das schon seit einigen Monaten für viel Lärm und Kontroversen in der Community sorgt: Web Components. Er zeigte Pros und Kontras auf, verwies uns auf einen Artikel von Rich Harris mit dem Titel «Why I Don’t Use Web Components» und zeigte uns ein bisschen Svelte. Hier meine Gedanken dazu.

Die ersten Eindrücke

Vor einigen Monaten habe ich mir das neueste Super-Ding im Frontend-Universum ein bisschen zur Brust genommen: Web Components. Komplett neue HTML-Elemente definieren und das ohne Angular, Vue oder React? «Das klingt ja mal nice!», dachte ich mir.Ich fühlte mich in etwa so, wie wenn ich im Tram nach Hause sitze und weiss, dass dort ein Päckli auf mich wartet, welches der Pösteler liebevoll im Treppenhaus nur für mich deponiert hat.Als ich das Tutorial auf MDN durchspielte und mir diverseste YouTube-Videos zu Gemüte führte, merkte ich aber relativ schnell: Um eine «Custom Component» zu schreiben braucht es viel Code. Beim ersten partiellen Beispiel auf MDN sind wir schon bei 39 Zeilen – ohne Konstruktor (neue Elemente sind Klassen), Styling oder jegliche Reaktivität. Ich war ein bisschen ernüchtert.

Nativ: Flop; Gewrappt: Top?

Ich mag CSS-in-JS nicht. Kann sein, dass ich da ein bisschen altmodisch bin, aber ich kann mich damit einfach nicht anfreunden. Es schaut unschön aus – was sucht dieser Style-Template-String plötzlich hier? – und zerstört die Separation of Concerns zwischen Aussehen und Logik.Web Components machen passioniert davon Gebrauch. Style-Tags werden innerhalb der Klasse definiert und dem Shadow DOM angehängt; vom Verlinken auf externe CSS-Sheets wird explizit abgeraten. No me gusta. Dazu kommt, dass ich ein grosser Freund von Sass und PostCSS bin. Diese in Web Components einzusetzen, ohne seine Webpack- oder Rollup-Config umzukrämpeln, ist nicht möglich. No me gusta nada.Wo ich allerdings erst richtig beginne zu nörgeln ist bei den Polyfills, denn Gott sei Dank müssen wir den allerseits beliebten Internet Explorer 11 unterstützen. Edge war früher ebenfalls ein Problem, versteht sich seit einiger Zeit nun aber schon voll gut mit Chrome und ist deswegen auch zu seinem Homie ins Blink-Camp gezogen, wo auch Opera in der Hängematte chillt.Die Polyfills, die wir folglich für Kundenprojekte brauchen, sind ziemlich schwer. Und hier rede ich nicht nur von den Polyfills, die für Web Components nötig sind, sondern auch von den Polyfills, die fürs Transpilieren via Babel von ESNext zu ES5 gebraucht werden. Ein simples Bundle wird da schnell mal mehrere 100kb gross. Whoops.Case closed, also, oder? Web Components sind blöd und man muss zu viel Code schreiben – basta. Na, na, na, nicht so voreilig! Denn es gibt Wrapper-Libraries, die viele angenehme Features bieten und Arbeit abnehmen. Die bekanntesten: LitElement und Stencil.

Lit und Stencil

LitElement ist Teil von Polymer (neu: Lit), einem Projekt von Google, und Stencil wird betreut von den Leuten hinter Ionic. Beides Libraries von zwei renommierten Unternehmen.

Die beiden Konkurrenten fühlen sich, schlägt man den TypeScript-Weg ein, ein bisschen an, wie Angular, vor allem aufgrund der Annotationen. Für LitElement naheliegend, stammt die Library doch aus demselben Hause. Sie abstrahieren vieles, wie etwa Event Handling und Reaktivität, was die Code Base um Einiges lesbarer und kompakter macht.Benutzerdefinierte Elemente, wie sie MDN auf Deutsch nennt, zu schreiben wird mit diesen beiden Packages bequemer. Wer sich ein TypeScript-und-Framework-Tandem gewohnt ist, wird absolut keine Probleme haben, sich zurecht zu finden. Für mich sehr erfreulich: CSS-in-JS kann sehr einfach umgangen werden – zumindest in Stencil. Und wer Lust auf PostCSS, Less oder eben Sass hat, kann seinen gewünschten Präprozessor einfach via Plugin nachinstallieren – zumindest in Stencil.Bezogen auf die «Developer Experience», ein weiteres neues Buzzword, hat Stencil absolut das Näschen vorn. Anständig prima ist auch, dass beide Packages auf unserem Bijou, dem Internet Explorer, laufen. Technisch gesehen gibt es also nichts auszusetzen.Ausserdem bringen Web Components doch auch einige Vorteile mit sich. Der grösste davon: Es ist spielend einfach, ein Custom Element in ein bereits bestehendes Projekt einzupflegen. Und dabei spielt es auch fast keine Rolle, welches Framework im Einsatz ist. Sie können als npm-Paket publiziert und dann von überall her bezogen werden. Das fördert die Kollaboration zwischen Framework-Experten. Ziemlich cool!Wer also Custom Elements bauen will, sich aber nicht mit den Drawbacks der nativen API herumschlagen möchte, findet hier zwei exzellente Lösungen.

Was ist mit Svelte?

Svelte, welches ich anfangs kurz erwähnt habe, ist die frischeste Spezies im Framework-Dschungel von JavaScript-Land. Das Mastermind dahinter ist Rich Harris. Svelte, anders als LitElement und Stencil, ist ein Compiler. Standardmässig spuckt es nicht Web Components aus – man kann es jedoch umkonfigurieren –, sondern normale HTML-Elemente mit dazugehörigen JavaScript- und CSS-Dateien.Dadurch ist die resultierende Bundle Size klein. Angelo Zehr, ein Entwickler vom SRF, spricht von nur 23kB für drei Komponenten. Und auch der Source Code einer Svelte-Komponente ist kompakt. Die Hauptphilosophie, die verfolgt wird: Write less code.Einen Haken hat die Sache allerdings doch: Svelte-Code läuft nicht auf dem Internet Explorer. Die generierten Bundles sind nämlich ES6/7/8-Module, mit denen Microsofts Urgestein nichts anfangen kann. In der Regel ist das jedoch verschmerzbar. Denn seit nun schon einigen Jahren ist es Standard, irgendwo und irgendwie einen Transpiler wie Bublé oder Babel einzusetzen.Mit Bublé können Svelte-Bundles, die der IE versteht, von nur 24kb hergestellt werden. Mit Babel, das allerlei Konfigurationsmöglichkeiten und Polyfills bereitstellt, was für grosse Projekte Sinn machen kann, wächst das Bundle auf mindestens 60kB heran. Eher gross, aber noch immer weitaus kleiner als alle Anderen. Pretty sweet stuff!

Neue Technologien bei Unic

Bei Unic halten wir ständig die Ohren offen, was neue Technologien angeht. Werden wir auf etwas Interessantes aufmerksam, so testen wirs so bald wie möglich auf Herz und Nieren. Sind sie reif genug und gefallen uns, setzen wir sie sehr gerne auch in Kundenprojekten ein. Das macht nicht nur uns Spass, sondern auch unseren Partnern. Genau so geschehen mit Stencil, welches wir für die SBB im Einsatz haben werden.