Software-update: Laravel 10.0

Laravel is een opensource PHP-framework waarmee webapplicaties kunnen worden ontwikkeld. Achter Laravel staat een uitgebreide community en er is uitgebreide documentatie. Niet voor niets is het naast Symfony en Yii een van de populairste PHP-frameworks van dit moment. Versie 10.0 van Laravel is zojuist uitgekomen en uitgebreide releasenotes daarvan kunnen op deze pagina worden gevonden. Hieronder is de aankondiging voor deze uitgave te vinden.

Laravel 10 is Now Released!

Laravel 10 continues the improvements made in Laravel 9 by introducing argument and return types to all application skeleton methods, as well as all stub files used to generate classes throughout the framework. In addition, a new, developer-friendly abstraction layer has been introduced for starting and interacting with external processes. Further, Laravel Pennant has been introduced to provide a wonderful approach to managing your application's "feature flags". To get all of the juicy details about this release, check out our official release notes and upgrade guide.

Versienummer	10.0
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Laravel
Download	https://laravel.com/docs/10.x
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (17)

Het framework is fijn maar 46 aan elkaar gelinkte functie calls zijn ook niet alles om wat data uit een database te halen.
Als ouwe rot leest een gewone SQL query toch een stuk makkelijker.

Ik merk dat ik een beetje hetzelfde heb, gebruik laravel sinds versie 3, maar je geeft wel een stuk optimalisatie uithanden, daardoor viel ik nogal eens terug op normale SQL queries omdat de performance stukken beter was.

Binnen Laravel en Symfony heb je ook de keuze om Query te "builden", waardoor je ook handmatige queries zelf kan maken binnen een repository, dat daar eigenlijk ook voor bedoeld is.
Deze wordt bij de eerste keer uitvoeren, altens, als je het goed doet, ook gecached, waardoor die function calls niet meer nodig zijn, als er al een cache er van is, vooral bij productie configuraties behoort dat de standaard te zijn.

Je kunt altijd raw statements gebruiken, DB::statement() is er ook nog en niets houdt je tegen om direct met PDO spullen uit je database te halen Als je de gedraaide queries voor een request wil inzien, gebruik dan Telescope of de Debugbar van Barry vd. Heuvel.

Ik vind de query builder en Eloquent juist enorm krachtig, mede omdat je door middel van de relaties en scopes eenvoudig stukken SQL kunt hergebruiken.

Misschien gebruik je dan laravel niet optimaal..
De kracht zit juist in een correcte opbouw van eloquent, scopes,.. Waardoor er geen onnodige complexe sql query uitgevoerd wordt

Ik snap wel waar Bas vandaan komt. Soms is het gewoon handiger eg. kan het sneller zijn om een ruwe query of ieder geval de builder rechtstreeks aan te roepen in plaats van een join te leggen met eloquent. Daar krijg je voornamelijk pas mee te maken als je gigantische data sets gaat ophalen uit de database.

Eloquent is zo gebouwd als je een "join" doet ofwel een "belongsTo" ed dat hij 2 losse queries uitvoert i.p.v. 1 en in de programmatuur aan elkaar joint. Met hele grote datasets kan je dan behoorlijke overhead krijgen in load times.

Daarnaast als je met SQLServer werkt en de 2100 parameter binding limit kan af en toe ook flink voor wat irritatie zorgen.

Laravel zie ik juist meer als een toolbox in combinatie met Symfony.
Doctrine met entities vind ik toch even een stuk fijner.

Daarnaast, als je Laravel vergelijkt met Symfony, is Laravel een samenraapsel van een heleboel plugins en modules van veel verschillende developers, waar Symfony door 1 groep beheerd wordt. Hierdoor is Symfony meer geschikt voor stabiele projecten waar 1 partij verantwoordelijk is voor de releases, waar bij Laravel het een probleem zou kunnen vormen als een developer staakt met een plugin of module, waardoor er (naar mijn mening) mogelijk veiligheids problemen zouden kunnen ontstaan.

Maar goed, iedereen heeft zijn eigen voorkeuren, en Laravel is een soort van zwitserse zakmes, waar Symfony een zakmes is die alleen de brood nodige messen en tools bevat.
Wel tof om te zien dat ze al weer op versie 10 zitten

In de realiteit stel je in Symfony ook uiteindelijk dezelfde stabiele projecten elke keer weer samen, met eenzelfde implementatie waar jij zelf ervaring mee hebt en vind dat het een goede 'plugin' is.

Datzelfde geld met Laravel, alleen bolsteren zij by-default een bepaalde set van opinionated plugins mee, wat als gevolg heeft dat die plugins de desnodige 'exposure' hebben om actief maintained te blijven, en mocht dit niet gebeuren of een van die plugins toch de stekker er uit trekken, dan heb je 100% de vrijheid om voor alsnog de Symfony-approach te nemen en de Laravel-default implementatie (dmv. een "contract" / interface) uit te wisselen.

Zo is het bijvoorbeeld prima mogelijk om binnen Laravel lekker Doctrine te gebruiken, alleen is het default om Eloquent te gebruiken, en vinden de meeste developers dit prima waardoor dit geen populaire keuze is.

Het grote verschil is dus meer dat Symfony als een soort eigen-keuze bouwpakket wordt aangeleverd, waarbij je elke keer dat je iets nodig hebt, het bouwpakket eerst in elkaar moet zetten, wat zorgt voor een soort onrealistisch gevoel dat er meer "vrijheid" is in vergelijking tot Laravel, terwijl je bij Laravel het bouwpakket eigenlijk al in een bepaalde kleur pre-assembled aanlevert krijgt, een soort "omakase", waardoor je (IMO) sneller echt met je project van start kunt zonder verlies van flexibiliteit. Beide leiden tot min of meer hetzelfde resultaat.

[Reactie gewijzigd door Arckedo op 15 februari 2023 09:09]

Inderdaad! Het grote voordeel van Laravel vind ik dat je veel minder tijd kwijt bent aan de standaard dingen die een gemiddelde applicatie altijd nodig heeft. Laravel is "start-klaar". Officiele packages als Horizon, Telescope en Octane zijn echt van enorm toegevoegde waarde en werken super goed. Indien je een ander framework gebruikt, dan zul je dit soort dingen zelf bij elkaar moeten rapen of bouwen met alle gevolgen van dien.

Het is smaak, persoonlijk heb ik een voorkeur voor Laminas (voorheen Zend) met Doctrine. Maar met Laravel ben ik altijd sneller in staat om een proof of concept te bouwen.

Dus het komt ook neer op kiezen wat het beste bij de omstandigheden past.

Daarnaast, als je Laravel vergelijkt met Symfony, is Laravel een samenraapsel van een heleboel plugins en modules van veel verschillende developers, waar Symfony door 1 groep beheerd wordt. Hierdoor is Symfony meer geschikt voor stabiele projecten waar 1 partij verantwoordelijk is voor de releases, waar bij Laravel het een probleem zou kunnen vormen als een developer staakt met een plugin of module, waardoor er (naar mijn mening) mogelijk veiligheids problemen zouden kunnen ontstaan.

Je kan het theoretisch ook juist andersom zien: als die ene partij omvalt, valt je hele framework om En die ene partij kan doen wat het wil met het framework. Bijvoorbeeld zichzelf laten overnemen door MegaCorp die alleen maar geld willen zien.

Zeker, maar bedrijven willen liever niet afhankelijk zijn van vele kleine groepjes, en hebben liever support, welke Symfony kan aanbieden. Soort van Redhat vs Ubuntu verhaal. Bedrijven kiezen liever voor Redhat dan voor Ubuntu, puur en enkel vanwege een enterprise SLA support. Symfony heeft hier ook een optie voor, maar hier zie ik die niet bij Laravel, en dat kan een overwegende keuze zijn.

Ik zie enterprises niet zo snel iets met PHP doen. Daar is open source over het algemeen eng, want oeh oeh geen support. De "support" van Symfony is gewoon SensioLabs; te vergelijken met een bedrijf wat software voor je bouwt; oftewel niets meer of minder dan https://partners.laravel.com/

Ik heb bij veel bedrijven gewerkt als DevOps, Developer en Linux Engineering.
Ik kan je vertellen die insteek is niet waar, bedrijven die enterprise zijn, gebruiken weldegelijk PHP.
Python wordt hier ook veel gebruikt, GoLang en Rust zijn nog "eng".

Erg veelzijdig en fijn framework. Zeker een aanrader!

Hoera