[PHP] Welk (micro) framework moet ik kiezen?

[StephanVierkant]

Een tijdje geleden heb ik lang gezocht naar verschillende PHP-frameworks en hun voor- en nadelen. De keuze ging destijds o.a. tussen CodeIgniter, Zend Framework en Symfony, maar nu blijkt dat het veel te uitgebreide frameworks zijn voor mij. Het is behoorlijk overkill voor de meeste projecten en door (het gebrek aan) de complexiteit van de code levert het gebruik van deze frameworks vrijwel geen van de te verwachten voordelen (ontwikkeltijd, performance, etc.) op. Mijn zoektocht begint dus opnieuw, nu met aangepaste eisen.

Googlen naar 'php frameworks' leverde op het eerste oog mooie overzichten op, maar in mijn eerste zoektocht heb ik o.a. Slim Framework, Limonade en Silex gemist, die volgens mij veel meer geschikt zijn voor mijn gebruik. Ik ben dus eigenlijk op zoek naar een micro framework.

Nu ik weet dat mijn eerste zoektocht niet is geslaagd, wil ik niet een tweede keer aan dezelfde steen stoten. Ik wil me dus goed inlezen in de specifieke kenmerken en voor- en nadelen van verschillende micro frameworks, maar ik heb geen idee waar ik moet beginnen. Dit overzicht is een leuk beginnetje, maar het is slechts een lijst gesorteerd op populariteit op Github. Een vergelijking tussen een aantal populairste frameworks die ik vond, was zeer summier.

Ik ben dus op zoek naar ervaringen met verschillende micro frameworks en wat de beweegredenen waren/zijn om juist dit specifieke framework te gebruiken. Wat is de beste volgende stap in mijn zoektocht? Zijn er goede artikelen/websites die ik nog gemist heb of hebben jullie bepaalde ervaringen/inzichten die mij verder kunnen helpen?

[frickY]

Wat zoek je precies in een framework?

En in plaats van full blown Zend Framework of Symfony2 te gebruiken, kun je ook slechts die packages gebruiken die je wilt. Je hoeft niet perse ook hun MVC-model te implementeren met de daarbij behorende routering en alles er op en er aan.

[juggle]

Laravel is ook zeker de moeite waard en waarschijnlijk the next big thing in PHP land...

http://laravel.com/

[StephanVierkant]

frickY schreef op vrijdag 15 februari 2013 @ 21:45:
Wat zoek je precies in een framework?

Dat is wellicht de kern van de vraag. Ik ben daar nog niet helemaal achter, maar uitgangspunt is wel dat het heel erg lean en mean moet zijn. Het MVC-model gebruiken is voor mij inmiddels een must gebleken, mede omdat het gebruik van Twig me erg goed bevalt. De webapplicaties die ik bouw zijn niet erg complex en is ontwikkelsnelheid erg belangrijk: ik merk steeds vaker dat hergebruik van code veel tijd bespaart en ook de kwaliteit ten goede komt. Een van mijn webapplicaties ben ik nu aan het uitkleden: beetje bij beetje allerlei spaghetti-code omzetten in betere OOP-code en meer gebruik maken van libraries i.p.v. steeds opnieuw het wiel uitvinden.

juggle schreef op vrijdag 15 februari 2013 @ 23:19:
Laravel is ook zeker de moeite waard en waarschijnlijk the next big thing in PHP land...

http://laravel.com/

Afgezien van specifieke voorbeelden van frameworks (Laravel ziet er inderdaad veelbelovend uit), ben ik benieuwd naar concrete verschillen tussen frameworks: waarom kiest iemand Slim i.p.v. Silex of Symfony2 i.p.v. Zf2?

En in welk 'gat in de markt' is Laraval nu eigenlijk gesprongen? Met andere woorden: wat biedt Laraval dat nog niet werd aangeboden? In hun lijst met 'unique selling points' (http://laravel.com/docs/home#laravel-is-different) vind ik veel zaken terug die ook bij andere frameworks zijn te vinden. Er zijn ongetwijfeld verschillen, maar totaal 'different' kan ik niet noemen.

Ik kan me voorstellen dat de ondersteuning (wie zit er achter? hoe groot/actief is de community?), de kwaliteit van de documentatie, de performance, de schaalbaarheid e.d. allemaal van belang zijn, maar voor mij is het nog onvoldoende duidelijk waar ik op moet letten bij het kiezen van het juiste framework.

[ Voor 6% gewijzigd door StephanVierkant op 15-02-2013 23:51 ]

[IceM]

Zolang je niet weet waarnaar je opzoek bent is het lastig zoeken....

Alle 'grote' frameworks zullen 1 ding gemeen hebben: het kost tijd om het framework te leren voordat alle beloftes zoals een snellere ontwikkeltijd waar gemaakt worden.

[juggle]

Laravel wordt met name geprezen door de goede documentatie. Juist bij Laravel zien ze dat het documenteren van het framework zo belangrijk is.

Maar wat met name Laravel uniek maakt is het feit dat het geschreven is door een .NET ontwikkelaar die pas met PHP versie 5.3 php is gaan leren. Juist daardoor breekt hij door het paradigma waar veel framework ontwikkelaars last van hebben, tunnelvisie. Veel frameworks, zoals fuelphp, codeigniter, cakephp, yii, kohana zijn allemaal rond dezelfde principes gebouwd. Laravel daarentegen maakt gelijk goed gebruik van de nieuwe OOP functies die PHP 5.3 biedt: Namespaces, anonymous functions, late static binding.

Op moment van schrijven stappen veel grote jongens die significante rollen hebben gespeeld bij andere Frameworks zoals Code Igniter over op Laravel. Ik noem bijvoorbeeld een Phil Sturgeon (http://philsturgeon.co.uk/blog/2012/05/laravel-is-awesome). Of een Shawn McCool (heybigname.com/2012/05/06/why-codeigniter-is-dead/). Leuke rel ook tussen deze 2 developers op het laatst genoemde blog post.

Anyway, als je met Laravel werkt zul je snel de merken dat ontwikkelen leuk en makkelijk wordt en hoe geniaal sommige onderdelen van Laravel zijn. Ik noem een Fluent of Artisan.

Verdiep je er eens in, een framework kun je niet op basis van een paar blogpostjes selecteren. Een framework moet je gaan gebruiken zodat het onderdeel van je routine wordt.

[armageddon_2k1]

Het is nogal een persoonlijke mening natuurlijk, maar ik ben zeer gecharmeerd van Silex, omdat dat gebouwd is op de Symfony2 components en daarom extreem goed gedocumenteerd is. Laravel heb ik geen ervaring mee, maar hoor er goede dingen over, ik vind alleen de uitstraling een beetje 'arrogant', maar dat hoeft geen afbreuk te zijn aan de kwaliteit.

[StephanVierkant]

juggle schreef op zaterdag 16 februari 2013 @ 00:24:
Verdiep je er eens in, een framework kun je niet op basis van een paar blogpostjes selecteren. Een framework moet je gaan gebruiken zodat het onderdeel van je routine wordt.

Die opmerking is even logisch als onhaalbaar. Verdiepen in een framework is een tijdrovende bezigheid en je leert de voor- en nadelen pas kennen nadat je met meerdere systemen ervaring hebt opgedaan. Helaas is tijd een schaars goed en ben ik dus erg benieuwd naar ieders ervaringen. Zeker met mijn relatief beperkte kennis en ervaring is alle frameworks uitproberen geen optie. Een keuze baseren op een middagje stoeien lijkt me onvoldoende onderbouwing.

Het idee van een framework is dat je niet opnieuw het wiel uitvindt en dat zou ook moeten gelden voor de zoektocht er naar. Ik ga er van uit dat niet elke gebruiker een framework willekeurig kiest, maar subjectieve én objectieve argumenten voor heeft (of is dat te naïef?). Bij de aankoop van producten zoek ik ook eerst in de Pricewatch en lees ik vele reviews, benchmarks, vergelijkingen, etc. Helaas kan ik weinig (uitgebreide) reviews vinden over php frameworks. Zoek ik niet goed genoeg, of zijn er maar weinig mensen die genoeg ervaring hebben om een goed beeld te schetsen (en er moeite in steken om het te publiceren)?

armageddon_2k1 schreef op zaterdag 16 februari 2013 @ 11:53:
Het is nogal een persoonlijke mening natuurlijk, maar ik ben zeer gecharmeerd van Silex, omdat dat gebouwd is op de Symfony2 components en daarom extreem goed gedocumenteerd is. Laravel heb ik geen ervaring mee, maar hoor er goede dingen over, ik vind alleen de uitstraling een beetje 'arrogant', maar dat hoeft geen afbreuk te zijn aan de kwaliteit.

Ik denk dat ik ook kies voor Silex, om dezelfde reden: het is goed gedocumenteerd en het maakt een eventuele overstap naar Symfony2 (mochten mijn eisen en kennis groeien ;-)) volgens mij ook gemakkelijker.

Ik heb echter nog steeds het idee dat die keuze in grote mate willekeurig is en ik begin alweer te duizelen als ik kijk welke ORM's er allemaal zijn. Over een ORM heb ik nog niet nagedacht en daarbij geldt volgens mij in hoge mate hetzelfde probleem: een korte zoektocht levert vooral persoonlijke voorkeuren op.

[ Voor 36% gewijzigd door StephanVierkant op 16-02-2013 14:24 ]

[Barryvdh]

Ik ben ook voorstander van Laravel (en dan wel versie 4). Gebruikt voornamelijk de componenten van Symfony, maar biedt een iets makkelijkere 'API', zodat je wat sneller kan beginnen (makkelijker dan Symfony imho).
En daarnaast is versie 4 ook PSR0/1 en gebruikt composer, dus je kan heel makkelijk extra libraries gebruiken.
Er zitten veel dingen standaard in, zoals bijvoorbeeld componenten voor authenticatie, emailen, een (Active Record) ORM, templates (met Blade ipv Twig, maar Twig kan in principe ook), dus het is geen microframework. Het scheelt mij wel veel in ontwikkeltijd iig.
Als je echt een microframework wil, zou ik denk ik goed naar Silex kijken, is ook van de maker van Symfony en gebruikt veel van die componenten (en ook met Composer dus)

[pedorus]

Gezien de eisen die TS aan het framework stelt zou ik naar vanilla PHP kijken. Heel veel bedrijven zijn hier groot mee geworden, en gebruiken het nog. Er zijn vele bedrijven van Zend Framework (vanwege bijv. al die boilerplate-code en factories e.d.) overgestapt naar vanilla PHP. Vanilla PHP voldoet daarnaast aan alle eisen die in de TS worden gesteld. Ook werkt het perfect samen met Vanilla JS (http://vanilla-js.com/), maar ook met jQuery, of bijna ieder ander framework.

Vanilla PHP is overigens ook een stuk sneller dan bijvoorbeeld het hierboven genoemde Laravel. Daarnaast is de community van coders vele malen groter. Ook de code-omvang kan kleiner zijn, en duidelijker leesbaar. Voorbeeldje, rechtstreeks uit de docs van Laravel:

PHP:

<?php Section::start('scripts'); ?>
    <script src="jquery.js"></script>
<?php Section::stop(); ?>

PHP:

<head>
    <?php echo Section::yield('scripts'); ?>
</head>

Vanilla PHP:

HTML:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

PHP:

<head>
    <?php include 'scripts.php'; ?>
</head>

Niet alleen op de server, maar ook op de client werkt dit laatste een stuk sneller bij de eerste keer dat een nieuwe client de website bezoekt. Zo'n eerste bezoek kan cruciaal zijn voor het slagen van bijvoorbeeld een aankoop; met de code van Laravel ben je overduidelijk in het nadeel.

[StephanVierkant]

pedorus schreef op zaterdag 16 februari 2013 @ 13:36:
Gezien de eisen die TS aan het framework stelt zou ik naar vanilla PHP kijken. Heel veel bedrijven zijn hier groot mee geworden, en gebruiken het nog. Er zijn vele bedrijven van Zend Framework (vanwege bijv. al die boilerplate-code en factories e.d.) overgestapt naar vanilla PHP. Vanilla PHP voldoet daarnaast aan alle eisen die in de TS worden gesteld. Ook werkt het perfect samen met Vanilla JS (http://vanilla-js.com/), maar ook met jQuery, of bijna ieder ander framework.
(..)
Niet alleen op de server, maar ook op de client werkt dit laatste een stuk sneller bij de eerste keer dat een nieuwe client de website bezoekt. Zo'n eerste bezoek kan cruciaal zijn voor het slagen van bijvoorbeeld een aankoop; met de code van Laravel ben je overduidelijk in het nadeel.

Als je client side code afhankelijk is van je server side framework, heb je sowieso het verkeerde framework ;-)

Barryvdh schreef op zaterdag 16 februari 2013 @ 12:32:
Ik ben ook voorstander van Laravel (en dan wel versie 4). Gebruikt voornamelijk de componenten van Symfony, maar biedt een iets makkelijkere 'API', zodat je wat sneller kan beginnen (makkelijker dan Symfony imho).
En daarnaast is versie 4 ook PSR0/1 en gebruikt composer, dus je kan heel makkelijk extra libraries gebruiken.
Er zitten veel dingen standaard in, zoals bijvoorbeeld componenten voor authenticatie, emailen, een (Active Record) ORM, templates (met Blade ipv Twig, maar Twig kan in principe ook), dus het is geen microframework. Het scheelt mij wel veel in ontwikkeltijd iig.
Als je echt een microframework wil, zou ik denk ik goed naar Silex kijken, is ook van de maker van Symfony en gebruikt veel van die componenten (en ook met Composer dus)

Laravel is inderdaad goed eenvoudiger te leren dan Symfony2 en ZF2, maar dat geldt ook voor Slim en Silex. Silex is volgens mij een soort 'light' versie van Symfony2 en componenten aan je framework hangen is volgens mij de essentie van een framework. Het gebruik van Twig is bij alle genoemde frameworks in dit topic mogelijk: soms zelfs standaard ingebakken en anders is goed gedocumenteerd hoe je het kunt gebruiken. Ik vind je keuze voor Laravel of anders Silex goed te begrijpen, maar ik weet niet of de leercurve, de kwaliteit van documentatie en de beschikbaarheid van libraries/componenten de enige zaken zijn waar ik op moet letten.

Is er geen overzicht van alle frameworks, met reviews van gebruikers, benchmarks, etc.? Een soort Productreview voor frameworks?

[ Voor 24% gewijzigd door StephanVierkant op 16-02-2013 14:24 ]

[pedorus]

Stephan4kant schreef op zaterdag 16 februari 2013 @ 14:11:
Is er geen overzicht van alle frameworks, met reviews van gebruikers, benchmarks, etc.? Een soort Productreview voor frameworks?

Misschien dat je de overeenkomst nog niet gevonden hebt, maar je vraag toont erg veel overeenkomsten met Welke taal moet ik kiezen? Zonder dat je vertelt wat je wil maken, is dat niet echt te beantwoorden. Wil je bijvoorbeeld een CMS-achtige website, dan kan iemand zeggen dat je wellicht gewoon Wordpress kan gebruiken en eventueel wat plugins erbij kan schrijven. Zonder doel valt deze vraag niet te beantwoorden, en krijg je hooguit wat populaire frameworks te horen, en de meeste mensen hebben met niet heel veel frameworks (of zelfs met geen enkel framework) ervaring. Dus:

Voor wat voor soort dingen vindt je nu vaak "het wiel" opnieuw uit? Hoe groot is de kans dat iemand anders met welke achtergrond het snel moet kunnen onderhouden? Zijn er medewerkers die met templates moeten kunnen werken omdat code te tricky is? In welke setup moet het draaien? Zit er een database achter en zou ORM nuttig zijn? Is caching nodig? Dat soort vragen...

Vandaar mijn huidige advies voor vanilla PHP: meer micro dan dat gaat het niet worden, het werkt in elke situatie en PHP biedt van zichzelf al erg veel functionaliteit. (Dit forum is een mooi voorbeeld.)

[Barryvdh]

Ik denk ook dat het lastig is om te bepalen wat voor jou goed is. Stel inderdaad even wat eisen op en ga dan bekijken welke frameworks over blijven. Je zal toch een keer de knoop moeten doorhakken en beginnen.
Als je framework de PSR-0 standaard aanhoudt en gebruik maakt van Composer, moet je redelijk makkelijk alle algemene libraries kunnen gebruiken tegenwoordig.
Performance is wel wat lastiger te meten, want het ligt er ook aan wat je wil doen. En microframework (of plat php) zal allicht sneller zijn om een simpele pagina weer te geven, maar misschien ook minder flexibel. Zelf je queries schrijven is misschien sneller dan een ORM, maar kost weer meer tijd. Dus het is net de afweging van wat je belangrijker vindt.

[wackmaniac]

Met Barryvdh; Kijk wat jouw eisen zijn. Waarom wil je een framework, oftewel wat verwacht je dat het framework voor jou uit handen neemt? Afhankelijk daarvan kan je een framework of microframework kiezen. Als deze set met eisen klein is kan je er ook voor kiezen om zelf eenmalig een frameworkachtige constructie te fabricern, die je dan kan gebruiken voor je verdere projectjes.

Zelf heb ik ervaring met Zend (mij eigenlijk veel te uitgebreid, maar daardoor wel heel erg compleet), Lithium (compact, maar nog niet echt volwassen en documentatie laat te wensen) en Limonade (veel te micro). Uiteindelijk heb ik voor mezelf een lijstje gemaakt en zelf een stukje code gemaakt waar ik nu mijn projectjes op baseer.

Er zijn zo absurd veel frameworks dat je idd door de bomen soms het bos niet meer ziet. Ik zou je adviseren om of voor een full blown framework te gaan of zelf iets microframeworkachtigs te knutselen. Is ook een goede leerschool

[StephanVierkant]

Dank voor alle reacties, ik ben al een stukje wijzer! Gaandeweg kom ik er achter dat ik mijn vraag eigenlijk iets anders had moeten nuanceren: waar moet ik op letten bij het kiezen van een framework?

pedorus schreef op zaterdag 16 februari 2013 @ 14:59:
[...]

Misschien dat je de overeenkomst nog niet gevonden hebt, maar je vraag toont erg veel overeenkomsten met Welke taal moet ik kiezen? Zonder dat je vertelt wat je wil maken, is dat niet echt te beantwoorden. Wil je bijvoorbeeld een CMS-achtige website, dan kan iemand zeggen dat je wellicht gewoon Wordpress kan gebruiken en eventueel wat plugins erbij kan schrijven. Zonder doel valt deze vraag niet te beantwoorden, en krijg je hooguit wat populaire frameworks te horen, en de meeste mensen hebben met niet heel veel frameworks (of zelfs met geen enkel framework) ervaring.

Dat ben ik niet geheel met je eens: ook zonder het gebruik te weten kun je ergens over adviseren. De meeste reacties zijn nu subjectief en absoluut: ' ik vind framework A prettig werken.' Als je echter vraagt naar de keuze voor een mobiele telefoon, krijg je veel sneller 'Ik kies voor telefoon A omdat deze een langere accuduur (=objectief) heeft dan concurrerende modellen in dezelfde prijsklasse (=vergelijkend). Dat vind ik erg belangrijk omdat ik lang onderweg ben (=toelichting gebruik)'. Zo'n opmerking is objectief (accuduur is meetbaar) en doordat je weet wat de schrijver belangrijk vindt, kun je die eigenschap zwaarder of lichter wegen in je eigen eindoordeel.

Ik snap dat de subjectieve factor belangrijk is, maar de keuze voor een framework wordt verrassend weinig onderbouwd met vergelijkingen met andere frameworks (zie mijn vorige reactie: veel van de genoemde eigenschappen waren verre van specifiek), met objectieve gegevens (grootte community, performance, grootte van de 'clean install', systeemvereisten, beschikbaarheid libraries, etc.) of wordt toegelicht met persoonlijke ervaringen (Waar wordt het voor gebruikt en hoe bevalt dat? Wat waren alternatieven en waarom vielen ze af?).

Vandaar mijn huidige advies voor vanilla PHP: meer micro dan dat gaat het niet worden, het werkt in elke situatie en PHP biedt van zichzelf al erg veel functionaliteit. (Dit forum is een mooi voorbeeld.)

Volgens mij werkt Tweakers ook met Symfony: plan: Development-round-up - Iteratie #29

[ Voor 3% gewijzigd door StephanVierkant op 16-02-2013 21:35 ]

[pedorus]

Ah, maar de basis van dit forum is geen Symfony 2; dat is pas sinds 2011 in gebruik, en ik heb vermoedens dat Tweakers de React-code van het forum niet zo sterk heeft aangepast en het op andere delen wordt gebruikt. Zie plan: Development-round-up - iteratie #8 (en gelinkte discussie Standaard frameworks in PHP: wanneer wel en wanneer niet?).

[StephanVierkant]

pedorus schreef op zondag 17 februari 2013 @ 04:38:
Ah, maar de basis van dit forum is geen Symfony 2; dat is pas sinds 2011 in gebruik, en ik heb vermoedens dat Tweakers de React-code van het forum niet zo sterk heeft aangepast en het op andere delen wordt gebruikt. Zie plan: Development-round-up - iteratie #8 (en gelinkte discussie Standaard frameworks in PHP: wanneer wel en wanneer niet?).

De discussie over wel/niet een framework gebruiken vertoont inderdaad dezelfde retoriek: ik gebruik framework A dus dat is goed; jij gebruikt geen framework en hebt dus het Not invented here-syndroom. Het is een bitchfight tussen fanboys, in plaats van een helder onderscheid tussen (objectieve) feiten en persoonlijke omstandigheden of voorkeuren.

Toch kun je verschillende frameworks goed met elkaar vergelijken op veel punten:

• Hoe groot is de community erachter?
• Wat zijn unieke eigenschappen?
• Hoe groot is het aanbod aan (third party) libraries/bundles e.d.?
• Hoe uitgebreid/helder is de documentatie?
• Hoe eenvoudig of complex is het, met andere woorden: hoe is de leercurve?
• Biedt mijn favoriete IDE extra's?
• Welke keuzes worden gemaakt: hoe snel wordt bijv. ondersteuning oudere PHP-versies gestaakt?
• Hoe populair is het systeem? (relevant als je programmeurs wilt inhuren bijvoorbeeld: een Zend-programmeur is relatief snel gevonden)

Ligt het aan mij, of wordt deze discussie nauwelijks echt fundamenteel gevoerd? Bekijk een willekeurige review van een nieuwe telefoon en het barst van de vergelijkingen met de concurrentie (ondanks dat Android vs. iOS-discussies ook regelmatig worden gekaapt door fanboys ), maar een discussie over verschillende frameworks wordt afgedaan met 'hangt af van je gebruik'.

[crisp]

pedorus schreef op zondag 17 februari 2013 @ 04:38:
Ah, maar de basis van dit forum is geen Symfony 2; dat is pas sinds 2011 in gebruik, en ik heb vermoedens dat Tweakers de React-code van het forum niet zo sterk heeft aangepast en het op andere delen wordt gebruikt. Zie plan: Development-round-up - iteratie #8 (en gelinkte discussie Standaard frameworks in PHP: wanneer wel en wanneer niet?).

We hebben eerder delen van React vervangen door eigen componenten Maar vergeet niet dat React in feite ook een soort van framework is...

[StephanVierkant]

crisp schreef op zondag 17 februari 2013 @ 20:36:
[...]

We hebben eerder delen van React vervangen door eigen componenten Maar vergeet niet dat React in feite ook een soort van framework is...

Zo'n vermoeden had ik al: er is steeds minder van het 'oude' React terug te vinden door de betere integratie van het forum in de rest van de site. Ik kan me nog goed herinneren dat je voor beide een apart account had.

Ik las in verschillende .plans dat Tweakers Symfony gebruikt. Waarom is daar voor gekozen, en niet voor bijv. Zend, een eigen framework of gewoon vanilla?

[ZpAz]

Met vanilla moet je veel meer zelf regelen. Dan moet je weer een Routing systeem maken, een systeem wat bijvoorbeeld een MVC principe navolgt, een ORM of ander database-gerelateerd systeem, een caching systeem en andere dingen die je in elk project wel weer gebruikt.

Waarom dan niet een stukje code pakken wat dat al voor je doet en je je direct bezig kan houden met 'de applicatie' in plaats van dat opnieuw te schrijven? Als je dat al hebt heb je dus gewoon een 'in house framework' en dan is de vraag, waarom heb je het 'in house' geschreven? Kan jij het alleen beter dan de 100 developers die aan framework Y hebben geschreven (of framework X, Z & A?).

Daarnaast hoef je niet elke module te laden van een framework en de meesten laden tegenwoordig enkel wat je gebruikt.

Het voorbeeld van pedorus vind ik ook een beetje 'meh'. Ja je include is (waarschijnlijk minimaal sneller), maar als het om snelheid gaat heb je er waarschijnlijk al een caching systeem achter hangen en is het verschil na de eerste request nog kleiner, zo niet, afwezig.

Dit terwijl het framework systeem wel handiger is, zo kan je verder op in je code nog eens bepalen van: "O, voor deze pagina heb ik nog javsacript bestand 'x' nodig". en deze wordt dan gewoon in de header geplaatst dmv 2 step view of een andere pattern.

[armageddon_2k1]

Volgens mij was Pedorus een beetje sarcastisch met z'n voorbeeld post

[-DarkShadow-]

Keuze van een framework hangt vooral af van wat je al kan. Als je al een framework beheerst, kost het waarschijnlijk het minste tijd om je applicatie met dat framework te bouwen.

Stephan4kant schreef op zondag 17 februari 2013 @ 15:49:
Ligt het aan mij, of wordt deze discussie nauwelijks echt fundamenteel gevoerd? Bekijk een willekeurige review van een nieuwe telefoon en het barst van de vergelijkingen met de concurrentie (ondanks dat Android vs. iOS-discussies ook regelmatig worden gekaapt door fanboys ), maar een discussie over verschillende frameworks wordt afgedaan met 'hangt af van je gebruik'.

Ik denk dat deze discussie om enkele redenen niet interessant is:
- Welk framework het beste is, hang ook voornamelijk af van je gebruik
- Je leert een framework pas echt goed kennen als je er gebruik van maakt. De meeste ontwikkelaars kennen maar 1 framework echt goed, doordat een tweede framework onder de knie krijgen een flinke investering vergt.

[CyberJack]

Framework vs vanilla-php.
Mijn voorkeur gaat dan altijd uit naar een framework.

- Een framework zorgt vaak voor een zekere vorm van beveiliging.
Denk aan het goed escapen van database queries of het filteren van $_POST en $_GET waarden.
Iets wat je bij vanilla-php vaak zelf zal moeten doen.

- Het gebruik van een framework zorgt er voor dat een bepaalde structuur in je applicatie komt.
Een MVC framework zorgt er bijvoorbeeld voor dat je models, controllers en views losse onderdelen zijn.
Hierdoor is het terugvinden en aanpassen een stuk code is hierdoor veel makkelijker.
Het maken van een compleet andere layout kan dan vaak zonder aanpassingen aan je business logica.
Met vanilla-php is dit ook mogelijk maar vereist veel meer dicipline.
Maar of je nu een framework gebruikt of vanilla-php, het hebben van een goede structuur is noodzakelijk.

- Doorontwikkeling van een framework gebeurd vaak door een complete community.
Dit zorgt er voor dat bijvoorbeeld beveiligings issues vaak snel gepatched kunnen worden.
Door gebruikt te maken van een framework maak je eigenlijk gebruik van de kennis van misschien wel meer dan honderd personen. En die weten zeker meer dan 1 persoon die alles zelf doet in vanilla-php.

Buiten dat zorgt doorontwikkeling er ook voor dat je met je tijd mee gaat en een beetje gepushed wordt om je kennis up-to-date te houden. Want vaak kom je dingen in een framework tegen waarvan je misschien niet eens wist dat het met php kon.

En frameworks hebben in mijn ogen nog meer voordelen
- een caching engine
- meerdere omgevingen (production / development / testing)
- unittests (deze zijn vaak al aanwezig voor het framework en zijn makkelijk in te zetten voor je eigen componenten)
- documentatie
- een community voor vragen
Al deze dingen kan je natuurlijk ook wel in vanilla-php, maar kosten vaak meer tijd.

Dan heb je alleen nog de vraag "wat is het beste framework".
Ik denk dat dat van de klus af hangt. Je hebt klussen waar grote frameworks beter zijn, maar ook kleine klussen waar een microframework voldoet.

[Kajel]

armageddon_2k1 schreef op zaterdag 16 februari 2013 @ 11:53:
Het is nogal een persoonlijke mening natuurlijk, maar ik ben zeer gecharmeerd van Silex, omdat dat gebouwd is op de Symfony2 components en daarom extreem goed gedocumenteerd is. Laravel heb ik geen ervaring mee, maar hoor er goede dingen over, ik vind alleen de uitstraling een beetje 'arrogant', maar dat hoeft geen afbreuk te zijn aan de kwaliteit.

Ik kan hier alleen maar in mee gaan. Silex is naar mijn mening een uitstekend framework voor kleinere webapps, het opzetten van APIs, utility scripts (command line of niet) etc. Het is gebouwd op Symfony componenten (net als Laravel), maar heeft t.o.v. Laravel het grote voordeel dat het gebouwd is door Symfony-veteranen (waaronder de bedenken, Fabien Potencier), welke precies weten hoe deze componenten in elkaar steken en hoe ze ingezet kunnen worden binnen zo'n microframework. Het fijne is ook, dat je best makkelijk qua complexiteit/functionaliteit "op kunt schalen" richting Symfony. Zo wordt Twig standaard niet meegeleverd, maar heeft Silex wel out of the box ondersteuning voor Twig via een ServiceProvider. Dat laatste mechanisme leent zich overigens ook uitstekend om externe 3rd party libraries in te zetten volgens de Silex methodiek.

Ik gebruik Silex heel veel voor het bouwen van prototypes, en geniet elke keer weer van de ontwikkelsnelheid. Ik ga daarbij meestal uit van een Composer bestand van een bestaand project van mezelf, en zet daarmee binnen minuten een raamwerk op voor iets nieuws. De grap is overigens, dat het vaak begint met prototypen in Silex, maar voor niet al te grote projecten (en dat kun je behoorlijk ver rekken) ook in productie gewoon Silex ingezet wordt.

[StephanVierkant]

-DarkShadow- schreef op dinsdag 19 februari 2013 @ 11:50:
Ik denk dat deze discussie om enkele redenen niet interessant is:
- Welk framework het beste is, hang ook voornamelijk af van je gebruik

Dat vind ik niet echt een logische reden. Ook de meest geschikt telefoon, auto, etc. hangt af van je gebruik. Toch worden in reviews over bijv. telefoons veel met elkaar vergeleken. Zowel vergelijkbare modellen ('deze is sneller/groter dan anderen in dezelfde prijsklasse') als minder goed vergelijkbare modellen ('als je dit wilt, zul je toch echt een duurdere moeten nemen).

- Je leert een framework pas echt goed kennen als je er gebruik van maakt. De meeste ontwikkelaars kennen maar 1 framework echt goed, doordat een tweede framework onder de knie krijgen een flinke investering vergt.

Dit lijkt me de enige plausibele reden. Ik zal me er bij neer moeten leggen

[ Voor 9% gewijzigd door StephanVierkant op 19-02-2013 17:32 ]

[Anoniem: 241683]

Stephan4kant schreef op dinsdag 19 februari 2013 @ 17:32:
[...]

Dat vind ik niet echt een logische reden. Ook de meest geschikt telefoon, auto, etc. hangt af van je gebruik. Toch worden in reviews over bijv. telefoons veel met elkaar vergeleken. Zowel vergelijkbare modellen ('deze is sneller/groter dan anderen in dezelfde prijsklasse') als minder goed vergelijkbare modellen ('als je dit wilt, zul je toch echt een duurdere moeten nemen).

[...]

Dit lijkt me de enige plausibele reden. Ik zal me er bij neer moeten leggen

Ik heb uiteindelijk de keuze gemaakt voor Symfony. Niet direct omdat ik alle andere frameworks heb getest, maar omdat ik hier mij het meeste thuis voelde. Het is ook een kwestie van smaak. Laraval lijkt wel aan elkaar geplakt met static's. Ik vind dit behoorlijk lelijk en dat geeft voor mij minder programmeerplezier

Het is uiteindelijk dus een persoonlijke keuze.

Daarnaast zul je tussen de grote frameworks niet veel verschil vinden tussen continuïteit, stabiliteit en performance. Het enige verschil is vaak de leercurve en het programmeer-plezier

[ Voor 8% gewijzigd door Anoniem: 241683 op 19-02-2013 20:28 ]

[Barryvdh]

Anoniem: 241683 schreef op dinsdag 19 februari 2013 @ 20:16:
[...]


Ik heb uiteindelijk de keuze gemaakt voor Symfony. Niet direct omdat ik alle andere frameworks heb getest, maar omdat ik hier mij het meeste thuis voelde. Het is ook een kwestie van smaak. Laraval lijkt wel aan elkaar geplakt met static's. Ik vind dit behoorlijk lelijk en dat geeft voor mij minder programmeerplezier

Het is uiteindelijk dus een persoonlijke keuze.

Daarnaast zul je tussen de grote frameworks niet veel verschil vinden tussen continuïteit, stabiliteit en performance. Het enige verschil is vaak de leercurve en het programmeer-plezier

Nouja, Laravel 4 gebruikt geen statics maar Facades om in de achtergrond de echte class uit de DI container op te vragen. (Laravel 3 wel nog)

Het fijne aan Laravel vind ik dat je er makkelijk mee kan beginnen zonder precies te weten hoe de Symfony componenten werken. Met Symfony kan je waarschijnlijk wel alles, maar het kan er toch een beetje complex uit zien als je er mee moet beginnen. In Laravel worden veel zaken in de achtergrond geregeld, zodat je een wat simpelere interface hebt. Je hebt dan in no-time wat routes, controllers en modellen gemaakt die gewoon werken (maar wel met de kracht van Symfony).
En omdat het zich netjes aan de PSR0/1 standaarden houdt, kan je meestal gewoon je composer file aanpassen en de library meteen gebruiken.
In de paar maanden dat ik er nu mee werk, verbaas ik me iig nog steeds over de mogelijkheden, hoe simpel sommige zaken zijn, zeker met wat externe libraries/tools voor Laravel erbij.

Enige nadeel is wel dat het voornamelijk door 1 persoon ontwikkeld wordt (Taylor Otwell) en dat het nog niet echt een stabiele API heeft (Laravel 4 breekt nu best veel uit Laravel 3, maar dat komt voornamelijk ook door de omschakeling naar de PSR-0/1 standaarden, composer en van statics naar facades, dus dat zijn imho wel goede beslissingen). Hopelijk komt er binnenkort wel een versie die long time support krijgt.

Snelheid durf ik niet zoveel over te zeggen en ik kan ook weinig benchmarks vinden voor een vergelijking met andere frameworks. Wel zit er support in voor verschillende cache-mechanismen, dus daar kan je al veel op besparen (en bijv. eager loading in het ORM)

Ik merk overigens wel dat ik meer plezier erin krijg, omdat het veel van het 'saaie'/'domme' werk uit handen neemt, vooral ook door het Eloquent ORM.

[ Voor 3% gewijzigd door Barryvdh op 19-02-2013 23:46 ]

[Anoniem: 241683]

Barryvdh schreef op dinsdag 19 februari 2013 @ 23:44:
[...]

Nouja, Laravel 4 gebruikt geen statics maar Facades om in de achtergrond de echte class uit de DI container op te vragen. (Laravel 3 wel nog)

Het fijne aan Laravel vind ik dat je er makkelijk mee kan beginnen zonder precies te weten hoe de Symfony componenten werken. Met Symfony kan je waarschijnlijk wel alles, maar het kan er toch een beetje complex uit zien als je er mee moet beginnen. In Laravel worden veel zaken in de achtergrond geregeld, zodat je een wat simpelere interface hebt. Je hebt dan in no-time wat routes, controllers en modellen gemaakt die gewoon werken (maar wel met de kracht van Symfony).
En omdat het zich netjes aan de PSR0/1 standaarden houdt, kan je meestal gewoon je composer file aanpassen en de library meteen gebruiken.
In de paar maanden dat ik er nu mee werk, verbaas ik me iig nog steeds over de mogelijkheden, hoe simpel sommige zaken zijn, zeker met wat externe libraries/tools voor Laravel erbij.

Enige nadeel is wel dat het voornamelijk door 1 persoon ontwikkeld wordt (Taylor Otwell) en dat het nog niet echt een stabiele API heeft (Laravel 4 breekt nu best veel uit Laravel 3, maar dat komt voornamelijk ook door de omschakeling naar de PSR-0/1 standaarden, composer en van statics naar facades, dus dat zijn imho wel goede beslissingen). Hopelijk komt er binnenkort wel een versie die long time support krijgt.

Snelheid durf ik niet zoveel over te zeggen en ik kan ook weinig benchmarks vinden voor een vergelijking met andere frameworks. Wel zit er support in voor verschillende cache-mechanismen, dus daar kan je al veel op besparen (en bijv. eager loading in het ORM)

Ik merk overigens wel dat ik meer plezier erin krijg, omdat het veel van het 'saaie'/'domme' werk uit handen neemt, vooral ook door het Eloquent ORM.

Ja ik snap dat ze niet een directe static class gebruiken . Ik vind het alleen wat minder elegant. Alsnog zal het een mooi framework zijn, maar zoals ik zei: Het is ook vooral smaak. Zowieso is het gebruik van statics(niet facades) idd een goed iets om in te wisselen.

Snelheid zal denk ik niet echt veel verschillen. Beide frameworks lijken best modulair. Symfony is ook snel traag te krijgen als je maar genoeg services en extensions voor twig inlaad .

Datzelfde heb ik inderdaad ook. Ben alleen nog erg voorzichtig met het gebruik van ORM voor applicaties. Zit vaak tegen performance aan te hikken. En APC is niet op alle servers te installeren.

[armageddon_2k1]

Barryvdh schreef op dinsdag 19 februari 2013 @ 23:44:
[...]

Nouja, Laravel 4 gebruikt geen statics maar Facades om in de achtergrond de echte class uit de DI container op te vragen. (Laravel 3 wel nog)

Het waarom daarvan ontgaat me een beetje. Wat is het voordeel daarvan?

De nadelen die je aandraagt zijn echt killing voor Laravel om serieus genomen te worden in een professionele omgeving.

[ Voor 15% gewijzigd door armageddon_2k1 op 20-02-2013 07:31 ]

[kwaakvaak_v2]

Stephan4kant schreef op dinsdag 19 februari 2013 @ 17:32:
[...]

Dat vind ik niet echt een logische reden. Ook de meest geschikt telefoon, auto, etc. hangt af van je gebruik. Toch worden in reviews over bijv. telefoons veel met elkaar vergeleken. Zowel vergelijkbare modellen ('deze is sneller/groter dan anderen in dezelfde prijsklasse') als minder goed vergelijkbare modellen ('als je dit wilt, zul je toch echt een duurdere moeten nemen).

[...]

Dit lijkt me de enige plausibele reden. Ik zal me er bij neer moeten leggen

Ik krijg heel sterk het gevoel ben dat je opzoek bent naar de heilige graal.. Maar goed laat ik je spelletje eens meespelen.

Hoe had je gedacht een benchmark te doen? Bootstrap + een render 'hello world' ofzo? Dat zegt niets over de snelheid van bijvoorbeeld een ORM. En dan nog, een ORM wat native PDO objecten uitspuugt is iets anders dan een ORM dat hydradeert naar arrays of wat dan ook.

En benchmark je dan met of zonder caching?

Want als een app of site succesvol wordt, zijn er veel boeiendere manieren om de perfomance omhoog te krijgen dan de keuze van een framework. Dingen als caching met varnish (al dan niet met ESI), Horizontale schaalbaarheid over meerdere node's etc. etc.

Kortom.. Darkshadow zijn comment snijdt het meeste hout in deze. De keuze van een framework voor eigen gebruik is een persoonlijke keuze. De keuze van een framework in een zakelijke omgeving kent meerdere factoren, waarbij snelheid niet eens de meest belangrijke is. Maar een keuze zoals Fabian recent gedaan heeft met Security en Symfony2 veel zwaarder kan wegen als de oplossing die je er mee maakt langer mee moet dan een paar dagen.

Barryvdh schreef op dinsdag 19 februari 2013 @ 23:44:
[...]

Enige nadeel is wel dat het voornamelijk door 1 persoon ontwikkeld wordt (Taylor Otwell) en dat het nog niet echt een stabiele API heeft (Laravel 4 breekt nu best veel uit Laravel 3, maar dat komt voornamelijk ook door de omschakeling naar de PSR-0/1 standaarden, composer en van statics naar facades, dus dat zijn imho wel goede beslissingen). Hopelijk komt er binnenkort wel een versie die long time support krijgt
Nouja, Laravel 4 gebruikt geen statics maar Facades om in de achtergrond de echte class uit de DI container op te vragen. (Laravel 3 wel nog)

Dat was voor mij de hoofdreden om het hier op de zaak het direct van de shortlist te halen. Het ecosysteem is veel te zwaar onderhevig aan de grillen van Taylor. Als hij morgen weer iets nieuws bedenkt, start ie gelijk met laravel 5 en vergeet ie dat ie ooit met 4 bezig was. Leuk voor hobby projecten, maar ik kan hier intern niet verkopen dat het framework wat wij kiezen om apps mee te maken die een jaar of 2 moeten staan morgen ineens absolete kan zijn. Dat en die statics die met reflection de 'echte' code compileren. Te ondoorzichtig voor mij. Ik wil graag de code terug kunnen tracen in mijn IDE. Misschien dat het door zijn .net achtergrond komt, waar het redelijk normaal schijnt te zijn dat je geen idee hebt wat er precies onderwater gebeurt. Maar het voelde voor mij als een te grote zwarte magische doos waar maar een handje vol mensen de geheime handshake kennen.

[ Voor 30% gewijzigd door kwaakvaak_v2 op 20-02-2013 09:37 . Reden: extra stukse over laravel. ]

[Barryvdh]

armageddon_2k1 schreef op woensdag 20 februari 2013 @ 07:30:
[...]
Het waarom daarvan ontgaat me een beetje. Wat is het voordeel daarvan?

De nadelen die je aandraagt zijn echt killing voor Laravel om serieus genomen te worden in een professionele omgeving.

Van Facades? Omdat de interface wat cleaner/simpeler is, maar dat is waarschijnlijk ook een kwestie v an smaak. Dus in plaats van:

code:

$app['session']->get('foo');

krijg je

code:

Session::get('foo')

Qua stabiliteit heb je natuurlijk wel gelijk, maar je moet ergens beginnen en pas zodra je tevreden bent kan je de API vastzetten. (Hopelijk komt dat ook als Symfony2 zijn LTS versie uitbrengt)

[kwaakvaak_v2]

Barryvdh schreef op woensdag 20 februari 2013 @ 09:54:
[...]

Van Facades? Omdat de interface wat cleaner/simpeler is, maar dat is waarschijnlijk ook een kwestie v an smaak. Dus in plaats van:

code:

$app['session']->get('foo');

krijg je

code:

Session::get('foo')

Qua stabiliteit heb je natuurlijk wel gelijk, maar je moet ergens beginnen en pas zodra je tevreden bent kan je de API vastzetten. (Hopelijk komt dat ook als Symfony2 zijn LTS versie uitbrengt)

Die eerste is silex en die tweede is laravel's eigen intepretatie van een facade die eigenlijk niet meer is dan een fancy wrapper om die eerste functie heen omwille van de korte notatie.

Als je in elke controller de session nodig hebt, en je houdt niet van typen kun je die ook injecteren in je base controller en elke andere controller daarvan afleiden.

Dan kun je gewoon

code:

$this->session->get('foo')

gebruiken. Of als je foo altjd nodig hebt gewoon foo in je class injecteren en lekker

code:

$this->foo

gebruiken. Waarbij het voor je IDE nog altijd makkelijk is om direct naar de declaratie van foo te springen omdat het niet door een wrapper functie wordt opgehaald.

[Janoz]

Nou, dit lijken mij nu juist niet de dingen waarvoor je een framework zou willen gebruiken

cyberjack77 schreef op dinsdag 19 februari 2013 @ 12:16:
- Een framework zorgt vaak voor een zekere vorm van beveiliging.
Denk aan het goed escapen van database queries of het filteren van $_POST en $_GET waarden.
Iets wat je bij vanilla-php vaak zelf zal moeten doen.

Juist escapen van POST en/of GET zul je nooit moeten doen. Escapen is context afhankelijk en de manier van escapen is pas duidelijk op de plek waar je je parameters daadwerkelijk gebruikt. Ook filteren lijtk me typisch iets waarvan jijzelf bepaald wat gefilterd moet worden en wat niet. Voor queries zijn er prepared statements. Daar heb je niet een heel framework voor nodig (of gebruik je een specifiek framework voor zoals een ORM mapper)

- Het gebruik van een framework zorgt er voor dat een bepaalde structuur in je applicatie komt.

Discipline om te zorgen dat je structuur in je applicatie houd is een skill die iedere software ontwikkelaar zou moeten beschikken. Een code standaard zou en eventueel een architectuur document zou genoeg moeten zijn om de boel in lijn te houden.

- Doorontwikkeling van een framework gebeurd vaak door een complete community.

Maar wie zegt dat ze door ontwikkelen aan de features die jij gebruikt? Wie zegt dat dit niet een enorm vals gevoel van veiligheid geeft omdat 'het framework ons wel beschermt'?

Ja, het is goed om niet het wiel opnieuw uit te vinden en gebruik te maken van beschikbare on goed onderhouden frameworks. Maar waarom die dingen binnenfietsen terwijl je misschien maar 0.1% van de functionaliteit gebruikt? Het zorgt er alleen maar voor dat die andere 99.9% juist extra risico's opleveren.

En frameworks hebben in mijn ogen nog meer voordelen
- een caching engine
- meerdere omgevingen (production / development / testing)
- unittests (deze zijn vaak al aanwezig voor het framework en zijn makkelijk in te zetten voor je eigen componenten)
- documentatie
- een community voor vragen
Al deze dingen kan je natuurlijk ook wel in vanilla-php, maar kosten vaak meer tijd.

De eerste 3 dingen lijken me niet enkel voorbehouden aan frameworks. En voor de laatste twee is er geen onderscheid tussen een framework en vanilla php.


Maar goed. Dit alles getikt hebben krijg ik een beetje het idee dat er een babilonische spraakverwarring heerst. Ikzelf ben Java ontwikkelaar. In mijn werk gebruik ik enorm veel al beschikbare (open source) code. Dit zijn echter geen frameworks, maar libraries. Een library die specifiek gericht is op het logging. Een library die specifiek gericht is het maken van Unittests. Een andere library voor het maken van mocks voor die unittest. Een library voor ORM. Een library voor het renderen van de userinterface. Gelukkig bestaat er voor java fatsoenlijke dependency management waardoor ik in een configuratie bestandje alleen maar aan hoef te geven welke libs ik wil gebruiken en welke versie ik daarvan wil hebben. Het build proces (en mijn IDE) zorgt vervolgens dat alles netjes zonder conflicten binnen gehaald wordt.

Al die libraries hebben specifieke verantwoordelijkheid en ik gebruik ze omdat ik graag wil dat dat stuk mij uit handen genomen wordt.

Bij al die PHP frameworks heb ik een hoog 'zwitsers zakmes' gehalte. Ze kunnen alles, maar om je biefstukje te snijden kun je beter een vork en een mes pakken.

[mithras]

Stephan4kant schreef op vrijdag 15 februari 2013 @ 23:50:
[...]

Dat is wellicht de kern van de vraag. Ik ben daar nog niet helemaal achter, maar uitgangspunt is wel dat het heel erg lean en mean moet zijn.

Ik denk dat je dit eerst helder moet krijgen Elk type framework (los van frameworks zelf) zijn geschikt voor andere applicaties, groeimogelijkheden, performance etc. Beschrijf eerst wat je er mee wilt, dan kan je een goede keuze maken.

Het MVC-model gebruiken is voor mij inmiddels een must gebleken, mede omdat het gebruik van Twig me erg goed bevalt.

MVC met micro frameworks is lastiger dan een groter enterprise framework. In Symfony2, ZF2 heb je een veeluitgebreidere MVC structuur, in bijvoorbeeld Silex moet je dit bijna zelf opzetten.

De webapplicaties die ik bouw zijn niet erg complex en is ontwikkelsnelheid erg belangrijk: ik merk steeds vaker dat hergebruik van code veel tijd bespaart en ook de kwaliteit ten goede komt. Een van mijn webapplicaties ben ik nu aan het uitkleden: beetje bij beetje allerlei spaghetti-code omzetten in betere OOP-code en meer gebruik maken van libraries i.p.v. steeds opnieuw het wiel uitvinden.

Ik kan net zo snel in ZF2 iets opbouwen als met Silex, als je de code maar kent. Ontwikkelsnelheid is niet echt een argument voor keuze van framework, wat mij betreft.

Echter, complexiteit natuurlijk wel. Een leercurve is anders bij elk framework. Als je dat belangrijk vindt, kijk vooral naar de kleinere frameworks. Wil je echter meer DRY toepassen, herbruikbare code schrijven: blijf eerder weg van de micro's, die helpen je niet zo makkelijk daarbij. Symfony2 en nog sterker, ZF2, helpen je hier juist wel heel erg bij. Ze hebben goed de bekende patterns toegepast wat echt helpt bij de ontwikkeling.

Afgezien van specifieke voorbeelden van frameworks (Laravel ziet er inderdaad veelbelovend uit), ben ik benieuwd naar concrete verschillen tussen frameworks: waarom kiest iemand Slim i.p.v. Silex of Symfony2 i.p.v. Zf2?

De app die je wilt bouwen. Je kan micro's heel makkelijk gebruiken voor APIs of prototypes. Tegenwoordig kom je ook andere apps tegen in micro's, maar het blijft vooral bij een (REST) api van een klein aantal resources of een klein prototype. Wil je groter, schaalbaarder, complexer (qua app dan) werken, ga je eerder kijken naar Symfony of ZF2.

Voorbeelden die je makkelijker kan integreren in de grotere frameworks: authenticatie (logins), authorisatie (permissies), caching, navigatiestructuren, form builders, integratie met bijv. Doctrine.

En in welk 'gat in de markt' is Laraval nu eigenlijk gesprongen? Met andere woorden: wat biedt Laraval dat nog niet werd aangeboden? In hun lijst met 'unique selling points' (http://laravel.com/docs/home#laravel-is-different) vind ik veel zaken terug die ook bij andere frameworks zijn te vinden. Er zijn ongetwijfeld verschillen, maar totaal 'different' kan ik niet noemen.

Ze springen in een "gevoelsgat". Ze roepen dat losgekoppelde onderdelen veel beter zijn, dat Symfony2 en ZF2 te "groot" zijn. Volgens mij is het inhoudelijk nu niet echt iets waard. Ik gebruik liever een DRY framework waar in ZF2 veel componenten de stdlib, service manager en/of event manager components gebruiken. Dat liever dan elke component een eigen implementatie.

Ik kan me voorstellen dat de ondersteuning (wie zit er achter? hoe groot/actief is de community?), de kwaliteit van de documentatie, de performance, de schaalbaarheid e.d. allemaal van belang zijn, maar voor mij is het nog onvoldoende duidelijk waar ik op moet letten bij het kiezen van het juiste framework.

Het is ook niet erg eens te wisselen. Gewoon verschillende dingen uitproberen, kijken hoe eea gaat. Dat zorgt dat je weet wat je zelf belangrijk vind.

[kwaakvaak_v2]

Janoz schreef op woensdag 20 februari 2013 @ 10:49:
Nou, dit lijken mij nu juist niet de dingen waarvoor je een framework zou willen gebruiken

Al die libraries hebben specifieke verantwoordelijkheid en ik gebruik ze omdat ik graag wil dat dat stuk mij uit handen genomen wordt.

Bij al die PHP frameworks heb ik een hoog 'zwitsers zakmes' gehalte. Ze kunnen alles, maar om je biefstukje te snijden kun je beter een vork en een mes pakken.

Dat hangt er idd puur vanaf hoe je het benaderd, ik zie framework in php ook meer als een verzameling op elkaar afgestemde libraries die DRY voor mij makkelijker maken. Maar het neemt idd niet weg dat je nog steeds zelf moet bedenken hoe je bepaalde dingen wilt doen, zoals idd escaping en filtering. Dat is context afhankelijk. En dat is juist waar ze bij Symfony2 redelijk goed over nagedacht hebben. Ze filteren het niet voor je, ze transposen de inhoud van het HTTP request naar een container waar je filters op los kunt laten. Het basis idee hierachter is eigenlijk binnen webdevelopment logisch. Elk request MOET een response opleveren. En response moet je in de breedste zin zien. Immers enkel een 304 terug sturen is ook een response.

En voor de rest kun je het 'framework' aan kleden met de libraries die je nodig hebt en dat hoeven niet noodzakelijk bundles in de symfony2 structuur te zijn als je als basis symfony2 without vendors pakt. Of als het echt 'simpel' moet silex. Alhoewel ik de meerwaarde daarvan niet echt zie t.o.v een kale symfony2.

Dat zwitsers zakmes gevoel krijg ik zelf meer bij frameworks als Zend, Codeigniter,Cake, Laravel etc. Ze moeten alles kunnen en het liefst ook nog koffie zetten voor je. Maar dan wel koffie volgens een vooraf bepaalde methode en structuur. Prima als je bepaalde eenduidigheid in een organisatie met meerdere developers wilt afdwingen. Wat helaas soms ook nodig is gezien het 'eigenwijze' karakter wat de meeste developers hebben.

Kies gewoon de juiste tool voor de juiste taak, alleen zorg er voor dat je in team verband niet 30 tools door elkaar gebruikt, want dat maakt het overnemen van elkaars projecten mocht dat nodig zijn nodeloos complex.

[pedorus]

ZpAz schreef op dinsdag 19 februari 2013 @ 09:45:
Het voorbeeld van pedorus vind ik ook een beetje 'meh'. Ja je include is (waarschijnlijk minimaal sneller), maar als het om snelheid gaat heb je er waarschijnlijk al een caching systeem achter hangen en is het verschil na de eerste request nog kleiner, zo niet, afwezig.

Ik denk dat je inderdaad het sarcasme hebt gemist. Ik ken Laravel niet, maar ik viel gewoon over een domme include van jquery. In ieder geval lijken mij die voorbeelden niet echt hetzelfde. Import werkt meestal omgekeerd van een template-systeem, of je moet meerdere bestanden per pagina gaan maken.. Als je daadwerkelijk een template-systeem nodig hebt, dan kun je natuurlijk beter een bestaand systeem pakken, in plaats van dat je zelf iets nieuws maakt. Maar niet alle php-software heeft een template-systeem of volledig framework nodig.

cyberjack77 schreef op dinsdag 19 februari 2013 @ 12:16:
Een MVC framework zorgt er bijvoorbeeld voor dat je models, controllers en views losse onderdelen zijn.
Hierdoor is het terugvinden en aanpassen een stuk code is hierdoor veel makkelijker.

Lang niet altijd. Je zal zien dat een wijziging, bijvoorbeeld wie mag wat zien met welke meldingen, nu in zowel Model, View, als Controller moet worden doorgevoerd. De code van deze uitbreiding staat nu verspreid op 3 plekken (of 4 of nog meer in sommige gevallen). Of dat zich terug uitbetaald voor sommige projecten (zoals het doet bij een alternatieve layout), is maar zeer de vraag. Zeker als de leercurve van zo'n framework nog doorlopen moet worden.

Als je nou hergebruik en aanpassen van hergebruikte code had genoemd

Dit zorgt er voor dat bijvoorbeeld beveiligings issues vaak snel gepatched kunnen worden.

Hoe leg je een nadeel uit als voordeel? (Zie Ruby on Rails en DigiD bijvoorbeeld...)
En verder zie Janoz. Dan laat ik de rant over tijd kostende unit tests, en over assumpties met kostbare meerdere omgevingen achterwege.

Janoz schreef op woensdag 20 februari 2013 @ 10:49:
Ikzelf ben Java ontwikkelaar. In mijn werk gebruik ik enorm veel al beschikbare (open source) code. Dit zijn echter geen frameworks, maar libraries.

Vreemd. Laatst was ik bezig met JSF en JPA, en die noem ik toch echt frameworks (en Wikipedia ook). Ik vraag me af welke technologie dan wel wordt gebruikt (en Maven(?) lijkt me ook niet erg magisch). In het kader van dit draadje is ook Wikipedia: Web application framework interessant, en het lijstje uit de TS heeft juist opvallend veel Java-frameworks. De snelle leercurve en setup-tijd van vanilla PHP blijft echter onovertroffen natuurlijk

Het is natuurlijk wel zo dat een "micro"framework al snel een library wordt.