PHP libraries tegenwoordig naar mijn idee extreem bloated

[powershift]

Goedemiddag,

Onderwerp
----------------------------------------------------------------------------------------
Aangbeoden PHP libraries zijn naar mijn idee tegenwoordig veel te uitgebreid en doen niet meer rechttoe rechtaan wat ze moeten doen.


Inleiding
----------------------------------------------------------------------------------------
Het volgende, voor een klant van mij heb ik een MultiSafepay implementatie moeten maken voor een maatproject. Daarom kon ik niet standaard een WooCommerce, Prestashop, Magento oid implementatie downloaden en installeren.

Geen probleem. Ik kijk of er een standaard PHP libary beschikbaar is voor MultiSafepay en dat was er.
Maar ik laadt de bestanden in visual studio en het eerste dat mij opvalt is dat er echt een enorme hoeveelheid aan verschillende bestanden bij zit.

Echt van alles en nog wat. Veel dependancies die door middel van composer geladen moeten worden.
Vervolgens dacht ik bij mezelf, laat ik de documentatie eens doorlezen. En na nog geen halve minuut dacht ik bij mezelf... Als ik zelf een eigen PHP klasse maak. Moet dit veel korter en simpeler kunnen.

Met het oog op een paar uurtjes speling te hebben ben ik begonnen en na een vrij korte tijd had ik een MultiSafepay implemnatie die zonder problemen hetzelfde kon als de library die MSP zelf aanbied.

Echter mijn implementatie is zo'n 500 regels lang. En als ik wil kan ik het zo in composer gieten. Maar dat hoefde in dit geval niet.


Mijn stelling en tevens wel ergens mijn vraag
----------------------------------------------------------------------------------------
Mijn idee is dat tegenwoordig de vele PHP libraries die worden aangeboden te uitgebreid zijn. Niet meer rechttoe rechtaan wat ze moeten doen maar honderd en één dependancies en heel veel dingen met omhalen.

Ben ik nu gek? Of mis ik een belangrijke reden hiervoor?

Kleine extra toelichting
----------------------------------------------------------------------------------------

Neem de Mollie API klasse als voorbeeld. Vroeger had je een paar bestandjes. Een klasse voor de error handling en een klasse voor de API zelf. That's it.
Tegenwoordig moet je meerdere sidepackages laden voordat je de standaard API klasse kunt gebruiken.

Zelfde geld voor MultiSafePay.
Terwijl ik in één klasse zowel de CURL afhandeling heb geregeld. Maar ook de foutafhandeling.

Nu zie ik dat tegenwoordig deze manier van werken (die van vele bestanden) toch meer en meer standaard is. Nu kan ik denken dat de hele wereld gek is. Maar dat zou stom zijn.
Zie ik nu iets over het hoofd? Of is het iets anders?

[ Voor 3% gewijzigd door powershift op 04-05-2022 17:17 ]

[xh3adshotx]

Vooropgesteld: ben wel een dev maar niet met PHP

Als ik naar de repository van MultiSafePay kijk dan lijken ze hun code (goed) opgedeeld te hebben in kleine classes en per class Unit Tests geschreven te hebben. Over het algemeen wordt een class van 500 regels (discutabel) als "bad practice" gezien. Hoe meer regels je class heeft, des te meer kans je hebt dat hij meer dan één ding doet. Dat betekend dat die lastiger te Unit Testen is. Wat je in feite zelf ook al aangeeft: hij doet de API calls en handelt de excepties af.

Wikipedia: Single-responsibility principle

[RobIII]

powershift schreef op woensdag 4 mei 2022 @ 17:16:
een paar uurtjes [...] vrij korte tijd [...]

500 regels lang

Als jij in 'een paar uurtjes' en 'vrij korte tijd' 500 regels code produceert dan zet ik daar mij vraagtekens bij en ook bij in hoeverre je code dan goed getest is. Ik zeg niet dat die andere implementaties zo perfect zijn of niet zoveel kleiner kunnen, maar ik denk wel dat dergelijke implementaties vaak door tientallen, honderden, duizenden mensen gebruikt worden en (dus) vaak nét iets uitgebreider ("in het veld") getest zijn.

Maar, wie weet, misschien heb je wel een vele betere implementatie geschreven; goed mogelijk. Top! Wat let je om 'm te delen / te open sourcen? Waar kunnen we 'm vinden?

Verder zie ik niet echt wat je met dit topic wil bereiken. De definitie van "Extreem bloated" ligt bij iedereen ergens anders, wat de één prima vindt kunnen vindt de ander "extreem bloated". Het is behoorlijk subjectief. Maar goed, en dan? Wat verwacht je dat er uit dit topic komt? "Ja, libraries zijn tegenwoordig extreem bloated" of "Nee, dat valt allemaal reuze mee". En dan? Het verandert niets

[CrazyFool]

Vergeet niet de api van multisafepay veel meer behelst dan enkel een betaling starten en daarvan de status opvragen. Statistieken en allerlei andere api calls zijn ook onderdeel van dat package.

Dan nog de vraag, waarom geen composer gebruiken? Ik gebruik liever een package die teveel kan zodat ik later makkelijk kan verder bouwen. Dan een package die maar een paar dingen kan en ik er zelf weer extensies voor moet gaan schrijven.

[moijamie]

Die MultiSafePay repo is waarschijnlijk meer OOP dan jouw implementatie.

Kijk maar in de readme hoe je er mee werkt.

code:

$amount = new Money(2000, 'EUR'); // Amount must be in cents!!

$address = (new Address())
    ->addStreetName('Kraanspoor')
    ->addStreetNameAdditional('(blue door)')
    ->addHouseNumber('39')
    ->addZipCode('1033SC')
    ->addCity('Amsterdam')
    ->addState('Noord Holland')
    ->addCountry(new Country('NL'));

$customer = (new CustomerDetails())
    ->addFirstName('John')
    ->addLastName('Doe')
    ->addAddress($address)
    ->addEmailAddress(new EmailAddress('[e-mail]'))
    ->addPhoneNumber(new PhoneNumber('0208500500'))
    ->addLocale('nl_NL');

$pluginDetails = (new PluginDetails)
    ->addApplicationName('My e-commerce application')
    ->addApplicationVersion('0.0.1')
    ->addPluginVersion('1.1.0');

$paymentOptions = (new PaymentOptions())
    ->addNotificationUrl('http://www.example.com/client/notification?type=notification')
    ->addRedirectUrl('http://www.example.com/client/notification?type=redirect')
    ->addCancelUrl('http://www.example.com/client/notification?type=cancel')
    ->addCloseWindow(true);

$orderRequest = (new OrderRequest())
    ->addType('redirect')
    ->addOrderId($orderId)
    ->addDescriptionText($description)
    ->addMoney($amount)
    ->addGatewayCode('IDEAL')
    ->addCustomer($customer)
    ->addDelivery($customer)
    ->addPluginDetails($pluginDetails)
    ->addPaymentOptions( $paymentOptions);

$transactionManager = $multiSafepaySdk->getTransactionManager()->create($orderRequest);
$transactionManager->getPaymentUrl();

Ik verwacht dat jouw implementatie een hele andere API heeft, waar je dus niet met objecten kan werken. En dus ook geen autocompleting in je IDE krijgt. Dan moet je de API docs constant er bij hebben om te kijken hoe de velden heten.

Het is inderdaad meer bestanden/code om "net/correct" OOP te schrijven maar het levert ook veel op.

Ik ben wel benieuwd naar je implementatie kan je hem op Github zetten?

[Johnny]

Ja, het is een trend voor PHP libraries om steeds groter en complexer te worden. Er is een jarenlange trend onder PHP-ontwikkelaars om verder te professionaliseren; in de praktijk betekent dit dat de taal, en ook de code en gebruikte werkwijzen steeds meer op Java gaan lijken.

Dit alles komt over als onzinnig complex tenzij je ook je werkwijze zelf aanpast. Door "moderne" PHP code te schrijven in een IDE (dus niet een text editor) krijg je opeens heel veel voordelen van de integratie met de IDE omdat deze dan je code beter begrijpt en kan genereren, controleren en aanvullen en helpen met navigeren.

Dat betekent wel dat dynamische en "magic" code tegenwoordig minder populair is en je veel meer code schrijft die in pricincipe hetzelfde doet, maar omdat je een IDE gebruikt kost het niet meer tijd en omdat statische analyse mogelijk is kun je ook code analyzers gebruiken en geautomatiseerde tests om bugs uit te sluiten die bij meer dynamische code veel meer tests nodig zouden hebben.

[Harrie_]

Herkenbaar verhaal wat mij betreft. Ik kom meer dan eens libraries tegen met allerlei dependencies die imho totaal overbodig zijn. Laatst had ik nog een library als dependency die van alles deed met validatie; duizenden regels code terwijl er alleen 1 functie werd gebruikt om te checken of een telefoonnummer klopt (in mijn specifieke geval enkel Nederlands). Het liefste zou ik alles er gewoon uitslopen en zelf een functie van 5 regels erbij zetten maar dan kan ik niets meer auto-updaten... Ach, ik verlang weleens terug naar de tijd dat je zelf een xxx.class.php file downloade en die in je project trok met een include of require, maar die tijd is helaas geweest.

[phex]

Composer heeft package development onder PHP extreem krachtig gemaakt.

Veel libraries gebruiken dan ook uiteindelijk dezelfde dependencies. Hierdoor is die bloat vooral zichtbaar bij je eerste composer package die je include.

Kijk bijvoorbeeld eens naar Symfony of Laravel. Deze bestaan voornamelijk uit composer packages met een laagje "lijm".

Als je zelf een hobby project hebt, dan maak er vooral zelf iets van. Als je maar 1 regel gebruikt van een library kun je je afvragen of het de moeite waard is om een library te gebruiken.

Maar voor serieus development met PHP kun je echt niet zonder composer. Al was het alleen maar omdat je heel makkelijk packages kan updaten en alle extensie/versie checks ingebakken zit.

[RobIII]

phex schreef op donderdag 5 mei 2022 @ 17:24:
Als je maar 1 regel gebruikt van een library kun je je afvragen of het de moeite waard is om een library te gebruiken.

Naja, er kan natuurlijk een onmeunige hoeveelheid code achter $library->DoSomething('foo'); zitten dus dat vind ik niet echt een goede indicator

[phex]

Dat is ook niet echt 1 regel dan 😊

[Cartman!]

Het klinkt vooral alsof je niet snapt hoe code netjes gestructureerd zou moeten worden om goed te onderhouden en testen is. Als je in 2022 nog steeds denkt dat je voor ieder dingetje t wiel opnieuw moet uitvinden wens ik je veel succes. Maak goed gebruik van bestaande libraries, die hebben hun nut al bewezen en besparen je heel veel werk.

Opslag is goedkoop, staar je niet blind op de hoeveelheid bestanden, dat heeft geen zin.

[ Voor 11% gewijzigd door Cartman! op 05-05-2022 21:24 ]

[Lethalis]

Geen idee van PHP, maar ik heb collega .NET developers die mijn code ook niet altijd rechttoe rechtaan vinden, met een hoop dependencies etc.

Hoe komt dat? Omdat ik steeds minder zin heb om dingen zelf te programmeren en dus zoveel mogelijk kant en klare brokken binnen haal voor wat ik nodig heb. Als .NET developer heb ik het dan bijvoorbeeld over Dapper (simpele data naar object mapper), Serilog (universele logging library) etc.

Heb ik die zaken altijd nodig? Nee, maar het is wel verdomd makkelijk.

Ook ben ik geneigd complexe code zo te schrijven dat hij testbaar is. Recent nog heb ik code een refactor gegeven zodat een class niet meer zelf data ging inlezen, maar puur en alleen de verwerking deed (single responsibility principle). Hierdoor kan ik de class neppe data voeren en controleren of de output van de verwerking is wat ik verwacht (unit test schrijven).

Dat betekent uiteraard dat ik een aparte functies en classes heb om de data te lezen en in het geheugen vast te houden. Noodzakelijke "bloat" om het testbaar te maken.

Het kan in de helft van de hoeveelheid code, maar dan raak je de voordelen kwijt. En het kan efficiënter (data streamen ipv in geheugen houden), met het risico dat de code weer complexer / minder goed testbaar wordt.

Premature optimization is ook een ding. Als de code prima werkt en geen probleem geeft, dan ga ik niet tot het gaatje om het zo efficiënt mogelijk te maken. Dat doe ik waar het nodig is.

Anyways... ik werk sinds 2003 fulltime als developer. Ik doe tegenwoordig een hoop dingen die ik in 2003 niet had begrepen en die ik overmatig complex had gevonden

[Lethalis]

phex schreef op donderdag 5 mei 2022 @ 17:24:
Als je maar 1 regel gebruikt van een library kun je je afvragen of het de moeite waard is om een library te gebruiken.

Als het een library is die met een externe partij praat, zou ik altijd de library gebruiken. Want als die partij besluit morgen een nieuwe api te releasen, dan brengen ze vaak ook een nieuwe library uit.

Even updaten en klaar.

Anders mag je zelf jouw eigen - in TS zijn geval MultiSafepay - library gaan onderhouden elke keer. Super irritant.

[ Voor 3% gewijzigd door Lethalis op 07-05-2022 22:22 ]

[jeroen3]

powershift schreef op woensdag 4 mei 2022 @ 17:16:
Vervolgens dacht ik bij mezelf, laat ik de documentatie eens doorlezen. En na nog geen halve minuut dacht ik bij mezelf... Als ik zelf een eigen PHP klasse maak. Moet dit veel korter en simpeler kunnen.

[...]

De grootste valkuil van het vak.
“Wat een onzin deze library, dat kan ik veel beter!”…

Nu komt straks jouw opvolger, en die denkt precies hetzelfde. Die snapt jouw documentatie niet en kan het veel beter!

Dit is een van de grootste problemen van software, slechte kennisoverdracht en het continu willen heruitvinden van het wiel. Meer lagen. Meer code. Meer geheugen. Meer energie.

[RagingPenguin]

Lethalis schreef op zaterdag 7 mei 2022 @ 22:21:
[...]

Als het een library is die met een externe partij praat, zou ik altijd de library gebruiken. Want als die partij besluit morgen een nieuwe api te releasen, dan brengen ze vaak ook een nieuwe library uit.

Even updaten en klaar.

Anders mag je zelf jouw eigen - in TS zijn geval MultiSafepay - library gaan onderhouden elke keer. Super irritant.

Dit, en zeker voor dingen waar security super kritiek is zoals betaaloplossingen. Daar wil je niet zelf mee gaan klooien.

[RagingPenguin]

moijamie schreef op woensdag 4 mei 2022 @ 17:44:
Die MultiSafePay repo is waarschijnlijk meer OOP dan jouw implementatie.

Kijk maar in de readme hoe je er mee werkt.

code:

$amount = new Money(2000, 'EUR'); // Amount must be in cents!!

$address = (new Address())
    ->addStreetName('Kraanspoor')
    ->addStreetNameAdditional('(blue door)')
    ->addHouseNumber('39')
    ->addZipCode('1033SC')
    ->addCity('Amsterdam')
    ->addState('Noord Holland')
    ->addCountry(new Country('NL'));

$customer = (new CustomerDetails())
    ->addFirstName('John')
    ->addLastName('Doe')
    ->addAddress($address)
    ->addEmailAddress(new EmailAddress('[e-mail]'))
    ->addPhoneNumber(new PhoneNumber('0208500500'))
    ->addLocale('nl_NL');

$pluginDetails = (new PluginDetails)
    ->addApplicationName('My e-commerce application')
    ->addApplicationVersion('0.0.1')
    ->addPluginVersion('1.1.0');

$paymentOptions = (new PaymentOptions())
    ->addNotificationUrl('http://www.example.com/client/notification?type=notification')
    ->addRedirectUrl('http://www.example.com/client/notification?type=redirect')
    ->addCancelUrl('http://www.example.com/client/notification?type=cancel')
    ->addCloseWindow(true);

$orderRequest = (new OrderRequest())
    ->addType('redirect')
    ->addOrderId($orderId)
    ->addDescriptionText($description)
    ->addMoney($amount)
    ->addGatewayCode('IDEAL')
    ->addCustomer($customer)
    ->addDelivery($customer)
    ->addPluginDetails($pluginDetails)
    ->addPaymentOptions( $paymentOptions);

$transactionManager = $multiSafepaySdk->getTransactionManager()->create($orderRequest);
$transactionManager->getPaymentUrl();

Ik verwacht dat jouw implementatie een hele andere API heeft, waar je dus niet met objecten kan werken. En dus ook geen autocompleting in je IDE krijgt. Dan moet je de API docs constant er bij hebben om te kijken hoe de velden heten.

Het is inderdaad meer bestanden/code om "net/correct" OOP te schrijven maar het levert ook veel op.

Ik ben wel benieuwd naar je implementatie kan je hem op Github zetten?

En behalve dat doet het ook best wel een hoop data validatie in de domain classes wat ook extra regels code kost, maar het leven van de developers wel een stuk makkelijker maakt als het gaat om het debuggen van vreemd gedrag.

[Cartman!]

@powershift hebben we je mening inmiddels iets kunnen bijstellen?

[com2,1ghz]

jeroen3 schreef op zaterdag 7 mei 2022 @ 22:34:
[...]

De grootste valkuil van het vak.
“Wat een onzin deze library, dat kan ik veel beter!”…

Nu komt straks jouw opvolger, en die denkt precies hetzelfde. Die snapt jouw documentatie niet en kan het veel beter!

Dit is een van de grootste problemen van software, slechte kennisoverdracht en het continu willen heruitvinden van het wiel. Meer lagen. Meer code. Meer geheugen. Meer energie.

Daar is niets mis mee. Meeste software is nooit af. Keuzes veranderen. Ook de genomen architectuurwijzigingen.
De vaardigheid van nette code schrijven waarbij de verantwoordelijkheden duidelijk zijn zal ervoor zorgen dat die library zo vervangen kan worden door een ander implementatie.

De een noemt dat "lagen", de ander scheiden van verantwoordelijkheden.

[Janoz]

Harrie_ schreef op woensdag 4 mei 2022 @ 19:25:
Herkenbaar verhaal wat mij betreft. Ik kom meer dan eens libraries tegen met allerlei dependencies die imho totaal overbodig zijn. Laatst had ik nog een library als dependency die van alles deed met validatie; duizenden regels code terwijl er alleen 1 functie werd gebruikt om te checken of een telefoonnummer klopt (in mijn specifieke geval enkel Nederlands). Het liefste zou ik alles er gewoon uitslopen en zelf een functie van 5 regels erbij zetten maar dan kan ik niets meer auto-updaten... Ach, ik verlang weleens terug naar de tijd dat je zelf een xxx.class.php file downloade en die in je project trok met een include of require, maar die tijd is helaas geweest.

Wat dan? Het node verhaal waarbij je libraries had die alleen even of oneven testen? Of moeten ze het gewoon zelf doen en dat je vervolgens een telefoonnummer hebt dat in library a wel geldig is maar in library b niet omdat de implementatie net anders is?

Bij 1 dependency al die validaties binnen trekken lijkt overdreven, maar wanneer je 4 dependencies heb t is het verdomt handig dat ze dezelfde validaties gebruiken.

[jammo]

Om toch maar even een nadeel te noemen van het gebruik van externe libraries is dat het tegenwoordig voor kwaadwillenden wat makkelijker wordt gemaakt om legitieme software te voorzien van kwaadaardige code.

Doordat er steeds meer gebruik wordt gemaakt van libraries, ontwikkeld door derden, die gebuik maken van andere libraries ontwikkel door weer andere mensen (etc..) wordt het ook makkelijker om ergens in die tree van afhaneklijkeden iets te verstoppen wat niet zo snel opvalt.

Recent is er toevallig een rust crate naar voren gekomen met een probleem:
https://blog.rust-lang.or...ate-rustdecimal.html?s=09
maar (helaas) zijn er zo legio voorbeelden waarbij code via via in je eigen code base terecht zou kunnen komen, zonder dat je er snel van op de hoogte bent.

Hierdoor zou dus een multisafepay api library (die je vertrouwd) toch kwaadwillende code kunnen bevatten omdat ook zei afhankelijk van van libraries van derden..

edit: Ik wil hiermee uiteraard niet zeggen dat je dit soort libraries niet zou moeten gebruiken!
Blijf alleen (altijd) zelf een beetje opletten op wat voor afhankelijkheden je hebt zodat, mocht het gebeuren je zelf ook actie kunt ondernemen. Verder heeft het kunnen gebruiken van dit soort libraries juist heel veel voordelen zoals hierboven genoemd!

[ Voor 15% gewijzigd door jammo op 12-05-2022 11:45 ]

[dev10]

jammo schreef op donderdag 12 mei 2022 @ 11:36:

Doordat er steeds meer gebruik wordt gemaakt van libraries, ontwikkeld door derden, die gebuik maken van andere libraries ontwikkel door weer andere mensen (etc..) wordt het ook makkelijker om ergens in die tree van afhaneklijkeden iets te verstoppen wat niet zo snel opvalt.

Dat er steeds meer gebruik gemaakt wordt van libraries is juist ook weer een goede zaak omdat eventuele vulnerabilities altijd sneller gevonden dan een veiligheidslek in je zelfgeschreven code die door niemand anders gebruikt wordt.

Verder heb je tools die je dependency tree scannen en je een melding geven als er een vulnerability in een van je dependencies zit. Zie bijvoorbeeld https://github.com/dependabot. In het geval van Dependabot wordt er in GitHub een pull-request gemaakt als dit zonder problemen mogelijk is.

jammo schreef op donderdag 12 mei 2022 @ 11:36:
Recent is er toevallig een rust crate naar voren gekomen met een probleem:
https://blog.rust-lang.or...ate-rustdecimal.html?s=09
maar (helaas) zijn er zo legio voorbeelden waarbij code via via in je eigen code base terecht zou kunnen komen, zonder dat je er snel van op de hoogte bent.

Hierdoor zou dus een multisafepay api library (die je vertrouwd) toch kwaadwillende code kunnen bevatten omdat ook zei afhankelijk van van libraries van derden..

Het vervelende is dat software-ontwikkeling altijd ergens een basis van vertrouwen heeft. Vulnerabilities heb je in iedere laag waar je mee werkt, tot aan je hardware aan toe. Ergens moet je een keer een grens trekken en gewoon kiezen om een library te gebruiken in plaats van zelf het wiel uit te vinden.

[jammo]

Het vervelende is dat software-ontwikkeling altijd ergens een basis van vertrouwen heeft. Vulnerabilities heb je in iedere laag waar je mee werkt, tot aan je hardware aan toe. Ergens moet je een keer een grens trekken en gewoon kiezen om een library te gebruiken in plaats van zelf het wiel uit te vinden.

Ik denk niet dat ergens een basis van vertrouwen moeten hebben persee vervelend is
Verder, helemaal mee eens.
Mensen mogen echter wel bewust zijn dat het hebben van een publiekelijk toegankelijke repository ook problemen met zich mee kan nemen, maar dat is ook alles wat ik er mee zeg, blijft opletten met wat je gebruikt.
Ik zou er verder niet aan moeten denken dat ik alles zelf had moeten bouwen waarvoor ik nu externe libraries gebruik

[RobIII]

@powershift het is wel zo leuk als je ook zélf deelneemt aan je topic en dus reageert op de vragen en reacties die je gekregen hebt.

[Oon]

powershift schreef op woensdag 4 mei 2022 @ 17:16:
Daarom kon ik niet standaard een WooCommerce, Prestashop, Magento oid implementatie downloaden en installeren.

Hierbij ben ik al meteen geneigd om te stoppen met lezen. Prestashop is prima, Magento kan nog wel mee omdat veel klanten er expliciet om vragen, maar als er íéts bloated is dan is het wel WordPress icm WooCommerce.
WooCommerce is een van de hogere kwaliteit plugins op de markt (mag ook wel gezien de absurde prijs) maar maakt ook meteen je website 10x trager en doet alles op z'n eigen manier waardoor optimalisatie veel lastiger is dan nodig.

Het minste bloat dat je kan hebben is gewoon de bestaande library voor MSP, die is misschien meer dan een paar bytes maar doet z'n werk en ondersteunt alles dat nodig is.

Ja je kan het zelf in minder regels, maar dan zul je toch heel wat dingen die jouw klant op het moment niet nodig heeft maar MSP wel aanbiedt missen, en ben ik ook benieuwd naar je sanity checks op alle data die in zo'n library gedaan worden

[DJMaze]

powershift schreef op woensdag 4 mei 2022 @ 17:16:
Ben ik nu gek? Of mis ik een belangrijke reden hiervoor?

Werk dat je hebt aan alles zelf doen en beheren?
Pak een microframework, dependencies, etc. en je hebt minder werk. Voila!
Komt wel beetje werk bij, en dat is update beheer.

Ik werk aan een fork van een project en diegene heeft nooit updates gedaan sinds 2013.
Nu ik de updates van die dependencies wel doe, is de code base 3x zo groot.

De redenen zijn er in overvloed!
Neem bijvoorbeeld OpenPGP.js.
Die is enorm gegroeid omdat er gewoon veel meer encryptie algorithmes zijn dan in 2013.