Johnny Hogenbirk: Artikelen, code-snippets, etc.


Home

Weg met frameworks - 07-11-2021


Inleiding

Degene die software gaat leren ontwikkelen, zal vaak beginnen met HTML, CSS en Javascript. Daarna de overstap maken naar een backend taal (vaak PHP) en de database (vaak MySql). Dit zie je terugkomen in opleidingsprogramma's maar ook op bijvoorbeeld de populaire site w3schools. Het menu heeft ook deze volgorde.
Maar dan zien we in het menu 'Bootstrap'. En verder naar rechts 'W3.css' en 'Jquery'.
Grappig, heb je net geleerd hoe je een webapplicatie maakt, moet je nog een framework gaan gebruiken voor CSS en Javascript?
En het is even zoeken, maar je vindt ook andere frameworks op W3Schools, bijvoorbeeld 'Angular JS' (voor Javascript) en 'Laravel' (voor PHP).
Wie googled op frameworks voor CSS, Javascript of PHP treft heel veel frameworks. Dat zie je al aan de hits 'top 10 frameworks'. En er zijn veel meer dan 10.
Wie googled op redenen om frameworks te gebruiken of op voor- en nadelen van frameworks, zal met name enthousiaste verhalen over framework lezen, weinig nadelen. Toch zijn die er volop. In dit artikel meer hierover.
Op W3Schools wordt Bootstrap als een framework aangeduid en Jquery als bibliotheek. Er is een verschil tussen bibliotheken en frameworks, maar dat is soms een nogal subtiel en discutabel onderscheid. In principe dwingt een framework je in een bepaalde structuur en een bibliotheek biedt mogelijkheden om onderdelen (functies/classes) te gebruiken binnen een vanilla taal.
Voor het gemak wordt in dit artikel over frameworks geproken. Daarmee worden dus sets aan code bedoeld, die je een structuur en/of verminking van je vanilla code opleggen.


Wat is een frameworks

Een framework is een pakket code die je kunt downloaden of via code kunt installeren. De bekende frameworks zijn open source, gratis te downloaden. Het kan door één persoon zijn ontwikkeld (Laravel: Taylor Otwell) of door een bedrijf (eerst voor eigen gebruik, daarna als open source ter beschikking gesteld, bijvoorbeeld Bootstrap door Twitter).
Een framework kan een bepaalde mappenstructuur afdwingen. Het legt je een structuur op. Doorgaans is dit MVC (zie ook een ander artikel van mij). Een voorbeeld hiervan is Laravel. Je wordt eigenlijk gedwongen om de index.php van Laravel over te nemen en te starten met het inrichten van een controller, met al een voorstel van hoe je dat zou moeten doen. Binnen in het framework, waar je de applicatie specifieke code schrijft, kun je normale PHP gebruiken. Maar je kunt ook classes uit de bibliotheek van Laravel gaan gebruiken, zoals Eloquent.
Een framework kan ook niets meer (en niets minder) zijn dan een map met code. Bijvoorbeeld Jquery en Bootstrap. Je kunt de style die Bootstrap je min of meer dan oplegt gaan gebruiken. Bij Jquery kun je de typische Jquery code gaan gebruiken, startend met $, naast je normale javascriptcode.


Genoemde voordelen van frameworks

- Tijd Bij nagenoeg alle sites wordt als voordeel genoemd dat je sneller code kunt ontwikkelen. Vaak als enige voordeel trouwens, maar in elk geval als eerste/grootste voordeel. Dit komt doordat ontwikkelaars gebruik maken van het standaard framework, met kant-en-klare componenten (CBD dus).
Ook wordt 'standaard autorisatie functionaliteit' genoemd (bij backend systeem) en 'ingebouwde beveiliging tegen hacking'. Ook dat bespaart tijd.
- Structuur Beter gestructureerde en onderhoudbare code (bij Laravel wordt daarbij dan ook vaak MVC genoemd).
Er worden nog wel meer voordelen genoemd, maar die zijn meer van hetzelfde. Zoals 'betere beveiliging' bij Laravel. Die kun je natuurlijk ook gewoon zelf bouwen, maar dat hoeft niet, dus bouw je sneller. Of 'minder code hoeven te schrijven'. Dat lijkt me geen doel, maar tijdswinst opleveren, dus is gelijk aan het eerst genoemde voordeel. Of tijdwinst door 'Browser onafhankelijkheid' (bij CSS en Javascript frameworks). Kun je ook zelf bouwen, maar levert tijdswinst op, weer de eerste reden.


Genoemde nadelen van frameworks

- Traag Soms wordt slechtere performance genoemd. Dit komt doordat meer code wordt aangeroepen. Bij frontend gaat het dan om de omvang van de bibliotheek die in de browser moet worden geladen. Vaak eenmalig trouwens, bij een volgende oproep wordt het uit de cache gehaald (als die niet is uitgeschakeld). Bij backend gaat het soms om de omvang van de bibliotheek, maar soms ook door allerlei (deels nodige) checks, deels vanwege backwards compatibility.
Als er trouwens nadelen worden genoemd, vaak geen enkele. Alleen op forums lees je nog wel meer opmerkingen. Maar in artikelen en blogs blijft het eigenlijk altijd beperkt tot geen of deze ene.
Performance is natuurlijk wel een dingetje, maar daar zit de doorsnee ontwikkelaar of software bureau niet mee. Wat snellere servers (als backend) en opgelost. Of de gebruiker moet maar even wachten (frontend).
Althans, als het als nadeel wordt genoemd, wordt daar niet zwaar aan getild.


De nadelen van frameworks

Volgens mij kloppen de voordelen niet helemaal en zijn er meer nadelen, die de voordelen vaak teniet doen.
Natuurlijk, het is erg afhankelijk van of je in je eentje programmeert of in een bedrijf. En of je een standaard pakket of maatwerk applicaties maakt/onderhoudt. En of het websites zijn of (complexe) webapplicaties.
Toch durf ik de stelling aan dat het in het algemeen niet lonend is om frameworks te hanteren.
- Tijd Voor de student: nadat je een taal hebt geleerd, moet je ook nog een framework leren. Dit is een nadeel voor opleidingen c.q. de student. In plaats van jezelf te verbeteren in een taal, ben je bezig met één of meer frameworks te leren. Die je mogelijk nooit gaat gebruiken, omdat je toekomstige werkgever die niet gebruikt. Daardoor kom je als minder goede ontwikkelaar van school dan als je geen frameworks had geleerd.
Voor de werkgever: heb je eindelijk na lang werven een goede sollicitant op gesprek (al dan niet een schoolverlater), kent hij/zij nou net dat framework niet (goed) die jij nou net gebruikt. Dus maar een cursus er tegenaan gooien of mee laten kijken met collega's.
En het klinkt zo mooi op de site van het framework: makkelijk te leren. Nou, zelfs ervaren ontwikkelaars hebben maanden tijd nodig om het framework goed te gebruiken.

En dan heb je een framework geleerd, werk je er een paar jaar mee, raakt dat framework uit de gratie. Geen updates, beveiligingslekken, geen browsersupport, what ever. Dan maar weer een nieuwe aanleren en alle code omzetten naar het nieuwe framework.
Het is lastig in te schatten hoe lang een framework mee gaat. Sommige bestaan al wel 5 of 10 jaar, maar werden de eerste jaren nauwelijks gebruikt. In elk geval gaan ze minder lang mee dan de basis programmeertalen. Zoals PHP, die is in 1994 ontwikkeld. Frameworks komen en gaan, de taal blijft bestaan.

Met wat geluk heb je een opkomend framework gekozen en kun je er jaren mee werken. Echter, van tijd tot tijd komt er een nieuwe versie. Met wat geluk is alles backwards compatible. Maar vaak niet (geheel). Had je net de upgrade van je PHP-versie achter de rug, kun je ook nog eens iedereen bijscholen en je code testen en aanpassen. De overgang van Laravel 4 naar 5 bijvoorbeeld, dit vereiste een omzetting van de mappenstructuur.

Natuurlijk, als alles loopt kun je sneller ontwikkelen. Maar als je een eigen framework of op zijn minst een componenten bibliotheek had gehad, kon je dat ook. Niemand bouwt bij elk project alles van scratch af aan. Je gebruikt altijd de code van het vorige project.
En, een goede ontwikkelaar is een goede googlelaar. Alles staat op het web, je kunt altijd code vinden voor een specifieke uitdaging die je hebt. En vaak zitten in frameworks nou net niet die functionaliteit die je nodig hebt, dus zoeken moet je toch. En er is meer dan wat er in de bib van het framework zit.

Elders op mijn site heb ik een MVC-model uitgewerkt, inclusief code. En voor gevorderde ontwikkelaars een double loop generator (die in de MVC kan hangen). Als je die als basis hebt en je hebt je eigen componenten, hoef je geen framework meer om sneller te gaan ontwikkelen.
- Structuur Het vaak als tweede genoemde voordeel is echt onzin. Je kunt heel gemakkelijk afspreken MVC te hanteren en daarin een bepaalde eigen- of bedrijfsmethodiek afspreken. Zie wederom het MVC-artikel van mij, met code structuur. En, je moet toch al conventies afspreken of de wijze van programmeren. In een team heb je sowieso een 'handboek soldaat' nodig, hetzij digitaal, hetzij onderling (mondeling) afgesproken.
Als een framework als middel om te structureren wordt gebruikt, is er een gebrek aan management talent.
- Traag Performance werd (terecht) als nadeel genoemd. Dit kan echt serieuze proporties aannemen.
Voor sites is het enorm belangrijk snel te zijn: google scoort sites ook op snelheid. Met een kleine site kwam ik (zonder framework!) op een score van 99 (op de google ranking site).
Drenthe.nl komt maar op 60. Met dank aan o.a. 4Mb(!) aan CSS* (framework niet bekend) en met een lading jquery-code. Voor gebruikers geldt dat een zogenaamd minimaal verschil nou net het grote verschil kan maken tussen lekker werken en stress. Dat gaat om tienden van seconden.
En tot slot, een slechte performance betekent energie verspilling. Niet bepaald groen dus. Zie ook de links onderaan.

* Over enorme CSS bestanden gesproken: drenthe.nl is wel een uitzondering, maar je ziet meer enorme CSS bronnen. Bijv. 121.000 bytes in overheid.nl, 237.000 bytes bij klm.nl, 543.000 bytes bij hema.nl. De KickerPlaza applicaties bevatten nog geen 11.000 bytes (de eerlijkheid gebied mij te melden dat er ook best veel inline CSS wordt gebruikt).

Meer artikelen hierover lezen? Een paar leuke:
Algemeen Catonmat

Javascript Matt Burgess
Javascript David Wickes
Javascript Vanilla JS

PHP The Wrong Way (incl. anti OO)

Ook leuk, performance vergelijking van vanilla PHP t.o.v. Laravel:
PHP
Laravel
PHP is pakhembeet 10 a 20 keer zo snel!


Opmerkingen? Ze zijn van harte welkom: email@johnnyhogenbirk.nl!