Door Tim Vermaelen, 19-12-2024
Met meer dan 20 jaar ervaring in webontwikkeling heb ik de evolutie van de sector van dichtbij meegemaakt. Ik herinner me nog de tijd waarin ik cross-browserproblemen moest oplossen met Internet Explorer (IE5.5, IE6, IE7), Opera en Safari. Destijds hoopte ik vurig dat deze problemen snel tot het verleden zouden behoren. Ik denk vaak terug aan het tijdperk waarin CSS-hacks een noodzakelijk kwaad waren: een wirwar van browser-specifieke oplossingen die onze codebases rommelig maakten en ons geduld zwaar op de proef stelden. Elke nieuwe browser-release maakte onze zorgvuldig opgebouwde code snel verouderd.
In 1995 ontwikkelde Brendan Eich JavaScript bij Netscape, een mijlpaal in webontwikkeling. Rond 2006 brak het tijdperk van JavaScript-bibliotheken aan, dat een oplossing beloofde voor de chaos van cross-browsercompatibiliteit. Bibliotheken zoals Prototype (2005, Sam Stephenson), jQuery (2006, John Resig) en Underscore (2009, Jeremy Ashkenas) zorgden voor een gestandaardiseerde aanpak van DOM-manipulatie en event-afhandeling. Het leek een gouden tijdperk van vooruitgang en innovatie.
Tijdens het tijdperk van mobiele optimalisatie, waarin HTML5 (geïntroduceerd in 2008, gestandaardiseerd in 2014) en CSS3 (uitgebracht in 1999, breed ondersteund rond 2012) de nieuwe normen werden, verschoof het gebruik van het web naar mobiele apparaten. In oktober 2016 overtrof mobiel webgebruik voor het eerst desktopgebruik (51,3% van de webpagina's werd op mobiele apparaten bezocht, volgens StatCounter). Responsief webdesign (voor het eerst geïntroduceerd door Ethan Marcotte in 2010) werd essentieel. Technieken zoals mediaqueries, flexibele grids en responsieve afbeeldingen werden gangbaar. Tegelijkertijd was het een uitdaging om klanten, gewend aan desktop-georiënteerde ontwerpen, van deze nieuwe aanpak te overtuigen.
En eerlijk gezegd ging het goed. Alles was logisch: we hadden een MVC-backend en een frontend met duidelijke scheiding van verantwoordelijkheden (Separation of Concerns, SoC). Maar in de strijd tegen IE8 en IE9, terwijl we IE10 en IE11 ondersteunden naast FireFox, Chrome, Opera en Safari, besloten veel ontwikkelaars zelf frameworks te bouwen. Hoewel deze frameworks bedoeld waren om orde te scheppen in de chaos, brachten ze vaak een nieuwe laag van complexiteit met zich mee. Laten we eens bekijken waarom dat zo is.
Sommige frameworks en bibliotheken, zoals Knockout en bepaalde toepassingen van AngularJS, maken gebruik van HTML-data-attributen om gegevens op te slaan en te manipuleren. Deze data-attributen worden vaak gebruikt voor bindings, state management en event handling. Het introduceren van logica in deze data-attributen roept echter aanzienlijke bezorgdheden op. De ontwikkelaarsgemeenschap stond op het punt de Separation of Concerns (SoC) volledig onder de knie te krijgen, toen frameworks begonnen te promoten dat twee-weg data binding een noodzakelijkheid was. Deze benadering kan de duidelijke grenzen tussen de verschillende lagen van een applicatie vervagen, waardoor de code moeilijker te onderhouden en te debuggen wordt. In plaats van de eenvoud en onderhoudbaarheid te verbeteren, maakt het gebruik van data-attributen voor logica de architectuur vaak complexer en ondermijnt het de principes van SoC. Is dit geen stap achteruit, die de schone architectuur die we net hadden bereikt, bemoeilijkt?
Bij elke update van een framework kwamen er breaking changes, waardoor ontwikkelaars voortdurend hun codebases moesten refactoren om up-to-date te blijven. De eenvoud waar we naar verlangden werd vervangen door een afhankelijkheid van externe bibliotheken, en de vrijheid om te innoveren werd overschaduwd door de beperkingen van frameworkconventies.
Beschouw de gebruikelijke aanpak van Separation of Concerns (SoC) als een verticale structuur. Je hebt je HTML, CSS en JavaScript in aparte mappen. Makkelijk te doorzoeken en te vinden!
In een Single Page Application (SPA) framework wordt SoC horizontaal toegepast. Je hebt je webcomponenten elk in een map, waar HTML, CSS en JavaScript door elkaar staan. Ook makkelijk te doorzoeken en te vinden! Maar wij ontwikkelden geen Single Page Applications. Houd deze gedachte vast, want dit komt later terug als een belangrijk punt.
Frameworks, hoewel krachtig, botsen vaak met de complexiteit van de integratie van Content Management Systemen (CMS). Platforms zoals Sitecore, Kentico en Umbraco hebben hun eigen ecosystemen, die zorgvuldig zijn afgestemd op het werken met standaard webtechnologieën. Het introduceren van een framework in dit ecosysteem kan de delicate balans verstoren, wat leidt tot compatibiliteitsproblemen en weergaveverschillen.
Stel je voor dat je enorm veel tijd en budget hebt geïnvesteerd in de nieuwste, coolste functionaliteiten met de nieuwste technologie. Twee tot vier jaar later is je zogenaamde “coolste ding” ineens ingehaald door de concurrentie. Onderhoud wordt een last. Het vinden van mensen met de juiste kennis wordt een uitdaging. Je hebt het langetermijnvoordeel van een codebase verloren, iets waar we vroeger trots op waren.
Voor kleinere teams zoals het onze, weegt de overhead van een framework vaak zwaarder dan de voordelen. Met slechts een handvol ontwikkelaars is de communicatie direct en worden richtlijnen informeel gehandhaafd. Het toevoegen van een framework introduceert onnodige complexiteit, wat het ontwikkelproces eerder hindert dan ondersteunt.
Bij het werken met verschillende JavaScript-frameworks worden ontwikkelaars vaak geconfronteerd met een terugkerende uitdaging: elk framework heeft zijn eigen set van conventies, syntaxis en eigenaardigheden. Dit betekent dat voor elk nieuw project of framework tijd moet worden besteed aan het herontdekken van hoe taken te voltooien die in een andere omgeving routine waren. De leercurve die gepaard gaat met het beheersen van een nieuw framework kan de capaciteit om zakelijke vereisten effectief aan te pakken, vertragen.
De constante stroom van nieuwe frameworks en updates kan uitputtend zijn, aangezien ontwikkelaars op de hoogte moeten blijven van de laatste veranderingen en best practices. Dit verbruikt niet alleen kostbare tijd, maar kan ook leiden tot frustratie en burn-out. Vasthouden aan basis HTML, CSS en JavaScript kan deze problemen verminderen, doordat het een stabiele basis biedt die geen constante herbezinning en aanpassing vereist.
Hoewel frameworks de neiging hebben ontwikkelaars aan te moedigen op dezelfde manier te schrijven, is dit in de praktijk zelden het geval. Natuurlijk wil iedereen collega’s die op dezelfde manier schrijven als zijzelf. Maar aan de andere kant schrijf ik niet eens altijd op dezelfde manier. We zijn allemaal aan het leren en groeien, en dat geldt ook voor onze oplossingen voor problemen.
Heb je ooit geprobeerd je afhankelijkheden bij te werken in een codebase van 10 jaar geleden? Ik wel! Ik heb het geprobeerd! Ik heb gefaald! Het is werkelijk verbijsterend hoe een verouderde verzameling packages kan veranderen in één grote verwarrende chaos.
Eerlijk gezegd kan dat aan mijn gebrek aan kennis liggen. Maar vraag me niet om het oude framework te onderzoeken, het nieuwe framework te leren, gewoon om een simpele build aan de praat te krijgen. Hoeveel story points is dat? Euhm…
Als je de basisprincipes beheerst, kun je elk frontend-framework leren dat je wilt. Als je alleen een specifiek framework beheerst, veel succes wanneer het uit de gratie valt. Frameworks komen en gaan. Het is onvermijdelijk. De basisprincipes blijven waarschijnlijk langer bestaan.
Bij bijna al onze projecten maken we gebruik van een .Net-infrastructuur, aangezien we ervaren zijn in CMS/DXP-integratie. Deze softwarepakketten zijn geschreven in een bepaalde servertaal, en de servers zijn geconfigureerd om deze te ondersteunen. De frontend is in dit geval altijd de bovenste laag. De kers op de taart. Het deel dat zorgt voor een soepele en plezierige interactie.
Een specifiek trucje om te begrijpen in SPA-frameworks is dat optimalisatie plaatsvindt bij de paginalaag. Het benutten van alleen de bouwstenen voor de zogenaamde actieve pagina. Hoe bepaalt het welke pagina actief is? Het draait allemaal om het verplaatsen van routing naar de frontend. Je Webpack-configuratie samen met lazy-loaded imports kunnen nu de paginaverzoeken tree-shaken.
Tot op de dag van vandaag ontwikkelen wij nog steeds geen SPA's. We richten ons op website-integratie in Digital Experience Platforms (DXP). Dit betekent dat de klant beslist welke componenten op elke pagina worden weergegeven, en pagina's zijn niet vooraf geconfigureerd. Ze kunnen wel worden getemplate, maar dit betekent ook dat routing server-side wordt afgehandeld, wat naar mijn mening een groot voordeel is. Op deze manier kunnen we volledig dynamisch gaan, we leveren de LEGO, jij bouwt een huis, een vlakte, een stad, … of in dit geval, een website of een heleboel websites allemaal op hetzelfde platform. We gebruiken dezelfde bouwstenen, maar met een ander ontwerp of thema in gedachten.
Een van de sterkste argumenten tegen frameworks is performantie. Terwijl frameworks efficiëntie beloven, komen ze vaak met een lading ongebruikte functies en afhankelijkheden die onze applicaties opblazen en de laadtijden vertragen. Door vast te houden aan basis JavaScript zorgen we ervoor dat onze code slank en geoptimaliseerd is, wat resulteert in een snelle gebruikerservaring.
Bedenk dat het gebruik van een framework altijd, ongeacht hoe klein of geoptimaliseerd het framework ook is, altijd een extra stap is ten opzichte van het renderen van basis JavaScript.
Onze aanpak levert consistent hoge scores op in Lighthouse-audits (performance, best practices, accessibility, en SEO). Dit toont de effectiviteit aan van het gebruik van vanilla-technologieën bij het leveren van geoptimaliseerde en kwalitatief hoogstaande webapplicaties.
Je kunt de analogie van het .Net Framework met assembly maken. Maar dat laat een te grote kloof achter, naar mijn weten. Bij JavaScript is deze kloof relatief klein in vergelijking, en daarom is het argument tegen een framework relevanter. Vergeet ook niet dat JavaScript regelmatig wordt bijgewerkt en de ondersteuning in moderne browsers er erg positief uitziet.
Frameworks leggen van nature een set van conventies en abstracties op die soms onze flexibiliteit als ontwikkelaars kunnen beperken. Door frameworks te vermijden, herwinnen we de controle over onze code, waardoor we oplossingen kunnen creëren die zijn afgestemd op onze specifieke behoeften. Deze eenvoud verbetert niet alleen de leesbaarheid en onderhoudbaarheid van de code, maar bevordert ook creativiteit en innovatie.
In onze context biedt het vermijden van frameworks een groot voordeel: de langetermijn-herbruikbaarheid van onze code. Dit betekent dat we modules van eerdere projecten naadloos kunnen overdragen naar toekomstige projecten, zoals drag-and-dropfunctionaliteit. Frameworks binden ons vaak aan hun specifieke ecosysteem, waarbij updates en wijzigingen tussen versies en afhankelijkheden de compatibiliteit van componenten kunnen verstoren, waardoor het moeilijk wordt om ze over verschillende projecten te hergebruiken. Door vast te houden aan eenvoudige HTML, CSS en JavaScript blijft onze code modulair en draagbaar. Dit stelt ons in staat om gebruik te maken van bestaande oplossingen zonder opnieuw te moeten beginnen, wat uiteindelijk tijd en moeite bespaart, terwijl het consistentie tussen projecten waarborgt.
Voor kleine teams is het onboardingproces van nieuwe ontwikkelaars cruciaal. Door vast te houden aan eenvoudige webtechnologieën, zorgen we ervoor dat nieuwe medewerkers meteen aan de slag kunnen zonder de noodzaak om een complex framework te leren. Dit verkort de inwerktijd en stelt nieuwe teamleden in staat om vanaf dag één effectief bij te dragen.
Hoewel het waar is dat jonge ontwikkelaars mogelijk nog niet alle basisprincipes beheersen, zijn de fundamenten van webontwikkeling, zoals het begrijpen van HTML, CSS en de basisprincipes van JavaScript, tijdloos en van onschatbare waarde. Deze kernvaardigheden vormen de basis waarop ontwikkelaars hun expertise in de loop van de tijd opbouwen. In tegenstelling tot framework-specifieke kennis, die snel verouderd kan zijn met nieuwe releases of veranderende trends in de industrie, biedt het beheersen van de basis een blijvende basis voor voortdurende leren en aanpassing. Het bevordert een dieper begrip van webtechnologieën en de principes van softwareontwikkeling, waardoor ontwikkelaars een breed scala aan uitdagingen in hun carrière kunnen aangaan. In tegenstelling, door alleen op frameworkgerelateerde vaardigheden te vertrouwen, kan de aanpasbaarheid en groei van ontwikkelaars beperkt worden, omdat ze afhankelijk worden van specifieke tools in plaats van fundamentele probleemoplossende vaardigheden. Investeren in fundamentele kennis zorgt ervoor dat ontwikkelaars niet alleen excelleren in de huidige technologieën, maar ook wendbaar blijven en in staat zijn toekomstige innovaties in het steeds evoluerende landschap van webontwikkeling te omarmen.
HTML, CSS en JavaScript zijn de bouwstenen van het web. Door frameworks te vermijden, vereenvoudigen we onze bouwstappen en codebeheerprocessen, waardoor we de overhead verminderen en de productiviteit verhogen. Deze gestroomlijnde aanpak zorgt ervoor dat onze codebase schoon en onderhoudbaar blijft, zelfs wanneer projecten in de loop van de tijd evolueren.
Alle grote CMS-systemen volgen het MVC (Model-View-Controller) patroon, wat van nature een duidelijke scheiding van zorgen (SoC) bevordert. Door gebruik te maken van eenvoudige HTML, CSS en JavaScript versterken we deze scheiding, waardoor het gemakkelijker wordt om onze codebase te onderhouden en te debuggen. Deze duidelijkheid verbetert het onderhoud en de verfijning zodra een project zijn laatste fase bereikt.
Afhankelijk van wat je aan het bouwen bent, zijn frameworks goed geschikt voor grote en complexe applicaties die schaalbare architectuur en robuuste state management vereisen. Ze bieden structuur en consistentie, waardoor het gemakkelijker wordt om uitgebreide codebases te beheren en te onderhouden. Bij het bouwen van SPAs die dynamische content-updates vereisen zonder pagina-herladen, zijn frameworks zoals React, Angular en Vue ideaal. Ze bieden efficiënte client-side routing en state management. Voor webapplicaties die real-time functies nodig hebben, zoals live-updates, chatfunctionaliteit of samenwerkingshulpmiddelen, kunnen frameworks de implementatie van websockets en andere real-time technologieën vereenvoudigen.
Afhankelijk van je vaardigheden. Frameworks komen met vooraf gebouwde componenten en bibliotheken, die snel prototypen en snellere iteraties mogelijk maken. Dit kan vooral voordelig zijn in startup-omgevingen of voor projecten met strakke deadlines. Het vermogen om componenten tussen projecten te hergebruiken, kan de ontwikkeling aanzienlijk versnellen. Frameworks bieden vaak een rijk ecosysteem van componenten van derden die gemakkelijk geïntegreerd kunnen worden.
Als je ontwikkelteam al bedreven is in een bepaald framework, kan het benutten van die expertise leiden tot snellere en efficiëntere ontwikkeling. Vertrouwd zijn met de tools en best practices van het framework kan de leercurve verkleinen en de productiviteit verbeteren. Frameworks met een grote gemeenschap en uitgebreide documentatie maken het makkelijker om nieuwe ontwikkelaars in te werken, omdat zij snel op de hoogte kunnen raken van gestandaardiseerde praktijken en tools.
Voor klanten die sterk gepersonaliseerde en verfijnde oplossingen eisen, kunnen frameworks de nodige tools bieden om geavanceerde en feature-rijke applicaties te creëren. Dit gaat echter vaak gepaard met verhoogde ontwikkeltijd en kosten. Als het primaire doel is om snel een functionele oplossing te leveren zonder uitgebreide maatwerk, kan het gebruik van een framework nog steeds voordelig zijn vanwege de out-of-the-box functies en componenten die veelvoorkomende taken efficiënt afhandelen.
Aangepaste oplossingen zijn vaak duurder vanwege de extra ontwikkeltijd die nodig is voor het afstemmen en aanpassen. Frameworks kunnen helpen om de kosten te beheersen door het ontwikkelproces te stroomlijnen en bestaande componenten te benutten. Houd rekening met de implicaties voor langdurig onderhoud. Frameworks kunnen door hun gestructureerde aanpak en gemeenschapssteun het lopende onderhoud vereenvoudigen, maar ze kunnen ook afhankelijkheden introduceren die over tijd beheerd moeten worden.
De toepasbaarheid van frameworks hangt af van verschillende factoren, zoals de complexiteit van het project, de snelheid van ontwikkeling, de expertise van het team en de aard van de oplossing die wordt gecreëerd. Voor grootschalige, complexe toepassingen en real-time functionaliteiten bieden frameworks essentiële tools en structuur. Ze maken snelle prototyping en efficiënte ontwikkeling mogelijk, vooral wanneer het team vertrouwd is met het framework. Voor projecten die zeer op maat gemaakte oplossingen vereisen of waar eenvoud en onderhoudbaarheid cruciaal zijn, kan een meer op maat gemaakte benadering met eenvoudige technologieën de voorkeur hebben.
De keuze hangt uiteindelijk af van de afweging tussen de vereisten van het project, de vaardigheden van het team en het gewenste resultaat.
Klaar om je digitale ervaring naar een hoger niveau te tillen? Neem gerust contact met ons op voor meer informatie over onze diensten en hoe we jou kunnen helpen het volledige potentieel van je digitale marketing te benutten.
Neem contact op met één van onze consultants om de perfecte match te vinden die bij je past en waarmee je kunt groeien.