Software-update: Laravel 10.0

Laravel logo (75 pix) 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.)

Door Bart van Klaveren

Downloads en Best Buy Guide

14-02-2023 • 20:06

17 Linkedin

Submitter: Lucas

Bron: Laravel

Update-historie

14-02 Laravel 10.0 17
02-'22 Laravel 9.0 12
03-'20 Laravel 7.0 13
09-'19 Laravel 6.0 3
02-'19 Laravel 5.8 3
08-'17 Laravel 5.5 29
01-'17 Laravel 5.4 24
Meer historie

Reacties (17)

17
17
9
0
0
6
Wijzig sortering
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!

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee