Web Components 101 – Part 6: The Next Level

Je weet nu wat over de principes, de techniek, de libraries, het ecosysteem en hoe je het groter aan kan pakken. Maar waar begin je? De kans is groot dat je al een bestaande frontend applicatie hebt. Of dat je de potentie van web components wel inziet voor bepaalde onderdelen van de applicatie, maar niet alles. Daarom ga ik je deze week laten zien hoe je kan beginnen met web components. En hoe je ze laat samenwerken met een Vue, React of Angular applicatie. En wat de volgende stappen zijn om naar een toekomstbestendige frontend te reizen.

But first…

Is het überhaupt wel een goed idee om web components te gebruiken? Je kan wel raden wat ík zelf vind. Maar ook dat ligt meer genuanceerd dan je zou denken. Het hangt namelijk volledig af van de organisatie en haar wensen.

Ik geloof (natuurlijk) volledig in de kracht en potentie van web components. De toekomstbestendigheid van framework-onafhankelijk werken is heel veel waard voor mij. Maar boven dat alles geloof ik ook sterk in de Developer Experience van een codebase. En wanneer je voor web components kiest, dan zal je daar hard voor moeten werken. Er is geen mega ecosysteem voor kant-en-klare eslint plugins die naadloos aansluiten met een Lit component. En ik heb een hekel aan je eigen build systeem onderhouden. Webpack configuraties kunnen zo complex worden dat je een bachelor in zwarte magie nodig hebt om ze te begrijpen. En dat zijn dus wél allemaal dingen die je zelf in handen moet nemen wanneer je met web components gaat werken.

Vergelijk dat met de Angular CLI: een enorm krachtige tool die écht veel moeite uit handen neemt. Het genereren van nieuwe routes, modules en features kan met een enkel commando, en ze worden dan meteen met behulp van schematics op de goede plek in de codebase gezet. Ook is de build configuratie totaal verborgen voor je en hoef je er niet over na te denken tenzij je hele specifieke wensen hebt. Dat allemaal scheelt enorm in de cognitive complexity van de applicatie. Minder bewegende delen is minder complexiteit. Dit is echter alleen waar op de oppervlakte: binnen je eigen codebase. Want vergeet niet dat er honderdduizenden tot miljoenen regels code onder de motorkap van Angular liggen om dit allemaal zo vlekkeloos te integreren.

Het is dus nogal een keuze. Ga je voor gemak en ecosysteem, of voor onafhankelijkheid en toekomstbestendigheid? Er is geen goed antwoord. Afhankelijk van de organisatie, het project en de development team(s) zou mijn eigen keuze verschillen tussen een framework of web components. Hopelijk weet jij daar ook je eigen mening in te formuleren. Maar mocht je wel kiezen voor web components, dan heb ik in deze blogpost een paar opties beschreven van hoe je ze kan gebruiken binnen jouw frontend.

Ik gebruik <framework>. Werken web components wel samen hiermee?

Ja! Web components kan je integreren met virtueel elk framework wat er is. Van de grote spelers als React, Vue en Angular tot aan de minder bekende frameworks als Svelte, Mithril en Preact.

Hoe die integratie werkt kan je bekijken op de site van het Custom Elements Everywhere project. Daar kan je per framework zien hoe volwassen de integratie is, en in de Github repository zie je per framework zo’n dertig tests per framework waar je het in de praktijk kan zien. Op dit moment heeft alleen React heeft nog een paar problemen met de integratie tussen het framework en web components, maar daar wordt op dit moment aan gewerkt.

Wat goed is om in gedachten te houden is dat er veelal geen officiële ondersteuning is vanuit de frameworks voor het integreren van web components. Hoewel alles werkt en eventuele bugs ook wel gefixt worden vanuit de framework developers, zal je weinig documentatie en artikelen vinden over deze integratie. Doe daarom van tevoren een set aan experimenten om te kijken op wat voor manier web components integreren met jouw framework.

Frontend met een migratieachtergrond

Er zijn meerdere manieren om web components te introduceren in een frontend. Als je een kleine applicatie hebt is het misschien wel het makkelijkst om hem volledig te herbouwen met web components. Dat noemen we een Big Bang migratie. Het geeft je de kans om direct een mooie architectuur op te zetten en een hoge DX te behalen. Maar in de praktijk is dat vrijwel altijd makkelijker gezegd dan gedaan, en kan het maanden tot jaren duren zelfs voor een ervaren development team.

Daarom heb ik nog twee andere migratiepaden uitgeschreven die uitermate geschikt zijn voor het introduceren van web components: de Bottom-Up & Web Component Core strategieën.

Bottom-Up

Wanneer je uiteindelijke doel is om 100% op web components te draaien, dan raad ik je aan om Bottom-Up te werken. Het is namelijk makkelijker om framework-elementen afhankelijk te maken van web components dan andersom.

De aanvliegroute is vrij simpel: onderzoek wat de verschillende lagen zijn in de frontend applicatie, en hoe het gemigreerde alternatief er uit zal zien voor elke laag. Je begint onderaan met het migreren van de componenten. Denk hierbij aan je basiselementen of design system: de knoppen, input-velden en generieke styling. Dit zijn vrijwel altijd componenten zonder afhankelijkheden omdat ze zo simplistisch zijn, en zijn daarom perfect om als eerste te migreren. Ze leren je hoe je werkt met web components, en geven je inzicht in hoe het is om er mee te werken.

Daarna kan je beginnen met alles wat er boven ligt. Denk hierbij aan verschillende modules met features, routes en ook je state management oplossing. Als je een framework-specifieke oplossing gebruikt zal je dit moeten lostrekken en een “vanilla” alternatief moeten vinden. Als je al iets gebruikt als redux dan is het makkelijk: daar hoef je niets aan te wijzigen om samen te laten werken met web components.

Het nadeel van deze migratiestrategie is dat je niet zal eindigen met een walhalla qua codebase. Omdat je bestaande codebase in kleine stukjes migreert zal het eindresultaat ook sterk lijken op de bestaande codebase, maar dan gebouwd met web components. Je hebt dus niet het verse greenfield gevoel, en na de migratie zal je zeker nog wel veel tijd moeten investeren in het opschonen en refactoren om je doelarchitectuur te bereiken.

Het is ook een hele uitdaging voor de developers. Een nieuwe applicatie bouwen met web components is eén ding, maar een bestaande applicatie in kleine delen migreren en vloeiend samen laten werken met een bestaande applicatie…. Dat is een complex traject. Je bent continu aan het jongleren met het migreren van oude code, en het maken van nieuwe functionaliteit op de oude óf nieuwe manier.

Toch is dit een strategie die het overwegen waard is, afhankelijk van de context van het project. Zo heb je zero downtime, en wordt er niet een hele nieuwe applicatie gebouwd. Dit verkoop je makkelijker aan je business-collega’s, en kan je ook op je eigen tempo doen. In mijn ervaring zijn migraties als deze goed te doen wanneer je er een percentage van je tijd voor reserveert. Spreek bijvoorbeeld af om er twintig procent van je tijd aan te spenderen, en dat de rest van de tijd is voor het door ontwikkelen van de applicatie. Zo komt de innovatie niet stil te liggen, maar heb je na een tijd tóch een applicatie gebouwd met web components.

Als je dit gaat doen, dan heb ik een aanrader voor je! Deze migratiestrategie is heerlijk voor de vrijdagen. Maak een lijst van alle onderdelen die gemigreerd moeten worden en ga met je team op een leuke locatie zitten met hapjes, drankjes en muziek. Developers pakken componenten op uit de lijst, en omdat je met het team dicht bij elkaar zit ontstaan discussies ook organisch. Zo kan je meteen exotische situaties bekijken met het hele team, en afspraken maken over hoe bepaalde dingen gebouwd moeten worden in de toekomst. Daarnaast is het ook gewoon heel gezellig en zorgt het afstrepen van de to-do lijst ook voor een gevoel van progressie.

Web Component Core

De Bottom-Up migratiestrategie is een hele goede, maar waarschijnlijk niet geschikt voor grote organisaties met tientallen tot honderden frontend applicaties. Daar zal je namelijk altijd hebben dat bepaalde applicaties eigenlijk niet meer door ontwikkeld moeten worden. Of dat teams sterk gehecht zijn aan hun eigen framework keuze, waardoor je risico loopt om mensen te verjagen uit de organisatie.

In zo’n organisatie is de autonomie van teams veel waard, en zal je nooit alle applicaties kunnen migreren naar een codebase 100% gebouwd met web components. Daarom kan je een Web Component Core opzetten: een design system, component library en application core, allemaal gebouwd op basis van web standaarden.

Het doel is om de core van een applicatie op te zetten met web components, zodat elke frontend applicatie deze generieke kern kan implementeren. Deze core bevat het design system, waar alle basiselementen zijn gebouwd met de huisstijl van de organisatie. De component library bevat samengestelde componenten die overal terugkomen, denk bijvoorbeeld aan de header, footer en andere standaard features zoals een feedback formulier. Deze samengestelde componenten kunnen dan makkelijk in elke applicatie worden ingeladen.

Tot slot heb je de application core: deze bevat generieke functionaliteit die voor elke applicatie toepasbaar is. Denk aan standaard mechanismes voor authenticatie, autorisatie, tracking en logging. Wanneer deze mechanismes zijn gebouwd met ES Modules, kan je ze in elke applicatie inladen in gebruiken. Het is belangrijk dat deze application core zo generiek mogelijk is, en geen gebruik maakt van opinionated libraries. Gebruik dus geen RxJS voor interactie met de core library als je weet dat maar de helft van alle frontends ook dit patroon volgt. Om zoveel mogelijk applicaties aan boord te krijgen met de application core, moet deze zo dicht mogelijk op JavaScript standaarden blijven. Dus gewoon ES Modules, Promises en verder niet te veel fancy stuff. Met de application core kan je gemakkelijk belangrijke wijzigingen omtrent authenticatie en API-interactie doorvoeren over het gehele applicatie landschap, waar je vroeger altijd elke individuele implementatie in elke frontend applicatie moest aanpassen.

Tot slot is het belangrijk om een “application starter kit” op te zetten voor nieuwe frontend applicaties. Dat is een template voor een nieuwe applicatie, die gebruik maakt van de Web Component Core libraries, en een basisarchitectuur neer zet. Daar in zijn een paar voorbeeld features gebouwd en worden standaardimplementaties van routing en state management vastgelegd. Zo kunnen developers voor nieuwe projecten makkelijker de starter kit downloaden en inzetten, waardoor op de (erg!) lange termijn er vanzelf een migratie plaatsvindt naar web components toe.

Het risico van deze migratie is dat je meer complexiteit introduceert zonder er iets voor terug te krijgen. Waar je voorheen misschien drie frameworks gebruikte, gebruik je nu drie frameworks én een web component core. Het is daarom ook belangrijk om een visie te hebben voor de toekomst: willen we nog steeds een vrije framework keuze aanbieden, of is het de bedoeling dat elke applicatie op de lange termijn wordt gebouwd met web components?

Waarschijnlijk is het antwoord het laatste. Dan is het belangrijk om veel kennis te delen binnen de organisatie. Zo zorg je er voor dat iedereen weet wat web components zijn, en hoe je er mee werkt. Én door te zorgen voor veel voorbeelden van hoe je bepaalde features bouwt met web components zorg je er voor dat de drempel van adoptie laag ligt, waardoor het de logische keuze wordt.

Mocht je nog steeds elk team de autonomie willen geven om een eigen framework te kiezen, dan is het nog steeds een goede keuze om een web component core te gebruiken. Zo garandeer je met het design system dat alle applicaties dezelfde UX/UI richtlijnen volgen. En blijven je core componenten nog vele jaren in gebruik, terwijl er in die tijd wel drie frameworks komen en gaan. Dat is het voordeel van de toekomstbestendigheid van web components.

Waar moet je nog meer rekening mee houden tijdens een migratie?

Dit waren natuurlijk hele oppervlakkige beschrijven van zo’n migratie. Ze duren maanden tot jaren, en hebben inspanning nodig van heel veel collega’s vanuit allerlei disciplines. Denk bijvoorbeeld aan de User Experience: je wil natuurlijk wel garanderen dat de gebruiker de applicatie op dezelfde manier blijft ervaren, ondanks dat de onderliggende techniek verandert. Of hoe je nou deze kans kan benutten om niet alleen de techniek te migreren, maar ook meteen kan meten of je eindgebruikers problemen of verbeteringen ervaren.

Samen met mijn collega Sytze heb ik ook een whitepaper geschreven over het migreren van AngularJS naar Angular applicaties. De details zullen verschillen, maar er staat veel meer toelichting in over hoe je kan omgaan met zo’n migratie. Ook staat er nog een handige migratiestrategie beschreven die je kan helpen als je wél een greenfield codebase wil, én hem vanaf dag een al kan releasen voor je eindgebruikers.

Nieuwsgierig? De whitepaper kan je hier downloaden. 

Klaar met migreren, en nu?

Het is aantrekkelijk om meteen door te willen met de volgende grote stip op de horizon, maar neem als team even een moment om te reflecteren op de migratie. Wat heeft iedereen geleerd? Wat vonden ze lastig? En wat missen ze aan het oude framework wat nu niet meer kan? Deze vragen geven je inzicht in wat je nog mist en waar je de Developer Experience mee kan verhogen.

Ook is dit het moment om vast te leggen hoe dit is gegaan. Want er zullen vast nog wel migraties plaatsvinden in de toekomst. Hopelijk niet naar een frontend framework toe, maar wellicht wel in een state management oplossing. Of een nieuwe web component library. Een write-up maken geeft je later een kans om terug te kijken op hoe de migratie is verlopen, en waar je veel van hebt geleerd. Zo weet je of je in de toekomst dezelfde approach moet gebruiken, of juist een andere koers moet varen. Als je helemaal de blits wil maken, overweeg dan om deze reflectie ook als blogpost live te zetten. Zo heeft iedereen er profijt van. Want er zijn zo veel bedrijven die interesse hebben in een switch naar web components, maar er is veel twijfel vanwege een gebrek aan resources online.

En als dat allemaal klaar is… Kan je je eindelijk focussen op shiny features voor je eindgebruikers, want je zal je nooit meer zorgen hoeven te maken om framework migraties en deprecations 😉

Endgame

Daar zijn we dan. Aan het einde van de zes blogposts over web components. Nu ben je klaar om uit het nest te vliegen en de magie te verspreiden. Ik hoop dat je veel leesplezier hebt gehad de afgelopen zes weken, en ook het nodige hebt geleerd. Voor mij was het in ieder geval een hele bevalling: ongeveer 20,000 woorden verspreid over tachtig A4’tjes.

Mijn ultieme doel is dat er meer bewustwording is over web components als valide keuze voor een frontend applicatie. Én dat meer mensen ze gaan gebruiken, kleinschalig of voor een heel project. Met de inzet van ons allemaal wordt het ecosysteem namelijk alleen maar mooier. Op de lange termijn hoop ik dat web components gezien worden als de basis van moderne frontend development. Geen frameworks meer tijdens je studie: web components zijn de basis, en de grote frameworks zijn het alternatief. Of mijn droom ook waar wordt gemaakt, dat kan ik voor nu alleen maar hopen. Maar ik ben enorm blij dat jij als lezer al zó ver bent gekomen.

Als je naar aanleiding van deze blogpost serie iets gaat doen (of hebt gedaan) met web components, dan vind ik het leuk als je me even een berichtje stuurt via LinkedIn, Twitter of e-mail. Ook als je nog vragen hebt, verdieping zoekt in bepaalde onderwerpen of gewoon eens een kopje koffie met me wil drinken mag je me altijd benaderen.

Smaakt dit naar meer? Arcady biedt nu ook een tweedaagse Web Component Workshop aan. Onder mijn begeleiding ga je twee dagen lang alles wat je hebt gelezen in de praktijk toepassen, én ga je nog veel verder de diepte in. Dan ben je direct klaar om ze in te zetten voor jouw project! Meer weten? Bekijk hier de Web Component Workshop.

Deel 1: Web Components 101

Deel 2: ​Web Components 101 - Libraries

Deel 3: Web Components 101 - Show me the code!

Deel 4: Web Components 101 - Tooling & Ecosystem 

Deel 5: Web Components 101 - Scaling up!

Deel 6: Web Components 101 - The Next Level