| - | 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). |
| - | 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. |
| - | 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. |