Romke van der Meulen

Toen het voor ons tijd werd om het design van ons oude klantenportaal bij te werken, ging onze Romke van der Meulen op zoek naar een goed JavaScript framework. In dit artikel deelt hij zijn ervaringen en conclusie.

Het tijdperk van het JavaScript framework

De laatste jaren hebben we te maken met een nieuwe trend: UI-code verplaatst zich van de server naar de client. JavaScript wordt volwassen, de browser is het nieuwe OS, en de grote browserbouwers hebben eindelijk geleerd hun meningsverschillen op een volwassen manier op te lossen. Nou ja, meestal. Uiteindelijk. Na enige tijd.

Dus toen het tijd werd om het design van ons oude klantenportaal eens bij te werken, besloten we een paar van de meer interactieve UI-componenten te verplaatsen van onze webservers naar de client. En omdat we de taak serieus namen besloten we dat we geen zin hadden in een lange stroom jQuery-plugins en eigengebakken klik-handlers. Dit was tenslotte het jaar van de JavaScript frameworks. Het was tijd om onderhoudbare, testbare, enterprise-level JS-componenten te bouwen.

De zoektocht begint

Goed, een JavaScript framework dus. Maar welke? Aan mij de taak om te kijken wat onze opties waren en welk framework het best aan onze eisen voldeed. En er waren zeker genoeg mogelijkheden. Het lijkt erop dat Jan en alleman JS frameworks aan het schrijven zijn. Sommige zijn zelfs van bekende merken als Facebook en Google. Tijd dus om eens goed rond te kijken en het een en ander uit te proberen.

Eerst stelde ik een lijst kandidaten op. Daarna begon ik een kleine proof-of-concept te bouwen voor elk framework. Ik bouwde een klein deel van het huidige klantenportaal na met de ideeën en syntax van het framework. Na een paar weken keek ik kritisch naar alle code die ik had geschreven, en wat mijn ervaringen waren bij het schrijven van die code.

Dit is wat ik ervan heb geleerd.

AngularJS: waar het allemaal mee begon

Het bekendste JavaScript framework is Google’s AngularJS. We hadden eerder al Angular gebruikt bij het bouwen van ons bestelproces. Onze ervaringen hiermee waren wat gemengd. Aan de ene kant maakte Angular de beloftes van een goed applicatie-framework wel waar. We waren in staat een meerstaps bestelproces te bouwen zonder ons (vaak) bezig te hoeven houden met de details van alle nodige DOM-manipulatie.

Conventies en performanceproblemen

Angular is echter wel een beetje… euh… apart als het aankomt op hun code-conventies, en hun interpretatie van het Model-View-Controller patroon. Er ging wat tijd overheen voor we hadden uitgevogeld welk stukje code nou waar moest komen te staan, en dat is verre van ideaal wanneer je met een paar mensen tegelijk een applicatie aan het ontwikkelen bent. Bovendien heeft Angular nog wel eens last van performanceproblemen. We moesten aardig sleutelen om ervoor te zorgen dat de applicatie redelijk snel startte na het laden van de pagina.

Angular 2: nieuw en verbeterd

Een groot team is al langere tijd bezig met het ontwikkelen van Angular 2. Let niet op de naam: dit is een compleet nieuw framework met nieuwe syntax en nieuwe ideeën. De eerste beta kwam net uit toen ik op zoek ging naar kandidaten. (Inmiddels is de eerste release van het framework gepubliceerd.) Er was sprake van volledige pre-gecompileerde templates, ondersteuning voor isomorphic apps, native apps voor mobiele apparaten – noem maar op. Angular 2 deed zijn best om eindelijk de droom van softwareontwikkelaars waar te maken: dat je code zonder aanpassingen werkt in elke situatie. Angular 2 was dan ook het eerste framework dat ik uitprobeerde.

React: goede performance en simpel te debuggen

En toen was er, voor maar 43KB (minified), van Facebook: React. React is alleen een view-laag, niet een compleet applicatie-framework. Dus voor bijv. validatie en communicatie met je server moet je er andere libraries bij betrekken. React richt zich op goede performance en is simpel te debuggen. Toen het uitkwam ging het de oude Angular en andere frameworks snel voorbij in benchmarks. Dat gat is inmiddels wel een stuk kleiner maar React is nog steeds een van de snelste JS frameworks.

De nieuwe ideeën van React

React kwam ook met een boel nieuwe ideeën, waarvan sommige inmiddels door veel andere frameworks overgenomen zijn. Zo kwam React met het “reactive” patroon op de proppen. Dit houdt in dat React views niet meer zijn dan een pure mapping van je applicatiestaat naar HTML. Elke gebruikersinteractie, elke response van je server, elk event moet de applicatiestaat op duidelijke wijze aanpassen. Daarna rekent React de nieuwe staat door naar een speciale representatie, de Virtual DOM. Op basis van de vorige Virtual DOM wordt dan de minimale set aanpassingen bepaald en daadwerkelijk op de browser DOM doorgevoerd.

Aurelia: stille onbekende kracht

En dan is er ook nog het meest populaire JavaScript framework waar je waarschijnlijk nog nooit van gehoord hebt: Aurelia. Het is ontworpen door Rob Eisenberg, een ervaren framework-ontwikkelaar die een tijdje bij het Angular 2 team gewerkt heeft voor hij de groep verliet. Het is gebouwd op basis van de allernieuwste JavaScript standaarden, sommige zelfs zo nieuw dat ze nog niet helemaal afgerond zijn. Maar het geheel wordt netjes omgezet naar ES5 JavaScript code zo simpel dat zelfs Oma’s IE9 ermee kan omgaan.

Hoofdproducten, dus goeie support

Aurelia en Ember zijn ook bijzonder omdat ze de hoofdproducten zijn van hun bijbehorende bedrijven. Angular en React daarentegen worden niet officieel aanbevolen door Google of Facebook. Dit betekent dat je er redelijk vanuit kan gaan dat de ontwikkelaars van deze frameworks niet zo maar wijzigingen zullen doorvoeren waar je bestaande code stuk door gaat, en dat je applicatie over een aantal jaar nog steeds wordt ondersteund.

Ember: niet geschikt voor onze situatie

Ik heb ook een korte poging gedaan een proof-of-concept te maken met Ember, maar het bleek nogal ingewikkeld om losse UI-componenten te ontwikkelen met dit framework. Ember heeft een boel regels over hoe je code ingedeeld moet worden, en die gaan er min of meer vanuit dat je hele applicatie met Ember gebouwd wordt. Dat gaat voor ons niet werken, aangezien we nog met een heleboel legacy-code zitten waar we voorlopig niet omheen kunnen. Bovendien was ik tegen deze tijd al een paar weken bezig, en de conclusie was al aardig duidelijk.

En de winnaar is…

Aurelia, met grote voorsprong. Goed, het is dan misschien nog vrij nieuw en het heeft niet zo’n grote community als de meer bekende frameworks (maar de ontwikkelaars geven snel en duidelijk antwoord als je vragen hebt). Er is echter een ding dat Aurelia je geeft wat ik bij geen ander framework kon vinden: code voor Aurelia kun je grotendeels schrijven in pure JavaScript en simpele HTML. Nou ja… TypeScript en zelfbedachte HTML tags, maar je snapt wat ik bedoel.

Toen ik met Angular 2 aan het ontwikkelen was, moest ik duidelijk code schrijven die alleen met Angular 2 werkte (de template-taal voor Angular 2 is strikt gesproken niet eens HTML volgens de standaard). React heeft zelfs een compleet eigen template-taal bedacht: JSX. En die wordt nog niet door mijn editor ondersteund, en die ondersteuning komt er ook binnenkort niet aan.

Kijk daarentegen hier eens naar:

export class MijnComponent {

    aantalKliks = 0;

    verwerkKlik(e) {
        console.log('je klikte op: ' + e.target);
        console.log('aantal kliks: ' + ++this.aantalKliks);
    }
}

en de bijbehorende template:

<template>
    <a click.trigger="verwerkKlik($event)">
        Dit is een component.
    </a>
</template>

Als je mij had gevraagd hoe de ideale code voor een UI-component voor het web er uit zou moeten zien, dan had ik waarschijnlijk iets geschreven dat hier sterk op leek. Je hoeft alleen maar de template in mijn-component.html te zetten en de code in mijn-component.js en Aurelia regelt de rest. Geen configuratie of verdere code vereist. Nu kan ik waar ik maar wil <mijn-component></mijn-component> zetten, en Aurelia plaats mijn component daar.

Prachtige code

Dit is onderhoudbare code. Ik herken het direct. Als Aurelia morgen wordt opgedoekt (zeer onwaarschijnlijk), dan kan ik alle code die ik heb geschreven met weinig moeite overhevelen naar een ander framework. Misschien moet ik hier en daar een decorator aanpassen, of een aanroep van een framework API. Maar de UI- en business-logica schrijf ik uit in normale code die met elk fatsoenlijk framework hoort te werken.

Het is zelfs meer dan dat: het is elegant. De code die ik heb geschreven nu we besloten hebben voor Aurelia te gaan leest als Mulisch, ware het niet dat Mulisch moeilijker te begrijpen is dan de code die ik de laatste weken naar onze repository gestuurd heb.

Mijn advies

Aurelia is zeker niet perfect. Vooral de documentatie is nog enorm schaars. Maar dat wil ik wel vergeven, vooral aangezien het framework nog maar net gereleased is. Bovendien: als ik ergens niet uitkwam kon ik een vraag stellen op StackOverflow, of een issue openen op Github, en dan kreeg ik altijd netjes antwoord. En ik heb in de laatste maand meer geleerd over nieuwe en komende JavaScript features dan in de laatste paar jaar (hoera voor async functions!).

Dus mijn advies, gebaseerd op mijn ervaringen, is om de bekendere frameworks te negeren en je te richten op het framework dat jou vooral niet in de weg zit en je lekker je eigen ding laat doen. Probeer het maar eens uit en laat me weten wat jij er van vindt. Ik ben benieuwd naar jouw ervaringen.

Romke van der Meulen Code-goochelaar

“Ik ben developer bij Vevida. Elke dag leer ik nieuwe dingen over het ontwikkelen van webapps, en ik houd ervan die kennis weer te delen met anderen.”