“The Sound of Music” predikt misschien: “Laten we bij het allereerste begin beginnen, een heel goede plek om te beginnen.” Maar bijna elke ontwikkelaar weet dat dit een dwaas plan is. De juiste plaats om te beginnen is met een stevige fundering, gebouwd door een geweldig team van open source ontwikkelaars. Kloon hun harde werk en voeg dan net genoeg code toe om het je eigen te maken. Het is niet nodig om te herhalen wat iedereen al eerder heeft gedaan.
Het is een gemakkelijk plan-als je er eenmaal voor kiest. Helaas kan het kiezen van die basis bijna net zo moeilijk zijn als helemaal bij het begin beginnen. De wereld van webframeworks is een zeer actief ontwikkelingsgebied en er kunnen tientallen goede open source-projecten zijn die een geweldige start voor uw project zouden zijn.
Om het nog erger te maken, zijn de verschillende teams die deze verschillende projecten hebben gemaakt, een ander pad ingeslagen omdat ze ernstige filosofische verschillen hadden met de andere opties. Ze keken naar de andere frameworks en besloten dat ze het beter konden. Met andere woorden, ze deden het voor een reden en je kunt het wel of niet eens zijn met hun beslissing.
De onderstaande lijst met goede plaatsen om te beginnen laat opzettelijk de marktleiders React, Angular en Vue weg, gewoon om dingen een beetje eenvoudiger te maken. Dat betekent niet dat de grote drie slecht zijn. Ze kunnen nog steeds de juiste oplossing voor je zijn. Het is alleen dat er voortdurend over ze wordt gepraat en die discussies laten een aantal vrij goede andere opties links liggen.
Er zijn genoeg goede redenen om de populairste te kiezen. Veel mensen in jouw schoenen keken rond en velen van hen kozen niet voor niets voor React, Angular of Vue. Maar dat was toen. In de tussentijd hebben sommige slimme mensen nieuwere frameworks gemaakt die sneller, eenvoudiger, sterker, of een van een grote reeks superlatieven zijn.
In de meeste van de onderstaande gevallen hebben de teams iets intrigerends en krachtigs gecreëerd door de aard van het framework opnieuw te bedenken. Dat is een mooie manier om te zeggen dat ze uiteindelijk een functie hebben verwijderd, waardoor het framework efficiënter is geworden en dus minder geheugen nodig heeft, de opstarttijd is versneld, of in het algemeen het framework behendiger is geworden. Of in een paar gevallen hebben ze nieuwe ideeën toegevoegd die in de toekomst standaard kunnen worden.
Als je de tijd hebt om te investeren, hier is een lijst van enkele van de andere interessante keuzes. Ze zijn niet noodzakelijk geschikt voor sommige mensen en ze zijn zeker niet de beste keuze voor iedereen, maar ze kunnen een betere keuze voor u zijn. Uw taak, als u die wilt aanvaarden, is om een solide beschrijving te maken van uw webapplicatie, een relatief solide beschrijving op te schrijven van de verschillende use cases, en dan deze tools te evalueren met dit in gedachten.
Misschien houdt u van een bepaalde benadering van het ontwerpen van code. Misschien heeft uw app geen behoefte aan een aantal van de functies in de dikkere, meer populaire frameworks. Er zijn tientallen redenen om te investeren in een van deze andere paden. Je zou zomaar kunnen ontdekken dat een van hen wonderen doet voor je applicatie.
Petit DOM
Als je houdt van het idee van een virtuele DOM, maar je wilt niet alle beperkingen die komen met het overnemen van de mentaliteit van de mensen bij React, Vue, of je andere grote naam framework, dan is de Petit DOM de manier om te gaan. Je krijgt een kleine hoeveelheid code waarmee je een virtuele verzameling tags kunt manipuleren en deze vervolgens kunt migreren naar het echte DOM. Al de rest over de structuur van de componenten en de rendering is aan jou. Als uw componenten eenvoudig zijn, of als u een super-complexe rendering hiërarchie gaat maken die alleen van u zal zijn, kan dit uw basis zijn omdat alles wat het biedt een gereedschap is voor het virtualiseren van het DOM.
Surplus
Het virtuele DOM is misschien niet voor iedereen weggelegd. Het neemt ruimte in beslag, dus als je manipulaties niet te complex zijn, kun je net zo goed je instructies rechtstreeks naar het officiële DOM leiden. De Surplus bibliotheek doet precies dat. Het neemt ieders favoriete markup JSX en compileert het in code die het echte DOM zal manipuleren. Zoals ze zeggen in de advertentie business, het snijdt de tussenpersoon eruit. Geen verschillen. Geen geheime extra laag. Gewoon pure manipulatie van de echte DOM. Als uw code eenvoudig en direct genoeg is om slechts een paar dingen met het DOM te doen, waarom zou u zich dan druk maken over de virtuele afleiding?
RE:DOM
Een andere optie voor degenen die geen geheugen willen investeren in een virtuele Dom is een piepkleine bibliotheek (2KB) genaamd RE:DOM. RE:DOM bevat enkele basisroutines waarmee je al je tags en componenten kunt maken met een paar eenvoudige JavaScript-aanroepen. De syntaxis lijkt veel meer op die van CSS, dus je kunt vrij uitgebreide tags met ID’s en klassen specificeren met slechts een paar toetsaanslagen. Je “kleiner dan” (<) en “groter dan” (>) toetsen zullen je dankbaar zijn.
Mithril
Niet alle alternatieven zijn klein en minimalistisch. Mithril zou je in deze context een “midsized” framework kunnen noemen, hoewel het maar 8KB weegt. Al deze code bouwt een virtueel DOM met een efficiënt update mechanisme zoals de anderen, maar het komt ook met een gestandaardiseerde set van tools om met veel van de standaard uitdagingen om te gaan zoals routing en XMLHttpRequest calls. De ontwerpers van het project willen dat Mithril projecten relatief gestandaardiseerd zijn, en ze vinden dat het toevoegen van deze code aan de hoofdbibliotheek de standaardisatie verhoogt. Als dat nog niet genoeg is, pushen ze ook wat standaard opmaak en idiomatische structuren.
Bobril
Als je van de virtuele DOM en stateful componenten van React houdt en graag in TypeScript programmeert, dan is Bobril of zijn Angular-vriendelijke neefje ngBobril misschien precies het ticket. Het framework is consequent veel sneller dan React of Angular in sommige benchmarks, misschien vanwege de snellere diff-algoritmes en het gebrek aan ondersteuning voor isomorfe JavaScript. Er zijn ook steno functies voor CSS manipulatie en een complete state management laag, BobX, als je het nodig hebt.
Marko
Als je enige tijd hebt doorgebracht met het bieden op Pez dispensers of andere verzamelobjecten, heb je de kracht van Marko ervaren, een slank, snel framework dat eBay deelt via een open source licentie. Het mooiste is misschien wel de zeer lichte templating syntaxis die op slimme wijze het meeste overtollige vet uit HTML verwijdert zodat de structuur wordt bepaald door inspringingen en niet veel anders. En de rendering engine is zeer snel, in staat om uitgebreide constellaties van dansende DIV’s aan te sturen die sneller dan 60fps updaten.
Svelte
Jouw standaard web framework komt met een compiler en een gedownloade library die runtime afhandelt wat de compiler produceert. Het twee-stappen-proces maakt zeer uitgebreide code mogelijk tegen de prijs van het wachten op de runtime-bibliotheek die elke keer dat de pagina wordt geopend moet worden gedownload en geparseerd. De Svelte compiler maakt komaf met deze complexiteit door bijna pure JavaScript uit te spugen dat bijna klaar is om zelfstandig te draaien, zij het alleen in sommige van de nieuwere browsers (bv. Chrome, Firefox, Opera, en IE10). Het is een slim architectonisch gambiet dat zeer lichtgewicht websites produceert die weinig geheugen innemen.
Inferno
Inferno is een ander framework dat is gemaakt om veel te doen van wat React doet, maar met een kleinere download en een snellere runtime. Het bereikt veel van dit door het uitgebreide synthetische event mechanisme weg te gooien en zich alleen te concentreren op de meest essentiële zoals onClick. Veel andere delen van de API zijn vergelijkbaar, zo niet hetzelfde, waardoor het relatief eenvoudig is om je code over te zetten als het de event optimalisatie laag niet nodig heeft.
Preact
Een van de kleinste van de React afstammelingen is Preact, een eerbetoon dat de meeste van de meest waardevolle functies biedt, zoals een virtuele DOM en verfijnde componenten, maar de synthetische event handlers en een deel van de props overerving wegstript. Terwijl Inferno alleen de belangrijkste events zoals onClick probeert te implementeren, doet Preact niet de moeite om iets met de events te doen, zodat je kunt vertrouwen op de browser’s eigen addEventListener. Door functies weg te laten die niet veel toevoegen (naar hun mening), maken ze hun download nog kleiner. Dit is een beetje een afweging omdat de benchmarks laten zien dat Preact een beetje langzamer is dan Inferno. Natuurlijk, uw toepassing kan anders zijn en uw kilometers kunnen variëren. Als je echt pure compatibiliteit met React nodig hebt, is er zelfs een library (preact-compat) die de meeste problemen tijdens het bouwen verhelpt.
Hapi
Vele frameworks komen aan in een enkele brok. Hapi is meer een verzameling plug-ins, een constellatie van tientallen stukjes code die je naar eigen inzicht in je stack kunt mixen. Authenticatie, autorisatie en logging zijn klusjes die met een willekeurig aantal opties kunnen worden opgelost. Als je een microservices-architectuur vol API’s bouwt, genereert de gestandaardiseerde Swagger-plug-in automatisch de Swagger-documentatie uit je basiscode.
Koa
Soms heb je een vrij complexe verzameling routines nodig die jongleren met inkomende verzoeken en ze vertalen in meerdere wijzigingen, waarvan sommige uitgebreid. Koa is ontworpen om het organiseren van al dit werk een beetje eenvoudiger te maken. Het geheim ervan is dat het de callback functies die normaal JavaScript domineren verandert in een set van asynchrone functies die afgaan wanneer de tijd rijp is. De geneste spaghetti callback stacks worden omgezet in iets schoners.
Nest
Een andere optie voor het temmen van de complexiteit van de server komt van het Nest team, die een architectuur bieden gevuld met controllers, pipes, en providers met wat guards, interceptors, en exception filters erbij gegooid om orde te houden. Het framework is modern en klaar om GraphQL en microservice verzoeken direct vanaf het begin af te handelen.
Drupal, WordPress, en Rails
Frameworks die zijn gebouwd in JavaScript en die draaien op de top van Node.js vullen het psychologische centrum van de webontwikkelingswereld deze dagen. Maar het kan een vergissing zijn om de vorige generatie, gebouwd op PHP, te negeren, een basis die sneller is dan ooit nu het ook een just-in-time compiler heeft zoals JavaScript. En Ruby en zijn Rails framework blijven dienen als de hoekstenen van rotsvaste websites.
De laatste generatie is gehavend door de strijd en goed getest door meer dan een decennium van continue ontwikkeling en werk. Er zijn geavanceerde ontwerpers die thema’s en skins voor de apps kunnen maken. Er is een goede kans dat iemand de modules al heeft gebouwd met de functionaliteit die u nodig heeft. Dus voordat je een slim Node.js-framework onderzoekt, overweeg dan of een van de oudjes al veel, zo niet alles kan doen van wat je nodig hebt.
Vanilla JS
Je zou het kunnen zien als een gemene opgraving of misschien een satire op het niveau van “De nieuwe kleren van de keizer”, maar het is moeilijk om te argumenteren met het succes ervan. Vanilla JS is een website die opschept dat zijn framework op meer websites wordt gebruikt dan “jQuery, Prototype JS, MooTools, YUI, en Google Web Toolkit-gezamenlijk”. Dit kan al dan niet waar zijn gezien de proliferatie van jQuery, maar laten we lachen om de brandwond. De site komt ook met een schattige kleine selector waarmee je een aangepast archief van verschillende componenten kunt bundelen, zoals Math, DOM, closures, of reguliere expressies. Wat je ook kiest, het resultaat is een verbijsterende nul bytes lang. Probeer die maar eens te verslaan!
Het punt van de grap is dat het soms zinvol is om gewoon een paar van de standaard elementen in JavaScript te gebruiken en de extra’s over te slaan. Bibliotheken en frameworks als jQuery of React zijn deels begonnen vanwege de gekmakende verschillen tussen de browsers. Veel van die verschillen zijn verdwenen dankzij standaardisatie.
Natuurlijk gaan de Vanilla JS voorstanders niet de confrontatie aan met het feit dat shorthand functies zoals $() niet alleen handig zijn, ze besparen ook ruimte in onze eigen code. Maar als je de document.getElementById slechts af en toe gaat gebruiken, maakt het misschien niet uit. Als u slechts een paar functies aan uw webpagina toevoegt en die functies doen een paar basisdingen, dan is plain vanilla JavaScript misschien het snelste framework voor u.