Laravel 9(laravel-news.com)
laravel-news.com
Laravel 9
https://laravel-news.com/laravel-9-released
261 comments
> As a solo bootstrapped SaaS founder that literally relies on my app to pay my rent and food, I owe my sanity to Laravel
I’m in the same boat as you, and I couldn’t agree more. Your comment absolutely nails it.
Laravel is a pleasure to work with. It takes care of 95% of everything I could ever need from a framework. And that last 5% is guaranteed to be covered by a high-quality community package. (Just look at Spatie, this is all just from one maintainer! https://spatie.be/open-source )
Some commenters in this thread seem to take issue with Laravel’s “artisan” approach… and yeah, sure. Maybe it’s a bit pretentious. But, whatever. They’ve earned it. Laravel, its ecosystem and community takes pride in being polished and professional — and rightly so.
I’m in the same boat as you, and I couldn’t agree more. Your comment absolutely nails it.
Laravel is a pleasure to work with. It takes care of 95% of everything I could ever need from a framework. And that last 5% is guaranteed to be covered by a high-quality community package. (Just look at Spatie, this is all just from one maintainer! https://spatie.be/open-source )
Some commenters in this thread seem to take issue with Laravel’s “artisan” approach… and yeah, sure. Maybe it’s a bit pretentious. But, whatever. They’ve earned it. Laravel, its ecosystem and community takes pride in being polished and professional — and rightly so.
Medialibrary and the Stripe Webhooks library made me happy.
I love hearing about developer experiences by solo devs. As a potential solo dev, I was actually looking to go the Spring Boot route. I think Java has gone in a better direction the past few years, and I prefer it over PHP due to static typing, functional programming (to a point), and the tooling. Spring Boot seems to provide a lot of the same development productivity. My only other experience is with Rails and Django, although those have been with small projects.
I always find these technical decisions to be difficult to gauge when you're starting off.
I always find these technical decisions to be difficult to gauge when you're starting off.
I also find these decisions very hard. I switched from NodeJS to Spring Boot some 5 years ago when I found that the JS community moved faster than my clients could pay me to keep up to date. It has been great to make apps in Java with Thymeleaf, until I wanted to add dynamic frontends (a lot of advantages vanished) or when I tried to put Java on my CV.
I am now considering switching to .NET and Angular.
I would be happy to have a talk on this topic: what directions to take as solo-dev. I find that a whole different set of requirements apply.
I would be happy to have a talk on this topic: what directions to take as solo-dev. I find that a whole different set of requirements apply.
I don't understand why putting Java on your CV was a problem nor why you're considering switching to .Net. Here in London good Java developers earn a premium and along with PHP you will always find jobs with these languages in any location.
Hey that's fantastic. I'd love to hear more! You went 5 years in the direct direction I want to go (Spring Boot + Thymeleaf). I'm a bit confused why you were having difficulty finding work with Java. Seems like there's a lot of Java work out there.
What I found, and I may have been wrong, is that there is a lot of Java work but if you look deeper it is hardcore Java EE with all thise 200 levels of Java that a lot of folks fear. And so do I. Even jobs that had Spring Boot asked for the JavaEE experience.
Could be just me though.
Could be just me though.
I don't think it's just you. I came off a java gig about couple years back - typical enterprise... stuff. Lots of legacy stuff from 10-15 years ago that few people knew anything about, mixed docs, some tests, but not useful to learn from. Even pre-covid, far too few people for the size of the codebase and where they were trying to go. I started in October, I was given a ticket in November that someone else - who had left months earlier - estimated at '40 hours' in May of that year. This was my first 'task' at the company, and ... it took way more than 40 hours. It took 40 calendar hours to get a meeting with the PM to actually walk me through how to set up the bug the ticket was about. Some bigwig threw up to my manager that I was 'over budget' and 'threatened their client relationship' because I was taking so long (on a ticket that had been sitting around 5 months before it was estimated, then another 6 months before someone started working on it). They routinely rejected requests for info on the issue, or access to servers/data/etc. So... I went part time then, and moved in to something else pretty quickly. I know not all Java shops are like that, but it was like living in an enterprise cliché.
Check out NestJS (https://nestjs.com/) - it's a typescript framework for Node inspired by both Spring and the Angular architecture.
If your points are with static typing functional and tooling i would give another look to PHP 8/ symfony|Laravel
There's nothing in your list which doesn't have an equivalent in the Rails and Django ecosystems. Laravel is just another MVC framework built with a dynamically-typed scripting language. Rails, Django, Laravel - take your pick. Same wine in a similar bottle.
I've worked 8+ years with Django and the last 2~3 years with Laravel. Other than the admin, I don't miss anything from Django. Laravel is so much better in almost every other aspect.
OP seems to quite vehemently disagree that they are that alike even though he has more experience with Django than with Laravel. Curious what explains this gap.
>doesn't have an equivalent
Having an equivalent and being included and used by default is very different. To the point Laravel is more opinionated ( so to speak ) than Rails.
Having an equivalent and being included and used by default is very different. To the point Laravel is more opinionated ( so to speak ) than Rails.
Personally, I liked Laravel when I was first investigating it years ago, but was always a touch put off by the pervasive "I am beautiful, adore me" undercurrent throughout its design, documentation, and even comments. I'll be the first to admit that's not a rational critique.
Having said that, though, Laravel is relatively unusual among major frameworks in that it doesn't seem to have been developed in tandem with a real-world project like Rails and Django were (e.g., BaseCamp and the Lawrence World Journal's internal CMS), but rather developed just to be "a better framework." Each successive release of Laravel seems to push even harder at tying you up with other Laravel add-ons, some of which are paid services. Rails and Django are open-source projects, but Laravel is an open-source product. Again, not necessarily bad, but there's an increasing feeling that the Laravel commercialization model is "give us sufficient money and you'll barely have to write any code."
My other nitpick with Laravel is that learning to develop with it is often learning to develop specifically for Laravel rather than learning to develop for PHP. This is a charge leveled against Rails and Django, too, but Python and (perhaps especially) Ruby are just better languages for developing DSLs in. Laravel has to jump through a lot of hoops behind the scenes to do what it does, leaving you with a framework that isn't particularly nimble and design patterns that often aren't particularly applicable to the rest of the PHP world.
If you're willing to hop fully on board with the Laravel train, none of this may be an issue for you. But at this point I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all. Use Composer to pull in specific packages that you really need, and ask "if I can get the functionality I need from this package with an afternoon's work, is the package bringing anything to the table that I still want" before adding them. (Sometimes the answer is "yes," but not always, and I tend to be wary of packages that primarily just wrap other packages.)
Having said that, though, Laravel is relatively unusual among major frameworks in that it doesn't seem to have been developed in tandem with a real-world project like Rails and Django were (e.g., BaseCamp and the Lawrence World Journal's internal CMS), but rather developed just to be "a better framework." Each successive release of Laravel seems to push even harder at tying you up with other Laravel add-ons, some of which are paid services. Rails and Django are open-source projects, but Laravel is an open-source product. Again, not necessarily bad, but there's an increasing feeling that the Laravel commercialization model is "give us sufficient money and you'll barely have to write any code."
My other nitpick with Laravel is that learning to develop with it is often learning to develop specifically for Laravel rather than learning to develop for PHP. This is a charge leveled against Rails and Django, too, but Python and (perhaps especially) Ruby are just better languages for developing DSLs in. Laravel has to jump through a lot of hoops behind the scenes to do what it does, leaving you with a framework that isn't particularly nimble and design patterns that often aren't particularly applicable to the rest of the PHP world.
If you're willing to hop fully on board with the Laravel train, none of this may be an issue for you. But at this point I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all. Use Composer to pull in specific packages that you really need, and ask "if I can get the functionality I need from this package with an afternoon's work, is the package bringing anything to the table that I still want" before adding them. (Sometimes the answer is "yes," but not always, and I tend to be wary of packages that primarily just wrap other packages.)
> Laravel has to jump through a lot of hoops behind the scenes to do what it does, leaving you with a framework that isn't particularly nimble and design patterns that often aren't particularly applicable to the rest of the PHP world.
And tell me, do you use React? Talk about jumping through hoops just to print HTMl.
Personally I'm very glad Laravel was written in PHP, because:
1) you can still use raw PHP in the templates if you wish.
2) PHP Traits allow a very interesting form of polymorphism and code-reuse which is especially suited to the kind of business logic you find in web apps.
3) PHP is very much a C-inspired language that was built ONLY for the web, so you get access to a lot of low-level constructs and a "baremetal" paradigm (passthroughs like system() for bash scripts with seamless handling of STDIN/STDOUT) plus a solid standard library for the web. The PHP standard lib supports everything you need to write HTTP servers: curl_setopt, parse_url, FFI for calling C functions for performance-sensitive code, date/time/number/currency formatting, global variables for cookies and sessions, etc. all out of the box.
For web apps, I'll take PHP over NodeJS/Ruby/Python any day of the week.
And tell me, do you use React? Talk about jumping through hoops just to print HTMl.
Personally I'm very glad Laravel was written in PHP, because:
1) you can still use raw PHP in the templates if you wish.
2) PHP Traits allow a very interesting form of polymorphism and code-reuse which is especially suited to the kind of business logic you find in web apps.
3) PHP is very much a C-inspired language that was built ONLY for the web, so you get access to a lot of low-level constructs and a "baremetal" paradigm (passthroughs like system() for bash scripts with seamless handling of STDIN/STDOUT) plus a solid standard library for the web. The PHP standard lib supports everything you need to write HTTP servers: curl_setopt, parse_url, FFI for calling C functions for performance-sensitive code, date/time/number/currency formatting, global variables for cookies and sessions, etc. all out of the box.
For web apps, I'll take PHP over NodeJS/Ruby/Python any day of the week.
Your response reads to me like you think I was dunking on PHP, but I wasn't. I don't feel like PHP is a particularly great language to write a DSL-style web framework in, but that's largely because -- as I was trying to suggest with the part about "Use Composer to pull in specific packages you really need" -- modern PHP mostly just doesn't feel like it needs a framework to me. That's precisely because, as you put it, PHP was built ONLY for the web, and the language's earlier quirkiness has really been smoothed over in the last decade. I like PHP. We are closer to being in agreement than you may think. :)
(Although I might take Ruby over PHP, depending on specific circumstances. Ruby is just such a nice language, and Rails has gotten pretty darn good once it stopped being "interesting" and could settle down to making itself productive. Maybe that will one day happen with Node…)
(Although I might take Ruby over PHP, depending on specific circumstances. Ruby is just such a nice language, and Rails has gotten pretty darn good once it stopped being "interesting" and could settle down to making itself productive. Maybe that will one day happen with Node…)
> but was always a touch put off by the pervasive "I am beautiful, adore me" undercurrent throughout its design, documentation, and even comments. I'll be the first to admit that's not a rational critique.
I should add, separately, that after a long career in web-development, this kind of reflexive emotional response strikes me as practically a survival instinct, so I am not judging you for it at all.
I should add, separately, that after a long career in web-development, this kind of reflexive emotional response strikes me as practically a survival instinct, so I am not judging you for it at all.
If you want to talk about potentially irrational reasons to be put off Laravel: when picking a framework I ended up going with Zend over Laravel mostly due to the modularity of the former... but also because the wide prevalence of Laracasts made me concerned that written documentation would be difficult to use and the documentation space of the framework would slowly migrate to being half-out-of-date video and audio snippets that slowly became more and more misleading and inapplicable without being updated due to a lack of motivation.
FWIW that hasn't been my experience at all. The documentation is great and well maintained. The repo is public and you can see all changes here: https://github.com/laravel/docs
I made this decision about four years ago and while the documentation was well maintained at the time I was concerned that the Laracasts would be unmaintained and become a source of confusion that talked about no longer present features. I was mostly afraid about the primary problem with over-documentation: you're introducing a maintenance cost which, if you ever stop paying, ends up quickly causing more harm than never having had the documentation in the first place.
Here[1], for instance, is someone in this very response thread talking about how the core getting started Laracasts are out of date and they're confused which documentation they should reference. This will probably be addressed pretty soon (see the comment) but I think this is a very real danger with promising to deliver non-text based documentation.
1. https://news.ycombinator.com/item?id=30261801
Here[1], for instance, is someone in this very response thread talking about how the core getting started Laracasts are out of date and they're confused which documentation they should reference. This will probably be addressed pretty soon (see the comment) but I think this is a very real danger with promising to deliver non-text based documentation.
1. https://news.ycombinator.com/item?id=30261801
Laravel 9 was released today (hence this thread) - Laravel 8 is the major version that came out directly before Laravel 9. Further, Laravel 9 is essentially Laravel 8 with a bump to the dependencies, with most higher impact changes coming as a result of those dependencies being updated[1]. The Laravel 8 From Scratch series has videos as recently as August[2], with the What's New in Laravel 9 series already having 11 videos[3], with the most recent posted yesterday. The Laracasts video series are still very much actively updated (with Jeffrey, who runs it adding new teachers in the last year).
And Laracasts is a 3rd party learning resource anyway, with the first party docs all being well maintained.
1. https://laravel.com/docs/9.x/upgrade
2. https://laracasts.com/series/laravel-8-from-scratch/episodes...
3. https://laracasts.com/series/whats-new-in-laravel-9
And Laracasts is a 3rd party learning resource anyway, with the first party docs all being well maintained.
1. https://laravel.com/docs/9.x/upgrade
2. https://laracasts.com/series/laravel-8-from-scratch/episodes...
3. https://laracasts.com/series/whats-new-in-laravel-9
I think it's safe to view Laracasts as being "sold" as part of the documentation officially accessible - and documentation should be ready before a release is pushed into public release. I absolutely sympathize if I've got the wrong impression of Laracasts (though maybe they should be less frequently promoted by Laravel itself if that's the case) and I completely understand that it takes time to record updated audio-visual tutorials... but that's exactly the sort of thing I'm talking about - those prominent audio-visual tutorials existing and being pretty officially associated with Laravel means that new users trying to learn the system have windows where the documentation is confusing and out of date.
It seems like an unnecessary risk to have adopted given that it's not at all standard in the industry - sometimes language designers will give a version specific tutorial but they're understood to be unmaintained with the docos being the official source... Laracasts are a very different thing which appear to be mostly working, but seem really likely to dramatically and suddenly become more of a danger than a benefit.
One parallel I would draw on is the community effort, when PHP 5.3 or 5.4 came out, to purge all the terrible advice from StackOverflow. PHP had an issue, its documentation on php.net was fine and followed best practices, but the StackOverflow answers were often _terrible_ like - this will cause a big gaping hole in your security instantly terrible. It took a significant amount of effort to delete or properly answer these sources and since that happened the reputation of PHP has hugely improved. Bad documentation existing is worse than no documentation existing (but please don't take this as an excuse to not comment your code, just be conservative in your comments and keep it to a level you can actually afford to maintain).
It seems like an unnecessary risk to have adopted given that it's not at all standard in the industry - sometimes language designers will give a version specific tutorial but they're understood to be unmaintained with the docos being the official source... Laracasts are a very different thing which appear to be mostly working, but seem really likely to dramatically and suddenly become more of a danger than a benefit.
One parallel I would draw on is the community effort, when PHP 5.3 or 5.4 came out, to purge all the terrible advice from StackOverflow. PHP had an issue, its documentation on php.net was fine and followed best practices, but the StackOverflow answers were often _terrible_ like - this will cause a big gaping hole in your security instantly terrible. It took a significant amount of effort to delete or properly answer these sources and since that happened the reputation of PHP has hugely improved. Bad documentation existing is worse than no documentation existing (but please don't take this as an excuse to not comment your code, just be conservative in your comments and keep it to a level you can actually afford to maintain).
Are there any decent docs for Zend at all? I struggled with it for years. Simple "how do I ..." questions would just bring up nothing. Not from the docs, nor anywhere else on the web. Any solution I'd find wouldn't work in my case because other parts of my app were built in some incompatible way.
The Laravel docs on the other hand are the best I've ever seen and there's a huge amount of community driven guides that are mostly decent too.
The Laravel docs on the other hand are the best I've ever seen and there's a huge amount of community driven guides that are mostly decent too.
Zend has had some issues in that Zend1 and Zend2 were essentially different frameworks since Zend1 was built before namespacing was implemented. Whenever googling I'll include zf1, zf2, zf3 or laminas in the query to make sure I'm looking at the right version. The official documentation[1] itself is pretty good and has been since zf2 though, since laminas/zend has always been extremely modular, there aren't a lot of assumptions around what other components you're using, so most of the component documentation is pretty self contained. There are also resources like the skeleton application[2] that can be good places to begin if you're starting fresh.
1. https://docs.laminas.dev/
2. https://docs.laminas.dev/tutorials/getting-started/skeleton-...
1. https://docs.laminas.dev/
2. https://docs.laminas.dev/tutorials/getting-started/skeleton-...
That's not super irrational. :) Laravel does seem to be keeping up with their written documentation, although it's also occasionally an example of their "See how great Laravel is? See? See?" style.
FWIW I have never once interacted with Laravel's commercial model, or felt that I am being engineered into it. I just don't give it another thought.
I haven't interacted with it, either. "Engineered into it" would be too strong a phrasing, but it's hard not to get the impression Laravel's creator(s) really, really want you to use their other services. I mean, compare the menu bars of rubyonrails.org, djangoproject.com, and laravel.com: Rails's first links are "blogs" and "guides"; Django's first links are "overview" and "download"; Laravel's first links are "Forge" (their commercial provisioning service) and "Vapor" (their "serverless" deployment platform).
I take your point and I understand that you could get that impression looking at the website; they have stuff to sell.
There's also more of a market for some of that stuff, and the reason is the huge proliferation of different PHP execution environments. PHP runs in more places and there are more opportunities to help correct for the limitations of those environments (with log monitoring tools and the like).
(Also -- contrarywise as they say -- PHP does _not_ run first-class in some serverless environments; you need a custom execution environment for PHP in Lambda. So there's an opportunity there.)
But as a developer experience it is really not commercialised at all. I do not look at or think of any of those things, and I've not encountered any significant upselling. I'd forgotten all about Forge until you mentioned it! (And will now revisit it)
There's also more of a market for some of that stuff, and the reason is the huge proliferation of different PHP execution environments. PHP runs in more places and there are more opportunities to help correct for the limitations of those environments (with log monitoring tools and the like).
(Also -- contrarywise as they say -- PHP does _not_ run first-class in some serverless environments; you need a custom execution environment for PHP in Lambda. So there's an opportunity there.)
But as a developer experience it is really not commercialised at all. I do not look at or think of any of those things, and I've not encountered any significant upselling. I'd forgotten all about Forge until you mentioned it! (And will now revisit it)
This is totally fair. A few years back I worked on a Laravel project when both me and the other dev were fairly new to Laravel, and neither of us were particularly adept sysadmins. Forge was a life-saver when it came time to deploy.
Now that I'm _much_ more experienced with Linux server management, I found a mix of Laravel's official deployment docs and some community tutorials more than enough to spin up my Laravel apps on Digital Ocean.
I think that Laravel providing Forge as an official happy path for deployment is to the benefit of newer Laravel developers. I've listened to the hosts of the Django Chat Podcast lament about deployment being a big hurdle for newer Django developers. I'm glad that Laravel has an easy button. As someone who is now more experienced, I'm also glad that I don't feel forced to use Forge and other services by the Laravel team. I might use it again at some point though.
Now that I'm _much_ more experienced with Linux server management, I found a mix of Laravel's official deployment docs and some community tutorials more than enough to spin up my Laravel apps on Digital Ocean.
I think that Laravel providing Forge as an official happy path for deployment is to the benefit of newer Laravel developers. I've listened to the hosts of the Django Chat Podcast lament about deployment being a big hurdle for newer Django developers. I'm glad that Laravel has an easy button. As someone who is now more experienced, I'm also glad that I don't feel forced to use Forge and other services by the Laravel team. I might use it again at some point though.
Disagree mostly. I’ve never paid for any of the paid modules and continue to use Laravel on a daily basis.
I do feel the docs are a little minimal at times, maybe to make them prettier? Could definitely benefit from a little more explanation in places.
I do feel the docs are a little minimal at times, maybe to make them prettier? Could definitely benefit from a little more explanation in places.
> I'm not convinced that smaller PHP projects, at least, might not be better off without frameworks at all
Uh having experienced the old pre-codeigniter php, I don't really recommended it. Without proper controller separation (using twig as rendering engine for example) it poses the risk for the business logic to be tangled with view.
Not to mention that it's hard to do routing with native php, except the simple [folder-path]/[php-filename].php and remove the extension requirement with .htaccess.
At that point I recommend to just use a framework instead, though arguably Laravel may be too big for some. I don't know if PHP has similar framework like expressJs though that just handle the minimum requirements.
Uh having experienced the old pre-codeigniter php, I don't really recommended it. Without proper controller separation (using twig as rendering engine for example) it poses the risk for the business logic to be tangled with view.
Not to mention that it's hard to do routing with native php, except the simple [folder-path]/[php-filename].php and remove the extension requirement with .htaccess.
At that point I recommend to just use a framework instead, though arguably Laravel may be too big for some. I don't know if PHP has similar framework like expressJs though that just handle the minimum requirements.
> Without proper controller separation (using twig as rendering engine for example) it poses the risk for the business logic to be tangled with view.
Well, you should also quote the part in my comment about "use Composer to pull in specific packages that you really need." :) I'm not suggesting "roll everything on your own," necessarily: if you want to use Twig, or another templating engine, add that as a Composer package. (Personally, I'd just write a small pure PHP template class to handle this and trust myself not to be a dingus, but if I were on a team that might change the calculus here.)
> Not to mention that it's hard to do routing with native PHP...
Again, you don't have to roll your own here; you can include something like FastRoute or even Symfony's router as a routing engine.
I'm not saying you should avoid absolutely all libraries. Laravel is built on top of a lot of Symfony libraries, after all! For a project I've been noodling with slowly, I'm using my own "pure PHP" template engine, but I'm using FastRoute for routing, Doctrine DBAL (although not the ORM) for database access, Monolog for logging, PHP Debug Bar to get a lot of debugging info in development, etc.
Well, you should also quote the part in my comment about "use Composer to pull in specific packages that you really need." :) I'm not suggesting "roll everything on your own," necessarily: if you want to use Twig, or another templating engine, add that as a Composer package. (Personally, I'd just write a small pure PHP template class to handle this and trust myself not to be a dingus, but if I were on a team that might change the calculus here.)
> Not to mention that it's hard to do routing with native PHP...
Again, you don't have to roll your own here; you can include something like FastRoute or even Symfony's router as a routing engine.
I'm not saying you should avoid absolutely all libraries. Laravel is built on top of a lot of Symfony libraries, after all! For a project I've been noodling with slowly, I'm using my own "pure PHP" template engine, but I'm using FastRoute for routing, Doctrine DBAL (although not the ORM) for database access, Monolog for logging, PHP Debug Bar to get a lot of debugging info in development, etc.
Okay that's a fair approach, though it's still not recommended for everyone especially those who isn't much familiar with those packages setup.
It is quite obvious that Laravel is written by an American, they all do understand marketing better than us Europeans, Artisans creates works of art and it is eloquent even if it isn't.
What is great about Laravel is all the addons you can apply seamlessly.
But I can't say I like the overall design, too much magic for my taste and all the non-strict typing. Put things in the correct directory and things happen is generally a bad design. Use magic name on class object either as a property or a function and different things happen.
I do understand that it is easier for the framework developer to have loose typing, easier to swap implementations between major versions, but it makes it harder for the framework user. I have to, at least in older Laravel versions, apply a lot of annotations to get a pleasant developer experience.
In every Laravel project I haven been involved in I have needed to read the Laravel framework source code with all its layers to get grip what is actually going on and how it is related to my specific problem. However this have been true for every framework project I have been involved in, Laravel or not.
What is great about Laravel is all the addons you can apply seamlessly.
But I can't say I like the overall design, too much magic for my taste and all the non-strict typing. Put things in the correct directory and things happen is generally a bad design. Use magic name on class object either as a property or a function and different things happen.
I do understand that it is easier for the framework developer to have loose typing, easier to swap implementations between major versions, but it makes it harder for the framework user. I have to, at least in older Laravel versions, apply a lot of annotations to get a pleasant developer experience.
In every Laravel project I haven been involved in I have needed to read the Laravel framework source code with all its layers to get grip what is actually going on and how it is related to my specific problem. However this have been true for every framework project I have been involved in, Laravel or not.
> Laravel... doesn't seem to have been developed in tandem with a real-world project
> other Laravel add-ons, some of which are paid services
These other services are what you're looking for - that's how Taylor and the team dog-foods Laravel.
While I don't object at all to the claim that small PHP projects can easily be done w/out a major framework, it's worth noting that both many components of these frameworks (including Laravel) can be incorporated into a smaller project ad hoc.
> other Laravel add-ons, some of which are paid services
These other services are what you're looking for - that's how Taylor and the team dog-foods Laravel.
While I don't object at all to the claim that small PHP projects can easily be done w/out a major framework, it's worth noting that both many components of these frameworks (including Laravel) can be incorporated into a smaller project ad hoc.
Just for some context, here's how the items under "Ecosystem" on laravel.com break down on free vs. paid:
Free:
- Breeze
- Cashier
- Dusk
- Echo
- Horizon
- Jetstream
- Mix
- Octane
- Sail
- Sanctum
- Scout
- Socialite
- Telescope
- Valet
Paid:
- Envoyer
- Forge
- Nova
- Spark
- Vapor
Free:
- Breeze
- Cashier
- Dusk
- Echo
- Horizon
- Jetstream
- Mix
- Octane
- Sail
- Sanctum
- Scout
- Socialite
- Telescope
- Valet
Paid:
- Envoyer
- Forge
- Nova
- Spark
- Vapor
You left out Nova, which is also paid.
I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel add-on services, but Basecamp makes money from the SaaS applications they're building on top of Rails and is not trying to monetize Rails itself.)
I don't want to come across as "nobody should give Laravel money," to be clear. I'm just observing that Laravel is essentially a commercial open-source enterprise in a way that Rails and Django aren't. Models like this seem to be a bit more common in the PHP world. (e.g., Sensio Labs makes their money by teaching and consulting on Symfony, Laravel LLC makes money from Laravel add-on services, but Basecamp makes money from the SaaS applications they're building on top of Rails and is not trying to monetize Rails itself.)
Rails very much was a commercial open source enterprise when it started out.
It's just that the enterprise was Basecamp and the other 37 Signals apps. They benefited enormously from the extra eyeballs on their framework, not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time.
They had no services to sell but they had a keen commercial imperative.
It's just that the enterprise was Basecamp and the other 37 Signals apps. They benefited enormously from the extra eyeballs on their framework, not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time.
They had no services to sell but they had a keen commercial imperative.
> not least during the infamous "hey, we built this massive web framework in part around the incorrect assumption that GET requests don't need to be idempotent and then encouraged everyone to use it" time.
Tell me more. I remember when Rails was first released but missed that entire saga.
Tell me more. I remember when Rails was first released but missed that entire saga.
It is so long ago now that I can't even find stuff about it on Google -- 2006 I think?
Basically, well after they'd released the framework they had to change the Rails scaffolding (and I think their own apps) because parts of the scaffolding (CRUD deletes) would use GET to do the action that should only be done as POST. They discovered it about the time link-prefetching was invented ;-)
Basically, browsers were pre-fetching all the clever scaffolded delete URLs and destroying records, seemingly at random.
I was really impressed with Rails at the time but stayed well away from the scaffolded code in production, and I was gobsmacked by the idea that people talking about a clever, opinionated framework that did the right thing and produced magical, clean, elegant code to rescue you from terrible alternatives did not understand that GET requests should be idempotent.
Edit: here is one bit about it:
https://dhh.dk/arc/000455.html
The unearned high-mindedness of this still makes me chuckle.
Basically, well after they'd released the framework they had to change the Rails scaffolding (and I think their own apps) because parts of the scaffolding (CRUD deletes) would use GET to do the action that should only be done as POST. They discovered it about the time link-prefetching was invented ;-)
Basically, browsers were pre-fetching all the clever scaffolded delete URLs and destroying records, seemingly at random.
I was really impressed with Rails at the time but stayed well away from the scaffolded code in production, and I was gobsmacked by the idea that people talking about a clever, opinionated framework that did the right thing and produced magical, clean, elegant code to rescue you from terrible alternatives did not understand that GET requests should be idempotent.
Edit: here is one bit about it:
https://dhh.dk/arc/000455.html
The unearned high-mindedness of this still makes me chuckle.
[deleted]
You're right, thanks! Edited to add Nova (which I think is a fantastic product, and is worth far more than the $199 it costs).
I admit my initial thought looking at Nova was "this is free with Django!", but I'm pretty sure Nova does a lot more. :) (Django's automatic admin interface still had a distinct "state of the art for 2006" vibe the last time I looked, although to be fair it's been a few years.)
for $199, you'd think Nova would be mobile friendly. Maybe this has changed? When we tried it last year, we were quite shocked it had no responsive design support.
This gives absolutely no context as I have no idea what these funny names are :)
Free:
- Breeze: authentication starter kit
- Cashier: payment processing through Stripe or Paddle
- Dusk: automated browser testing
- Echo: real-time broadcasting
- Horizon: queue handler
- Jetstream: application scaffolding
- Mix: frontend asset compilation
- Octane: serverless Laravel
- Sail: Laravel Docker environment
- Sanctum: SPA authentication
- Scout: search engine
- Socialite: OAuth provider authentication
- Telescope: application monitoring
- Valet: macOS developer environment
Paid:
- Envoyer: zero-downtime deployment service
- Forge: Laravel hosting via AWS, DigitalOcean, and more
- Spark: application scaffolding kit
- Vapor: serverless Laravel hosting via AWS
- Breeze: authentication starter kit
- Cashier: payment processing through Stripe or Paddle
- Dusk: automated browser testing
- Echo: real-time broadcasting
- Horizon: queue handler
- Jetstream: application scaffolding
- Mix: frontend asset compilation
- Octane: serverless Laravel
- Sail: Laravel Docker environment
- Sanctum: SPA authentication
- Scout: search engine
- Socialite: OAuth provider authentication
- Telescope: application monitoring
- Valet: macOS developer environment
Paid:
- Envoyer: zero-downtime deployment service
- Forge: Laravel hosting via AWS, DigitalOcean, and more
- Spark: application scaffolding kit
- Vapor: serverless Laravel hosting via AWS
I've just realised that a) I've used precisely none of them, and b) Passport isn't even on the list!
I really do need to look at all of this stuff again, because I'm very open to not running my own VMs/services for a couple of apps.
I really do need to look at all of this stuff again, because I'm very open to not running my own VMs/services for a couple of apps.
>Laravel commercialization model is "give us sufficient money and you'll barely have to write any code."
I actually think this is a good direction. Working its way backward to Low-Code.
I actually think this is a good direction. Working its way backward to Low-Code.
[deleted]
We have been using Laravel for over 8 years. Nothing but praise. It's a framework we could rely on. No painful upgrades and clear documentation. For us it's a pleasure to work with. I also recommend Laracasts from Jeffrey Way.
Yeah. Maybe what we love from Laravel isn't only great docs and painless upgrade process, but also the great ecosystem.
It's the fact that it has a culture of grown-ups. Where by "grown-ups" I mean there is an avoidance of cute hacks for the sake of things, there is an approach where nobody assumes anyone is the same kind of expert, and takes care to contextualise.
There is a stronger emphasis on being able to _write_, to explain, etc.
I love really cute hacks and neat minilanguages and metaprogramming and all that when I am doing things for fun. But when I am working, I want documentation, not five-line git READMEs that presume I am up-to-date.
There is a stronger emphasis on being able to _write_, to explain, etc.
I love really cute hacks and neat minilanguages and metaprogramming and all that when I am doing things for fun. But when I am working, I want documentation, not five-line git READMEs that presume I am up-to-date.
I wanted to try it. I wanted to see if it could help me solve a business problem.
Sadly I just wasn't able to understand the first steps to get something out there.
I really still want to like it. But currently I have no idea how to practically start.
Sadly I just wasn't able to understand the first steps to get something out there.
I really still want to like it. But currently I have no idea how to practically start.
Seconded this in its entirety. Been to Laracon multiple times, use it for all my side projects (as well as startup). Has performed remarkably well and more consistently than any other experiences I've used
I met Taylor a few years ago at a conference we were both speaking at. Coming from the iOS world, I had no idea who he was.
"So, what do you work with?"
"PHP mainly", he said.
I replied "That sucks, sorry man."
¯\_(ツ)_/¯
"So, what do you work with?"
"PHP mainly", he said.
I replied "That sucks, sorry man."
¯\_(ツ)_/¯
We're used to it . You're wrong, though!
Haha not surprised - ecosystem seems to be doing very well.
The fact that everyone thinks that PHP is terrible is really good at keeping the ecosystem healthy. No one is swooping in and overcomplicating the stack for internet brownie points. If something exists, it exists to solve a real problem.
What was his response?
Making money in PHP is better than making none at all!
We both just laughed
Glad he was able to take it in stride. I bet it was funny when you realized who it was
To be fair, the guy is doing alright. His business is booming. He probably gets the PHP pity all the time and has learnt to deal with it.
For those here wondering why you'd use Laravel over vanilla PHP + MySQL + PDO, a few of my clients had this opinion so I've had experience. The Laravel "fluff" saves you from rewriting tons of code, helps you write test cases, and makes logic easy to follow.
One of my clients was very anti "needless vendor packages" (definitely some truth to this sentiment), but we ended up with 14 extra php files reinventing the wheel. I'd opt for the former any day.
One of my clients was very anti "needless vendor packages" (definitely some truth to this sentiment), but we ended up with 14 extra php files reinventing the wheel. I'd opt for the former any day.
The concept of frameworks in PHP predates its package manager and its PSR standards. Nowadays you can easily slap a collection of libraries together to create your own micro-framework that fulfills your precise needs. That is often a better decision than to go with a monster like Laravel or Symfony which by design aims to be good at all the things, instead of good at the things you need. Those frameworks themselves usually have individual components that can be used independently of the rest of the framework for exactly this purpose
hello, I am in a growth phase startup and have been here since the early days. I am speaking from experience about a specific type of company and codebase.
if you’re planning to scale a team and a company, do not do this. stick to Laravel. let your new hires read the docs and move on to shipping features.
if I were going to build a solo project, yes, I would consider bolting the libraries I want into a high comfort codebase that allowed me to move quickly.
there is a massive Laravel talent pool and straying from the standard approach just makes onboarding and maintenance more difficult. focus on your company’s problems and don’t be bespoke. if Laravel is even in consideration for you and your company and your problem space, there’s absolutely no problem that is worth reinventing the wheel on here
if you’re planning to scale a team and a company, do not do this. stick to Laravel. let your new hires read the docs and move on to shipping features.
if I were going to build a solo project, yes, I would consider bolting the libraries I want into a high comfort codebase that allowed me to move quickly.
there is a massive Laravel talent pool and straying from the standard approach just makes onboarding and maintenance more difficult. focus on your company’s problems and don’t be bespoke. if Laravel is even in consideration for you and your company and your problem space, there’s absolutely no problem that is worth reinventing the wheel on here
The biggest benifit to something like Laravel is that a new developer to your team can step in and know where everything should be and how it should generally work without asking. There is good documentation so you dont have to write that for your foundational code, just your business logic.
A bunch of bespoke packages strung together with no logic does not provide that. You can surely look up how one package works but its a lot harder to figure out how it all ties together.
A bunch of bespoke packages strung together with no logic does not provide that. You can surely look up how one package works but its a lot harder to figure out how it all ties together.
I can see how it's seen as a benefit, but the flipside is that you're teaching your developers Laravel, not PHP. They assume whatever they do, they do in a good way because it's Laravel that does it which is great, but it abstracts actual knowledge. It's like if a developer uses SQL exclusively through an ORM and DBAL, how much can they be expected to know about the workings of SQL performance, indexes, etc.
I also find it very interesting that there's no stigma associated with "Laravel developers" that focus exclusively on that framework and its syntax and way of doing things and you have "WordPress developers" who do the exact same but are seen as incompetent.
I understand though that there are scenarios in which what you want is a guy that knows a framework really well, but if we're talking about skills of a developer, I'll pick the guy that knows vanilla PHP over a framework specialist 80% of the time
I also find it very interesting that there's no stigma associated with "Laravel developers" that focus exclusively on that framework and its syntax and way of doing things and you have "WordPress developers" who do the exact same but are seen as incompetent.
I understand though that there are scenarios in which what you want is a guy that knows a framework really well, but if we're talking about skills of a developer, I'll pick the guy that knows vanilla PHP over a framework specialist 80% of the time
I find it hard to imagine how anyone who groks Laravel well enough to get a product shipped could be deficient in understanding PHP. Surely such cases are outliers?
I regularly interview PHP developers for hiring and I can quickly classify them into 1. Wordpress Developers, 2. PHP developers and lately 3. Laravel developers.
Specifically for no 3 is the kind of developer who considers the framework magical and has no idea how things are done without it because they've learned framework first and the PHP basics to survive. They can do well for basic CRUD tasks but for anything trickier they get stuck.
Specifically for no 3 is the kind of developer who considers the framework magical and has no idea how things are done without it because they've learned framework first and the PHP basics to survive. They can do well for basic CRUD tasks but for anything trickier they get stuck.
Seems easy enough to teach if those developers have picked up whatever is in front of them in the past.
Being Laravel focused and knowing what is happening underneath the hood are not mutually exclusive. A mature developer knows when to stray from the framework when its absolutely needed, not when it just seems like a fun thing to do. 99% of the time the frameworks predetermined path is the right way as its the simplest to maintain.
If you’re pulling libraries instead of using a framework, you’re basically just writing your own framework. One that’s simpler but also it’s unique so you lose the ability to bring in a seasoned Laravel dev that can get going right away. You have introduced a learning curve for all new devs that didn’t need to be there.
There is a micro symfony build just for this purpose, as barebones as possible, pull in only what you need.
yes, that's basically what a framework is for. but you have to follow the framework's way of doing things. most of the time that works well. few times, you may be fighting the framework to achieve some special cases.
you call libraries. framework calls you.
you call libraries. framework calls you.
Yeah you're right this is kind of the archetypical "framework vs not" or "framework vs library" debate.
And I agree there's nuance to that conversation.
IMO, PHP codebases most err on the side of "reinventing the wheel" because PHP has since its inception just sort of worked, i.e. mirroring directory structure, spitting out HTML verbatim etc. So the framework luddites tend to be over-represented with PHP projects. Hence my opinion here.
And I agree there's nuance to that conversation.
IMO, PHP codebases most err on the side of "reinventing the wheel" because PHP has since its inception just sort of worked, i.e. mirroring directory structure, spitting out HTML verbatim etc. So the framework luddites tend to be over-represented with PHP projects. Hence my opinion here.
I would say that if you're considering frameworkless I might suggest Laminas (the Zend successor) as an alternative since it allows you to pull in tools in a more piecemeal style. Integrating roll-your-own components into Laravel can be difficult due to have tightly knit and off the beaten path their internal style can be.
I think there are a few quite good choices of frameworks right now in PHP and I hope the space remains healthy and varied since the different options do cater well to different use cases.
I think there are a few quite good choices of frameworks right now in PHP and I hope the space remains healthy and varied since the different options do cater well to different use cases.
14 files on the scale of a large app, is nothing?
Yeah, not a large app. I should have mentioned that it had like 12 endpoints total
Laravel and Drupal 7+ frankly ruined PHP for me.
PHP as a platform is KISS and elegant, and I still admire some of its features such as built in templating, filesystem based routing, etc.
But whenever I look back at Laravel, I remember how dangerous overly complex fluff with a nice logo is to a platform.
PHP as a platform is KISS and elegant, and I still admire some of its features such as built in templating, filesystem based routing, etc.
But whenever I look back at Laravel, I remember how dangerous overly complex fluff with a nice logo is to a platform.
IMHO Laravel and Symfony are the best things that happened to PHP community since php5. PHP was an ugly mess of bad practices, fragmented into many outdated apps/frameworks and it was just exhausting to use. Symphony was a great improvement, but a bit too rigid and too enterprise-level for my taste. For me Laravel was honestly a breath of fresh air - finally I had something significantly more powerful than my custom framework and still highly flexible and light-weight.
Laravel definitely is everything, but light-weight. It's the slowest of the large names in PHP.
see http://www.phpbenchmarks.com/en/comparator/framework or https://www.techempower.com/benchmarks/#section=data-r20&hw=...
see http://www.phpbenchmarks.com/en/comparator/framework or https://www.techempower.com/benchmarks/#section=data-r20&hw=...
Agreed! Framework == good doesn't mean any/all frameworks == good. Many of PHP's frameworks seem to have ignored PHP's unique run-time characteristics and adopted Java idioms (with Java, you pay once at compile time; with PHP, you pay with every single request). Ubiquity, near/at the top of the PHP benchmarks, seems to accept PHP's unique run-time characteristics (so performs well) and yet still provides all the benefits of a framework (consistency, etc). Ubiquity should see much more love than Laravel/Symfony/etc but doesn't :(
> It's the slowest of the large names in PHP.
No, in 2022 it seems it's not. Just seen this benchmark today: Laravel is the 2nd fastest, after Kirby (but Kirby is static text files CMS so it's not really comparable). Not sure what exactly they've tested and it's probably not super realistic, but still it's far from calling Laravel the slowest.
https://twitter.com/getkirby/status/1493538621768581120
No, in 2022 it seems it's not. Just seen this benchmark today: Laravel is the 2nd fastest, after Kirby (but Kirby is static text files CMS so it's not really comparable). Not sure what exactly they've tested and it's probably not super realistic, but still it's far from calling Laravel the slowest.
https://twitter.com/getkirby/status/1493538621768581120
As soon as you throw an MVC framework into the mix with an ORM the much-touted speed gains of PHP in recents years vanish into thin air. That's because with heavy frameworks PHP's shared nothing architecture works against you.
Generally yes, but there has been at least some improvements regarding this with preloading shipped with PHP 7.4 and with the inheritance cache added to PHP 8.1, both synergize well with framework heavy code.
You’re posting benchmarks for versions that are now more than 7 years old
TechEmpower appears[0] to be using Laravel 8.70, which was released about 3 months ago. Much less than 7 years ago.
The numbers there don't paint an encouraging picture either, but I'm happy to concede that performance isn't everything... it just doesn't matter for some applications. But, numbers like these are pretty appalling to me. (And yes, I feel the same way about Rails.)
[0]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
The numbers there don't paint an encouraging picture either, but I'm happy to concede that performance isn't everything... it just doesn't matter for some applications. But, numbers like these are pretty appalling to me. (And yes, I feel the same way about Rails.)
[0]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
Compared to Zend, Symfony and other FWs popular a decade ago, Laravel 4 felt very light... or perhaps less complex is the right word, as I never really compared the file sizes, but it subjectively felt way easier to find your way around...
Any app without a framework ends up creating a framework of its own. Complexity isn't something to hand-wave away, but neither is the mess of include's and SQL injection risks that many "vanilla" apps become.
Same applies for frameworks. Your hoping that the framework and ecosystem is clean as to get everyone to update the framework isn't an easy task espcially when a vulnerability arises from within.
It's moot. Take Wordpress for example.
It's moot. Take Wordpress for example.
> However your then hoping that there are not any vulnerabilities within the framework.
The likelihood of me introducing an injection, authentication/authorization bypass or RCE vulnerability in homegrown stuff is orders of magnitude larger than in an application where at least the sensitive core parts are handled by something that's battle tested in millions of deployments and regularly audited.
The likelihood of me introducing an injection, authentication/authorization bypass or RCE vulnerability in homegrown stuff is orders of magnitude larger than in an application where at least the sensitive core parts are handled by something that's battle tested in millions of deployments and regularly audited.
If the framework is promoted to be enhanced by a ecosystem of plugins, widgets, your still introducing the same exploitable ground as of developing your own. If not more dangerous because your operating already on core infrastructure and with a wider audience. How often does the developer get bored and start to neglect the plugin?
I do agree that a single home-hobbyist programmer should not be coding a bank and that sql injections and the rest are all lethal to the internet. However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.
It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.
I do agree that a single home-hobbyist programmer should not be coding a bank and that sql injections and the rest are all lethal to the internet. However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.
It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.
>How often does the developer get bored and start to neglect the plugin?
For the most popular frameworks (e.g. Drupal, Symfony, PHPunit), the core ecosystem is (co-)maintained by the framework authors, who are funded through various means - usually consulting/webdev agencies. The "usual" FOSS burnout problem doesn't apply for them.
> However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.
A framework is just that: a framework. You can develop all you want with that framework - I've seen Symfony being used for tiny microservices to the code for a bank's website. You can develop faster and better code because you don't have to re-invent wheels or do tedious interoperability tests for basic stuff allll the time, and whatever problem you encounter, someone else will have also encountered and posted a solution on Stackoverflow.
> It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.
No. Symfony, Laravel and others are the vendors for the basic bike... you can always bolt on custom parts according to your need and for the PSR-standardized stuff like loggers, you can even choose between multiple different part vendors.
For the most popular frameworks (e.g. Drupal, Symfony, PHPunit), the core ecosystem is (co-)maintained by the framework authors, who are funded through various means - usually consulting/webdev agencies. The "usual" FOSS burnout problem doesn't apply for them.
> However you end up with stagnation and lack of innovation if you pressure users to use a framework because there's a fear of some sort of exploit.
A framework is just that: a framework. You can develop all you want with that framework - I've seen Symfony being used for tiny microservices to the code for a bank's website. You can develop faster and better code because you don't have to re-invent wheels or do tedious interoperability tests for basic stuff allll the time, and whatever problem you encounter, someone else will have also encountered and posted a solution on Stackoverflow.
> It's like riding a bike and forcing the rider not to ride without stabilisers because they may fall sideways.
No. Symfony, Laravel and others are the vendors for the basic bike... you can always bolt on custom parts according to your need and for the PSR-standardized stuff like loggers, you can even choose between multiple different part vendors.
You have valid points, I disagree on personal preference and so I'll agree to disagree.
I guess what i'm saying is building from scratch makes different happen. I can see the purpose of frameworks but when it comes to a new start-up project, it just feels like it should be built from scratch otherwise you have a project which is pre-made and not really yours. Thats what puts me off from using a framework.
Myself was script-kiddie in the older-generation of the internet era, 15/16. I'm talking 2003. when extensions have .php3 and uploading scripts over 56k took hours. If you wanted a forum, same for a CMS either use a pre-existing platform and used the functionality it provided or built it yourself. PHPNuke, e107, PHPBB all come to mind. However the internet was young, compared to now where technology has evolved and time is less, so I can see where frameworks come in.
I guess what i'm saying is building from scratch makes different happen. I can see the purpose of frameworks but when it comes to a new start-up project, it just feels like it should be built from scratch otherwise you have a project which is pre-made and not really yours. Thats what puts me off from using a framework.
Myself was script-kiddie in the older-generation of the internet era, 15/16. I'm talking 2003. when extensions have .php3 and uploading scripts over 56k took hours. If you wanted a forum, same for a CMS either use a pre-existing platform and used the functionality it provided or built it yourself. PHPNuke, e107, PHPBB all come to mind. However the internet was young, compared to now where technology has evolved and time is less, so I can see where frameworks come in.
Not true of Node.js.
Node.js is only fine if you have the personal energy to keep up with all of JS tooling all the time. It strikes me as insanely unprofessional most of the time.
Laravel always seems to be the work of grownups; it's not cutting edge but it is solid and self-contained.
Laravel always seems to be the work of grownups; it's not cutting edge but it is solid and self-contained.
True, and just like with the Gradle build system on JVM, every project is its own unique snowflake.
That's what you meant, right ;-)
Or is it just everything I inherit?
That's what you meant, right ;-)
Or is it just everything I inherit?
Funny, all I remember is the hot mess everyone was producing before Laravel.
Right.
Laravel 7 and 8 have been excellent. It's a good product with beautiful documentation.
Laravel 7 and 8 have been excellent. It's a good product with beautiful documentation.
beside legacy cobol, wordpress plugins were the most horrendous code i've ever seen. dead code I should say since quite often half of it was left commented in the official running source.
You can use Laravel just for the basic wiring, integrated tooling, SQL query builder, auth, sessions, and HTTP routing. It really gets out of the way if you need to avoid features you don't like. All of the stuff I listed above are a PITA in plain PHP.
Yep -- Laravel has always been the work of grownups in this regard.
It's a really very good platform for headless PHP. The job queuing stuff is so neat it actually makes me write queueable jobs.
Combined with Lighthouse, Spatie's Stripe Webhooks library, Spatie's MediaLibrary, I've actually had fun with Laravel.
I see no reason for hate now.
It's a really very good platform for headless PHP. The job queuing stuff is so neat it actually makes me write queueable jobs.
Combined with Lighthouse, Spatie's Stripe Webhooks library, Spatie's MediaLibrary, I've actually had fun with Laravel.
I see no reason for hate now.
I went kind of in another direction a few years ago - CodeIgniter's routing/sessions/etc base was plenty for most of my projects, but I wanted a real ORM. So I integrated Eloquent from Laravel and ignored the built-in CI database layer. A bunch of these sites are still running smoothly on modern PHP.
Symfony components would be the better choice?
Did they change Laravel to only include what you want like Symfony?
Having worked in both environments (framework vs no framework), for anything other than very trivial apps, you want the framework to force everyone into a common way of doing things. Otherwise the project turns into a a massive clusterfuck of everyone doing their own thing, often with many instances of "reinventing the wheel" going on.
> Laravel and Drupal 7+ frankly ruined PHP for me.
You don't have to use either. It's like saying something like "Britney Spears ruined music for me".
Just go with Symfony and be done with it.
You don't have to use either. It's like saying something like "Britney Spears ruined music for me".
Just go with Symfony and be done with it.
Getting started with Laravel on Mac required me to fire up Docker desktop which I don't particularly care for but I proceeded because I like to try out new things, so I followed the documentation https://laravel.com/docs/9.x#your-first-laravel-project:
- Fired up Docker desktop - ran curl -s "https://laravel.build/example-app" | bash and "cd example-app" - typed "./vendor/bin/sail up" and got an error "no such file or directory: ./vendor/bin/sail" - Deleted the example-app and ran curl -s "https://laravel.build/example-app" | bash and "cd example-app" - typed "./vendor/bin/sail up" and got another error "no configuration file provided: not found"
By this time my MBP fan sounds like an Airbus A380 getting ready to takeoff and I'm already frustrated with the framework, not sure what I'm missing!!
- Fired up Docker desktop - ran curl -s "https://laravel.build/example-app" | bash and "cd example-app" - typed "./vendor/bin/sail up" and got an error "no such file or directory: ./vendor/bin/sail" - Deleted the example-app and ran curl -s "https://laravel.build/example-app" | bash and "cd example-app" - typed "./vendor/bin/sail up" and got another error "no configuration file provided: not found"
By this time my MBP fan sounds like an Airbus A380 getting ready to takeoff and I'm already frustrated with the framework, not sure what I'm missing!!
The docs push you in the docker direction, but they also have Laravel Valet which "is a development environment for macOS minimalists": https://laravel.com/docs/9.x/valet
A lot of Laravel devs use Valet instead of Docker.
A lot of Laravel devs use Valet instead of Docker.
I've been programming in PHP for around 5 years. I've used vanilla PHP, full featured MVC frameworks, micro frameworks and I've been working with Laravel for around 2 weeks. Worst experience ever. The more I dig into it the more I hate it.
This doesn't match my experience at all, and given Laravel's popularity... this comment would be a lot more valuable with a why.
I will say I opt out of the starter packs and Laravel Sail (their Docker-for-dummies basic setup) in favor of a more bespoke setup, but my Laravel experience has been great otherwise.
I will say I opt out of the starter packs and Laravel Sail (their Docker-for-dummies basic setup) in favor of a more bespoke setup, but my Laravel experience has been great otherwise.
Not the OP, but one thing that stands out for me is the (lack of) quality of the documentation. It reads more like a book (that tries to explain how to do things) than a reference (an exhaustive list of all classes, methods, parameters etc.). Ok, it's nice to have the former, but the latter would be far more important!
If you think so, it's available here: https://laravel.com/api/master/
That does seem very, uhh, minimalistic, if that's supposed to be the reference documentation. Just one very short sentence per method. Most arguments are unexplained. No examples that I could find.
I'm not sure what you're trying to find. The main Laravel docs are fine for 90% of what you would want to do. If you're digging into the core of some internal class trying to decide if you can re-use something elsewhere, that seems edge-case-y.
The ORM, relationship model, templating, and routing are all thoroughly documented in the main docs. If you want to find out what obscure methods might be available for your custom package, you're probably competent enough to parse the auto-generated code docs or read the source directly (which is also very clear and well organized).
The ORM, relationship model, templating, and routing are all thoroughly documented in the main docs. If you want to find out what obscure methods might be available for your custom package, you're probably competent enough to parse the auto-generated code docs or read the source directly (which is also very clear and well organized).
Does Laravel have anything akin to the Rails Guides? (ie, higher level based on what you want to do, rather than API-level documentation)
Rails has a number of "cast" sites as well. There are times however that you just need well organized text documentation.
It's actually not unreasonable to expect something that exists between the main documentation and the automated API documentation. Sounds like a great idea for someone to build and contribute back to the community!
I've been programming in PHP since ~2000, I've created giant systems with vanilla PHP, Kohana, Code Igniter, WordPress, and for the last ~8 years, Laravel. It's been a dream to work with.
I, like others, am curious about what your actual complaints are more than "I hate it".
As others have said, its opinionated, but its opinions tend to be strong ones with good data. It is also extremely customizable, with a smaller learning curve than most other frameworks and a richer community and documentation that the vast majority of frameworks.
If I were to hazard a guess, you're running into your opinion being counter theirs?
I, like others, am curious about what your actual complaints are more than "I hate it".
As others have said, its opinionated, but its opinions tend to be strong ones with good data. It is also extremely customizable, with a smaller learning curve than most other frameworks and a richer community and documentation that the vast majority of frameworks.
If I were to hazard a guess, you're running into your opinion being counter theirs?
I've been programming PHP since around 2003 and although I don't find Laravel to be perfect, I find it to be a very solid framework to build general web solutions with. I have successfully launched everything from complex OAUTH solutions handling insane amounts of traffic, to dumb startup ideas, to just simple CRUD apps I use in my own personal life.
I find it to be fully featured, incredibly well documented, and easy to use/learn. I find it to be my favorite "RAD" tool for generic API development. Also, the community is pretty solid too - specifically the IRC channel. I'll go far enough to say that Laravel has positively motivated my development as a software engineer - it's opinionated but I find it to be opinionated in a good way. Example: Laravel is heavy on testing/tooling which I think is outstanding.
I am really curious as to what specifically you're finding problematic?
I find it to be fully featured, incredibly well documented, and easy to use/learn. I find it to be my favorite "RAD" tool for generic API development. Also, the community is pretty solid too - specifically the IRC channel. I'll go far enough to say that Laravel has positively motivated my development as a software engineer - it's opinionated but I find it to be opinionated in a good way. Example: Laravel is heavy on testing/tooling which I think is outstanding.
I am really curious as to what specifically you're finding problematic?
This is my experience with Laravel as well. Laravel looks great on the surface for a simple CRUD application, but once you need to do something non-trivial with it, you need to start fighting the framework. Also I dislike the large amount of magic happening within the framework. I want to understand what the code is doing, so that I can properly debug it in an emergency.
As a specific example I needed to override half of the classes of Laravel Passport within the DI container to fix issues upstream wouldn't acknowledge at the time / doesn't acknowledge. Some of them are fixed by now (e.g. they finally support non auto increment Client IDs OOTB), some of them are not when I last checked.
I wouldn't choose Laravel again.
As a specific example I needed to override half of the classes of Laravel Passport within the DI container to fix issues upstream wouldn't acknowledge at the time / doesn't acknowledge. Some of them are fixed by now (e.g. they finally support non auto increment Client IDs OOTB), some of them are not when I last checked.
I wouldn't choose Laravel again.
Exactly this for the exact same reasons, only more specific to the Eloquent ORM instead. God forbid you need to do nested-nested-nested relationships or something relatively complex. Laravel works VERY well for the simple cases, but all the weak typing, reflection and runtime searches that it uses just makes every runtime framework problem a pain in the ass to debug. I'll stick to Spring Boot or ASP.NET Core any day.
It sounds like Doctrine https://www.doctrine-project.org/ is what you need if you want an ORM to handle relatively complex stuff. It's the default in Symfony projects and I don't know if there's a Laravel integration.
ASP.NET Core is nice mind; if you have the choice... :)
ASP.NET Core is nice mind; if you have the choice... :)
ASP.Net Core runs perfectly well on Linux so cheap VMs are an option now.
I don't know if many share the same sentiment, but mine is to keep ORM use to the simplest of query. Anymore complex than that is better to be developed with raw queries, which also usually supported by the ORM.
Passport is the only bit that makes me nervous, because of one over-broad exception that it raises that I don't really like. I accept that the action from that exception is the same in each case but I'd rather it broke it up into more than one.
The rest of Laravel I have no complaints over; compared to Rails it is a model of pragmatism.
The rest of Laravel I have no complaints over; compared to Rails it is a model of pragmatism.
Do you have any actual complaints?
Honestly surprised by this. It's an opinionated framework, but it's consistent and the ecosystem is rich with options. I've been very happy working inside the laravel ecosystem for the last couple of years.
A problem with any "opinionated" framework is that people may disagree with the opinions. :)
What would you suggest as idiomatic server code which is not Laravel, in PHP?
I had the "pleasure" to work a bit with a PHP legacy server written in Laravel, and I thought that the framework was alright - the problem was in the PHP code written with it (specifically its typing). I think laravel is opinionated and can help to have a consistent codebase... curious to know why you had such a bad experience, and where you were happier :D
I had the "pleasure" to work a bit with a PHP legacy server written in Laravel, and I thought that the framework was alright - the problem was in the PHP code written with it (specifically its typing). I think laravel is opinionated and can help to have a consistent codebase... curious to know why you had such a bad experience, and where you were happier :D
Checkout Laracasts, Jeffrey Way is pretty good explaining things. I don't use Laravel (or PHP at all),but I do like his video tutorials a lot. I say this, because maybe is you the docs, or you cant find a way of doing something, etc...
When learning cool bird facts I really enjoy listening to people talk - but when trying to debug or learn a new framework I absolutely insist on written documentation. I need to be able to re-read paragraphs or segue to other topics briefly and then return which is incompatible with anything audio-visual. The existence of Laracasts was actually a strong disincentive for me to go with Laravel and I've been quite happy over in Zend/Laminas land.
So you decided not to use framework because there is website with video courses about it? Interesting reasoning. Isnt there website with videos about the other framework?
There were a few reasons that was just one of them. My concern was that the website with video courses might supplant text based tutorials. Additionally, we've all got different learning styles - I've got ADHD so video courses are extremely ineffective for me.
I think I know where you are coming from. The first time I touched laravel was somewhere 2016-2017. I loved the way you got started and using valet got your app up and running a few minutes. Recently I wanted to do a quick project and noticed it is getting bloated. You have multiple paths you can follow instead of being straight forward. It adds to the learning curve. It is ironic because some of this new things were supposed to make it easier to create an MVP, but what happens is that it makes it harder to learn how the framework operates and integrates with all the new features.
Downvoting because you're not adding any info besides 'laravel bad.' I am interested in your experiences, but "I hate it" isn't useful by itself.
This is a wildly unhelpful comment without additional explanation. My guess is you're doing it wrong.
Given the success of the framework, you just might need sone more time before it clicks
Please tell us why?
Excellent.
The LTS nature of this release is good news (because presumably it involves the Laravel team committing to supporting the version of Symfony they use for some components).
The LTS nature of this release is good news (because presumably it involves the Laravel team committing to supporting the version of Symfony they use for some components).
I like using plain PHP + PDO MySQL. I structure it so almost all files contain a single function/MySQL query, with very little dependencies. I already know how to implement core functionalities when needed (e.g. CSRF, user permissions). Why should I consider Laravel if plain PHP seems to work excellent in my case (been able to maintain the same codebase for over 9 years without issues, can quickly create a new app if needed, can reuse code from one project to another, understanding what the code does requires zero-framework knowledge, performance is as good as it can be, as every file executes only what's needed and doesn't create unnecessary abstractions, etc.)?
> Why should I consider Laravel
If you work on all those projects alone, and you're happy doing this, you probably wouldn't. You aren't the target market for a framework like this.
Laravel (and any good framework, really) is for people who want a consistent dev experience _with good documentation_.
If you work on all those projects alone, and you're happy doing this, you probably wouldn't. You aren't the target market for a framework like this.
Laravel (and any good framework, really) is for people who want a consistent dev experience _with good documentation_.
> You aren't the target market for a framework like this.
I don't know about this. But then I am of an age where I consider myself to be a team of programmers separated by time.
There are the younger, less easily tired versions of myself who thought this was a great idea for a career and lived on takeaway curries, there's me, and there are the four or five older versions of myself who will hate me for trying to be clever and not trying to be consistent.
Laravel helps me take on projects that allow me to hand off pieces of work among my team ;-)
I don't know about this. But then I am of an age where I consider myself to be a team of programmers separated by time.
There are the younger, less easily tired versions of myself who thought this was a great idea for a career and lived on takeaway curries, there's me, and there are the four or five older versions of myself who will hate me for trying to be clever and not trying to be consistent.
Laravel helps me take on projects that allow me to hand off pieces of work among my team ;-)
Yes, I do work alone on those projects, but I do use frameworks on the frontend-side as I find them to help in the long term, not hinder the projects as PHP frameworks do (a lot of boilerplate).
It makes sense that if Laravel is strongly-opinionated to result in a consistent dev experience, but is a consistently bloated dev experience better than an inconsistent lean one?
It makes sense that if Laravel is strongly-opinionated to result in a consistent dev experience, but is a consistently bloated dev experience better than an inconsistent lean one?
Bloat can be mostly ignored, inconsistencies can not.
Frameworks are useful for working in teams, and on long term projects. This is because they provide a set of idioms, patterns and decisions that everyone can learn and know, without having to invent them all yourself. It doesn't have to be the perfect way, it just has to be a way, so that you can focus on your domain specfic problems.
Likewise, when a new developer arrives, they know exactly where to find everything because it has a place that it belongs, and they can reference the docs if they are having trouble.
It's less about the code and more about treating the project as a whole ecosystem.
Likewise, when a new developer arrives, they know exactly where to find everything because it has a place that it belongs, and they can reference the docs if they are having trouble.
It's less about the code and more about treating the project as a whole ecosystem.
But what if the app is a simple monolith that exposes some API routes and processes/reads/stores data in a database?
Is something like this really harder to understand for a new developer than a Laravel project?
Is something like this really harder to understand for a new developer than a Laravel project?
.htaccess
dbconfig.php
/api
/users
create.php
get.php
getAll.php
delete.php
/products
create.php
get.php
delete.php
// /api/users/getAll.php
include 'dbconfig.php';
checkPermissions(ROLE_ADMIN);
$res = $db->exec("SELECT * from users");
echo json_encode($res);Those files might work and your project might stay on that small scale - but you'd find it impossible to add automated tests to that. If your project grew to be serious enough to warrant automated testing then you're going to want to seriously refactor it and using a framework's dependency management is just going to make your life easier. You can make things a lot safer with just a little bit of separation and that will help protect you against bugs and security issues.
This is all said by someone who is working right now with a codebase with a checkPermissions function that they added to shift things off of direct $_SESSION access and which has since been almost entirely supplanted by route based authentication. I delight in working to modernize and secure legacy systems which is why I heavily favor Laminas over Laravel due to the add-it-as-you-need-it approach, when I first worked to convert our codebase to a framework we did it page by page and component by component with everything working fine for both legacy and framework fulfilled requests and we've slowly added more components as they've become necessary (and removed ones that are no longer of use).
This is all said by someone who is working right now with a codebase with a checkPermissions function that they added to shift things off of direct $_SESSION access and which has since been almost entirely supplanted by route based authentication. I delight in working to modernize and secure legacy systems which is why I heavily favor Laminas over Laravel due to the add-it-as-you-need-it approach, when I first worked to convert our codebase to a framework we did it page by page and component by component with everything working fine for both legacy and framework fulfilled requests and we've slowly added more components as they've become necessary (and removed ones that are no longer of use).
It might be hard to do, but do you measure any KPIs (performance, codebase size, time needed to write a new feature, security) for before/after converting the platform to a different framework?
I did switch the front-end side from no-framework (jQuery spaghetti) to a framework (React + MUI + TypeScript), but the main reason was that I needed:
1) Component reusability
2) Premade components (UI elements)
3) Data typing (thus TypeScript, to get autocompletion features)
On the back-end side, the default PHP language already supports most of those things, plus the reusability part is very little for an API (it's mostly having some basic functions such as auth/db connection and writing different queries), for which a framework wouldn't necessarily make things easier, just provide a different way of writing those queries (i.e. ORM vs direct DB query). I agree, it's nice that with an ORM you get autocompletion for the fields you want to select, but the databases that I usually use only have a few (intuitively named) columns, so if you take a look at the table it immediately makes sense (but the queries are still prone to typos, so you might get an error the first time you type it).
I did switch the front-end side from no-framework (jQuery spaghetti) to a framework (React + MUI + TypeScript), but the main reason was that I needed:
1) Component reusability
2) Premade components (UI elements)
3) Data typing (thus TypeScript, to get autocompletion features)
On the back-end side, the default PHP language already supports most of those things, plus the reusability part is very little for an API (it's mostly having some basic functions such as auth/db connection and writing different queries), for which a framework wouldn't necessarily make things easier, just provide a different way of writing those queries (i.e. ORM vs direct DB query). I agree, it's nice that with an ORM you get autocompletion for the fields you want to select, but the databases that I usually use only have a few (intuitively named) columns, so if you take a look at the table it immediately makes sense (but the queries are still prone to typos, so you might get an error the first time you type it).
We don't specifically numerically measure them but we have seen our defect rate go down noticeably. The changes are also quite minimal with very little developer overhead being required - using a service architecture requires writing a factory and class definition once... using a query repository is about the same.
The biggest advantage we've seen though is in onboarding time. The more purpose driven and modular our code gets the quicker it is people pick up on each individual module types structure and new devs can start experimental coding quite quickly.
For me, personally, the ultimate attribute I value over everything else in a codebase is minimized maintenance costs - we have a few corners of our codebase that have extremely brittle automated tests that require hours of labour to execute the simplest of changes in and they're on our fix list. But the stuff we need to change frequently can be changed quickly and safely so our bug fix turn around is relatively minor. I'm actually in the middle of upgrading us from ZF2 to Laminas and this work is probably going to last about three weeks (with a bunch of the most annoying fixes coming out of Doctrine and their fanatical devotion to `final`ing every class under the sun - thanks guys) which honestly seems extremely reasonable to me for bumping two framework versions.
I'm also really not personally a fan of ORMs because the query building tends to make DB performance harder to tune and I loathe the performance implications of ActiveRecord approaches - but they're components I've built into our infrastructure to support other devs and I can comprehend their appeal.
The biggest advantage we've seen though is in onboarding time. The more purpose driven and modular our code gets the quicker it is people pick up on each individual module types structure and new devs can start experimental coding quite quickly.
For me, personally, the ultimate attribute I value over everything else in a codebase is minimized maintenance costs - we have a few corners of our codebase that have extremely brittle automated tests that require hours of labour to execute the simplest of changes in and they're on our fix list. But the stuff we need to change frequently can be changed quickly and safely so our bug fix turn around is relatively minor. I'm actually in the middle of upgrading us from ZF2 to Laminas and this work is probably going to last about three weeks (with a bunch of the most annoying fixes coming out of Doctrine and their fanatical devotion to `final`ing every class under the sun - thanks guys) which honestly seems extremely reasonable to me for bumping two framework versions.
I'm also really not personally a fan of ORMs because the query building tends to make DB performance harder to tune and I loathe the performance implications of ActiveRecord approaches - but they're components I've built into our infrastructure to support other devs and I can comprehend their appeal.
Nearly every time I see PHP projects like this, I find massive security vulnerabilities combined with extremely brittle functionality.
Sure, this describes many Laravel and Symfony projects as well, and not every vanilla PHP project is bad. But there is definitely a pattern.
Sure, this describes many Laravel and Symfony projects as well, and not every vanilla PHP project is bad. But there is definitely a pattern.
I agree, one big reason to use frameworks is that they at least make it harder to make insecure things, but as you said, if the developer is inexperienced they can still introduce vulnerabilities in any codebase.
I would say, in this regard, that Laravel is better than plain PHP when working with inexperienced devs that are likely to make mistakes or write bad code.
I would say, in this regard, that Laravel is better than plain PHP when working with inexperienced devs that are likely to make mistakes or write bad code.
So what happens if you want to hire a second dev to help you? Or you want to sell the codebase?
A new dev can start writing code immediately by looking at any existing file, as almost all of them do the same thing: include a shared header, get some input from the user, do one or more MySQL queries, return the result.
The backend is completely separated from the frontend (so the PHP application just exposes an API to work with), so any code written there does exactly what you expect with no side effects on the client-side.
The backend is completely separated from the frontend (so the PHP application just exposes an API to work with), so any code written there does exactly what you expect with no side effects on the client-side.
> as almost all of them do the same thing
It's the almost that will get you here.
It's the almost that will get you here.
The difference is mostly the user input, MySQL query and DB table and output. This is indeed prone to typos and "brain-farts" when selecting the wrong data.
Does Laravel provide any protection in making sure you don't SELECT from the wrong table?
Does Laravel provide any protection in making sure you don't SELECT from the wrong table?
Generally I use the model builder methods for this anyway, because I'm using the ORM and the models represent tables, so I barely ever build my own select statements at all.
https://laravel.com/docs/8.x/eloquent
https://laravel.com/docs/8.x/eloquent
Even with an ORM, isn't there the risk of typing Flight::select('name') instead of Passenger::select('name'), if both values return the same data type (string)?
Is that harder to do than accidentally typing `SELECT name FROM flights` instead of `SELECT name FROM passengers`?
Aren't most of those issues found as soon as you first test the feature?
Is that harder to do than accidentally typing `SELECT name FROM flights` instead of `SELECT name FROM passengers`?
Aren't most of those issues found as soon as you first test the feature?
I don't understand the point you're getting at here. Isn't this kind of typo more or less universally possible? Which code library or generator can protect you from errors like this (and divine your intent?)
You can be protected from SQL injection and you can have various other query operations, and you can gain refactoring support (e.g. by telling the models the new table name), or you can add custom scopes that encapsulate transformations on the query.
Laravel also allows you to express model relationships, so Flight might have:
I don't know.
The thing is, an ORM brings you other stuff (like a query builder integration) that allows you to construct queries without having to glue SQL strings together (and chain and pass query objects).
And Laravel separately also brings you a migration tool that allows you to encapsulate upgrades to your database as code snippets (so you can put code live without manually fiddling with SQL at all).
In my experience even really small apps benefit from this at some level. The discipline of using regular patterns like this is really useful.
(The Lighthouse GraphQL binding is where this stuff gets really interesting)
At any rate, we're unlikely to agree.
[edit: removed a tired-brain word choice mistake!]
You can be protected from SQL injection and you can have various other query operations, and you can gain refactoring support (e.g. by telling the models the new table name), or you can add custom scopes that encapsulate transformations on the query.
Laravel also allows you to express model relationships, so Flight might have:
public function passengers(): BelongsTo {
return $this->hasMany(Passenger::class);
}
$flight->passengers->where('name', 'like', 'XCSme%');
I don't know.
The thing is, an ORM brings you other stuff (like a query builder integration) that allows you to construct queries without having to glue SQL strings together (and chain and pass query objects).
And Laravel separately also brings you a migration tool that allows you to encapsulate upgrades to your database as code snippets (so you can put code live without manually fiddling with SQL at all).
In my experience even really small apps benefit from this at some level. The discipline of using regular patterns like this is really useful.
(The Lighthouse GraphQL binding is where this stuff gets really interesting)
At any rate, we're unlikely to agree.
[edit: removed a tired-brain word choice mistake!]
There is no doubt that getting in and out of a Laravel project is a bit more difficult than the example you suggest. But the example you suggest absolutely encourages bad practice.
Non-PHP, non-Laravel person here just trying to learn. That looks pretty good to me. What bad practices does it encourage?
I wrote that example, which is simplified, but here are some security things to keep in mind when dealing with PHP/MySQL:
- Always use PDO prepared statements to avoid SQL injections
- Should probably implement a CSRF token check
- You shouldn't output values directly from the user/database and that can lead to XSS
attacks (either sanitize the stored data, or when outputting it make sure the page is always interpreted as plain text)
- You might forget to check for permissions in a specific route (code enforce this via some linting/IDE rules, by using some automated tests or by checking in an included shared script that permissions were indeed verified)Thank you. Somehow, I thought the tree structure they described for breaking down program logic was the problem. Obviously I agree with all the other stuff, which is table stakes for a safe web app
Always use PDO prepared statements to avoid SQL injections?
Sanitize your data and use whatever driver you want. Prepare statements are like sending xml instead of json. If you are populating a database with known data why add the overhead?
Sanitize your data and use whatever driver you want. Prepare statements are like sending xml instead of json. If you are populating a database with known data why add the overhead?
> absolutely encourages bad practice
Bad practice, as in security-wise, performance-wise, readability-wise, or something else?
If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices?
If the developer is inexperienced, can't they still implement something in a bad way in Laravel (e.g. save a user-submitted file on the disk without checking for permissions)?
Bad practice, as in security-wise, performance-wise, readability-wise, or something else?
If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices?
If the developer is inexperienced, can't they still implement something in a bad way in Laravel (e.g. save a user-submitted file on the disk without checking for permissions)?
> If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices?
That depends. How tired is the developer? How under pressure? How over deadline? ;-)
I do get your point and I understand where you're coming from.
But this model of PHP (where every URL entry point is its own script) is the thing that most encourages expedient development rather than good development, because you can just hack on that one thing without affecting anything else.
It also (traditionally) encourages somewhat riskier hosting configurations, because any PHP file the web server can route may need to be executable, and because a failure of web server configuration can expose PHP files as readable. Whereas with a single point of entry (index.php router), you can locate your codebase outside the document root, refuse to directly execute anything but your endpoint script, etc.
These are partly old-fashioned concerns, admittedly, but it's surprising how often the approach you're outlining is still the source of malicious PHP exploits where a script file gets buried in a hacked release, or where some server vulnerability can be inveigled into executing PHP code by some image file upload mechanism that didn't do adequate checking.
That depends. How tired is the developer? How under pressure? How over deadline? ;-)
I do get your point and I understand where you're coming from.
But this model of PHP (where every URL entry point is its own script) is the thing that most encourages expedient development rather than good development, because you can just hack on that one thing without affecting anything else.
It also (traditionally) encourages somewhat riskier hosting configurations, because any PHP file the web server can route may need to be executable, and because a failure of web server configuration can expose PHP files as readable. Whereas with a single point of entry (index.php router), you can locate your codebase outside the document root, refuse to directly execute anything but your endpoint script, etc.
These are partly old-fashioned concerns, admittedly, but it's surprising how often the approach you're outlining is still the source of malicious PHP exploits where a script file gets buried in a hacked release, or where some server vulnerability can be inveigled into executing PHP code by some image file upload mechanism that didn't do adequate checking.
I agree that writing secure PHP code is hard, but using a framework like Laravel, even if it has a single point of entry, makes it a lot more likely to introduce more security issues. When a framework is popular and open-source, people will spend a lot more resources trying to find and exploit vulnerabilities than in a custom private codebase: https://snyk.io/vuln/composer:laravel%2Fframework
I can see your point.
But at the same time, I have never seen a project built along the lines you discussed that has not collapsed under the pressure for expedience, and it's just as vulnerable to issues in libraries (which any project of any complexity will use).
But at the same time, I have never seen a project built along the lines you discussed that has not collapsed under the pressure for expedience, and it's just as vulnerable to issues in libraries (which any project of any complexity will use).
I think the biggest question to ask is how big the project is.
Wikipedia, Facebook, Etsy and other huge platform are written in PHP, but I doubt they use a framework like Laravel and not some in-house built platform.
Very tiny projects probably need no framework.
That leaves medium-sized projects, but again, it's hard to define what "size" means. I think a project is bigger if it implements various functionalities instead of having hundreds of different files that do a similar thing.
I can see Laravel being used more by out-sourcing companies. Custom frameworks or no framework being used more by companies building their own product.
Wikipedia, Facebook, Etsy and other huge platform are written in PHP, but I doubt they use a framework like Laravel and not some in-house built platform.
Very tiny projects probably need no framework.
That leaves medium-sized projects, but again, it's hard to define what "size" means. I think a project is bigger if it implements various functionalities instead of having hundreds of different files that do a similar thing.
I can see Laravel being used more by out-sourcing companies. Custom frameworks or no framework being used more by companies building their own product.
If your project is as simple as this then yes, a framework would be overkill for you.
The people that benefit from Laravel use a lot of its features and aren’t willing to waste time rewriting them for themselves.
In the businesses I have worked at, if we had spent the whole time building the stuff that Laravel already does for us then we’d have gone broke really quickly.
The people that benefit from Laravel use a lot of its features and aren’t willing to waste time rewriting them for themselves.
In the businesses I have worked at, if we had spent the whole time building the stuff that Laravel already does for us then we’d have gone broke really quickly.
If I am working alone, I sometimes do similar stuff. But if I am working with others, I don't really want to deliberate over every new architectural decision if a project grows. I want to be able to say, "Hey, can you make a new storelocator page" and then they can get it done using the docs. They know where models, controllers, views live, they know how to make migrations for the new tables, they can even google "store locator laravel" and probably get 90% of the way there in a day or less. Once they are done, I already know how this new feature should work before I even read their code.
I took over an enormous system that a third party developer built in Laravel.
Not good code, particularly, and not particularly good database design.
Also no documentation really.
But the implementation was pretty clearly pure Laravel, and the migrations ran without issue. So that was immediately a huge weight off my mind, because I knew I would be able to maintain the live, stage and dev boxes sanely.
The two biggest problems with this app were
1) the number of places they diverged from using the query builder for no really good reason when scopes could have made everything so much more readable
2) a false assumption they made about subquery ordering in MySQL (implicit ordering that worked for them in 4.x but would not work in 5.x, something along those lines anyway)
Because of 1), 2) was incredibly painful to fix. Dozens of bits of arbitrary SQL that could have been handled by the query builder.
And I'm sure the only reason it's like that is because that's the way they started out and they had time pressure that stopped them ever changing course.
Expedience kills software.
Not good code, particularly, and not particularly good database design.
Also no documentation really.
But the implementation was pretty clearly pure Laravel, and the migrations ran without issue. So that was immediately a huge weight off my mind, because I knew I would be able to maintain the live, stage and dev boxes sanely.
The two biggest problems with this app were
1) the number of places they diverged from using the query builder for no really good reason when scopes could have made everything so much more readable
2) a false assumption they made about subquery ordering in MySQL (implicit ordering that worked for them in 4.x but would not work in 5.x, something along those lines anyway)
Because of 1), 2) was incredibly painful to fix. Dozens of bits of arbitrary SQL that could have been handled by the query builder.
And I'm sure the only reason it's like that is because that's the way they started out and they had time pressure that stopped them ever changing course.
Expedience kills software.
> Expedience kills software
Unfortunately, this is how the majority of software is written nowadays. This is one of the reasons I prefer to build things slowly, think about stuff, implement them nicely, find clever solutions and optimize where it's possible. I know I could build more stuff and earn more money if I rushed things more, but I prefer building nicer stuff instead of more stuff. For most outsourcing companies, this doesn't really make economic sense though, but for product-driven companies it is still possible if the leadership decides to do it.
> the implementation was pretty clearly pure Laravel, and the migrations ran without issue
Being able to refactor/change one part of the code without being afraid that something else might break is an excellent reason to use a framework. Once you understand how that framework works, even if a codebase is bad, you can know what and how can break if not implemented properly. It increases the visibility of "code smells".
Unfortunately, this is how the majority of software is written nowadays. This is one of the reasons I prefer to build things slowly, think about stuff, implement them nicely, find clever solutions and optimize where it's possible. I know I could build more stuff and earn more money if I rushed things more, but I prefer building nicer stuff instead of more stuff. For most outsourcing companies, this doesn't really make economic sense though, but for product-driven companies it is still possible if the leadership decides to do it.
> the implementation was pretty clearly pure Laravel, and the migrations ran without issue
Being able to refactor/change one part of the code without being afraid that something else might break is an excellent reason to use a framework. Once you understand how that framework works, even if a codebase is bad, you can know what and how can break if not implemented properly. It increases the visibility of "code smells".
> Being able to refactor/change one part of the code without being afraid that something else might break is an excellent reason to use a framework.
Yep. It's also more or less essential when something is subcontracted, like this was. In this case I think there were hard-working, competent developers who were burned by the original spec hiding a lot of undiscovered complexity, and what would have been a really good piece of work went inevitably quite wrong. The subcontractors clearly desperately tried to finish it within their parameters, and the result is something that met most of the spec but satisfied nobody.
(The framework decision they made wrong was in the front end, because there they made the disastrous choice to run with Angular 1.x -- which was presumably an in-house skill -- and not push to at least use 2.x. The resulting project is the precise kind of agony that Angular 1.x is famed for.)
Yep. It's also more or less essential when something is subcontracted, like this was. In this case I think there were hard-working, competent developers who were burned by the original spec hiding a lot of undiscovered complexity, and what would have been a really good piece of work went inevitably quite wrong. The subcontractors clearly desperately tried to finish it within their parameters, and the result is something that met most of the spec but satisfied nobody.
(The framework decision they made wrong was in the front end, because there they made the disastrous choice to run with Angular 1.x -- which was presumably an in-house skill -- and not push to at least use 2.x. The resulting project is the precise kind of agony that Angular 1.x is famed for.)
> on long term projects
Aren't frameworks harder to use in a long-term project if the codebase is not constantly updated to match the new framework standards?
For example, a code-base written in React (pre-hooks) is probably pretty hard to understand for a developer that has only learned React recently and uses hooks for everything.
Aren't frameworks harder to use in a long-term project if the codebase is not constantly updated to match the new framework standards?
For example, a code-base written in React (pre-hooks) is probably pretty hard to understand for a developer that has only learned React recently and uses hooks for everything.
There’s definitely an overhead in updating your codebase to work with new versions of the framework but the time saved by not having to write all the features yourself makes it worth it.
Can you give example of some features that you have to write that don't exist in a plain PHP application nor an external library (i.e. features that have to be tightly integrated in the core of the product)?
To be honest, I'm sure all the features of Laravel I use could also be done with external libraries, but researching and finding something suitable, hooking it together, configuring, integrating it into my project is something I am unwilling to spend time on.
I write code to solve problems for my company, so building a framework is very low on my priorities. I'd rather just use something that is ready on day one.
Maybe it's not to everyone's taste but I like the fact I can just get on with trying to build my product.
I write code to solve problems for my company, so building a framework is very low on my priorities. I'd rather just use something that is ready on day one.
Maybe it's not to everyone's taste but I like the fact I can just get on with trying to build my product.
There is often ongoing maintenance for sure, but if that is a concern a framework probably doesn't fit your project for other reasons already.
Frameworks are heavier, but in the same way a company gets heavier as it gets more professional and more complex.
I think your use case doesn't require a framework, so don't think my angle is to convince you that you do. Just that there is definitely a time and place for them.
Frameworks are heavier, but in the same way a company gets heavier as it gets more professional and more complex.
I think your use case doesn't require a framework, so don't think my angle is to convince you that you do. Just that there is definitely a time and place for them.
I wouldn't consider Laravel for this use case - I might consider either Laminas or Symfony though since those two frameworks allow you to pick and choose which features you actually want to roll into your project. If you'd like to simplify your routing files but otherwise leave everything else the same - Laminas and Symfony can do that trivially. If you find yourself forced into an ORM due to needing to support multiple SQL dialects, Laminas and Symfony can also do that trivially.
Laravel is a sort of all-in option that tends to perform worst when integrated into a legacy project - it isn't completely overbearing (it won't creep into absolutely every file you're using) but it will end up requiring changes to a lot more files than is reasonable.
Laravel is a sort of all-in option that tends to perform worst when integrated into a legacy project - it isn't completely overbearing (it won't creep into absolutely every file you're using) but it will end up requiring changes to a lot more files than is reasonable.
For me, its about the higher level things included. I don't want to write a queue, event system, or cache layer again.
That makes sense, there are probably some more complex use-cases, but for those I would personally not use PHP (e.g. if real-time communication is required or linking together many microservices and having to do operations that involve more than a database and file system).
Though for a small-ish site (say <150 users), such techniques are typically not necessary.
The PHP apps that I have created handle millions of monthly users without issues, so I would say that probably specific techniques are needed more to implement a given functionality instead of to achieve a better performance.
There are lots of reasons someone like you might benefit from a framework, but this one jumps out immediately:
> I already know how to implement core functionalities when needed (e.g. CSRF, user permissions)
Even if you know "how", this is still wasted time on your part. These are solved problems.
Particularly when it comes to security features like CSRF, relying on yourself to implement it sounds like a major footgun opportunity. When you use a framework that has this built in, you have to try really hard to bypass these security features. You barely even have to think about how to implement it.
> I already know how to implement core functionalities when needed (e.g. CSRF, user permissions)
Even if you know "how", this is still wasted time on your part. These are solved problems.
Particularly when it comes to security features like CSRF, relying on yourself to implement it sounds like a major footgun opportunity. When you use a framework that has this built in, you have to try really hard to bypass these security features. You barely even have to think about how to implement it.
Self-made frameworks are great as long as:
They work. If they are full of bugs they are a pain
They are complete. If they are missing parts because they weren't needed yet, they are a pain
They are documented. Documented well is a bonus
There isn't a self-made framework for every project at the company
The person who made the framework is still around
The person who made the framework didn't also make v2 and v3, mixing them in the same projectMy point was more that PHP is more of a framework-less language, as most of the functionality needed for a basic web application is built-in (file-based routing, secure PDO database access, external libraries for specific functionalities like PHPMailer for sending emails).
I think that if you need something a lot more complex than this (realtime communication, processing data in separate threads, linking microservices), then PHP is not a good choice.
I think that if you need something a lot more complex than this (realtime communication, processing data in separate threads, linking microservices), then PHP is not a good choice.
Sounds reasonable. (how) do you do testing (unit test and integration tests)?
I don't do unit tests (tried it, it was slowing down development too much).
I did have integration testing for a while for the core functionality, but in the end that was not helping much either, and after releasing a new version of the app I deleted the tests and (after 2 years) still haven't written new ones, without any bad consequences so far.
I deploy a new version to a beta branch, test it myself for a few hours/days (as I do use the app myself daily), then publish it live. Customers gradually upgrade to the new version and if anyone encounters an issue they let me know, and I fix it ASAP, but it almost never happens.
Also, the app is pretty complex, so writing tests for every use-case and environment is impossible.
I am not a big fan of writing tests when working in a small team (<5 developers). I did work on some pretty big projects that turned out great and very robust, without having written any tests.
That being said, if I ever have the time and am bored enough, I will write some integration tests, but mostly for the installation part of the application, not for the usage part.
I did have integration testing for a while for the core functionality, but in the end that was not helping much either, and after releasing a new version of the app I deleted the tests and (after 2 years) still haven't written new ones, without any bad consequences so far.
I deploy a new version to a beta branch, test it myself for a few hours/days (as I do use the app myself daily), then publish it live. Customers gradually upgrade to the new version and if anyone encounters an issue they let me know, and I fix it ASAP, but it almost never happens.
Also, the app is pretty complex, so writing tests for every use-case and environment is impossible.
I am not a big fan of writing tests when working in a small team (<5 developers). I did work on some pretty big projects that turned out great and very robust, without having written any tests.
That being said, if I ever have the time and am bored enough, I will write some integration tests, but mostly for the installation part of the application, not for the usage part.
> Also, the app is pretty complex, so writing tests for every use-case and environment is impossible.
No, you're just using the most expensive / error prone testing methods: doing it manually.
No, you're just using the most expensive / error prone testing methods: doing it manually.
Maybe my comment was not clear, I do not specifically test the app and all its functionalities. I use the app myself on a daily basis anyway, which acts like a sort-of continuous integration testing program. I use the new version myself for a few days before publishing it, or provide it to some chosen beta testers that use the product anyway.
How in the world is that better than automated testing? Rather than being sure that a feature didn't break, you're taking the chance that you or a beta user is going to hit the bug and report it back correctly.
Rather than spending hours on writing and maintaining tests that are very unlikely to catch any of the future breaking changes, it is indeed better for me than automated testing.
Could somebody say, if you are planning to embark on a new Laravel project and you have no experience, how to begin?
I bought a subscription to Laracasts, and there is a "What's New in Laravel 9" series. But "Laravel from Scratch" is still on 8.
I bought a subscription to Laracasts, and there is a "What's New in Laravel 9" series. But "Laravel from Scratch" is still on 8.
Go with the "Laravel from Scratch" on v8 to learn the basics. Then follow up with the "What's new in Laravel 9". I'll be updating to v9 this spring. Laravel has been pretty stable since they changed to semver for versioning (ie v6). The framework is fairly stable. They held off the v9 release so it could have the new Symphony components. A lot of features that would have been released with v9 were added to the v8 framework. v9 may have some breaking changes, but I'd have to really dig through the release notes to find what would affect my app.
I'm more concerned with updating PHP from 7.4.x to 8.x then the framework update. Our test env had issue with one of our blade templates when running under 8.x.
I'm more concerned with updating PHP from 7.4.x to 8.x then the framework update. Our test env had issue with one of our blade templates when running under 8.x.
Yep -- I am more worried about the PHP side because there you run into the question of whether other PHP devs whose packages you use are as good as the Laravel guys.
The Laravel from Scratch will still largely be applicable, the changes in 9 won't be breaking enough for you to be missing out a lot. The upgrades tend to be painless with a few small tweaks you might have to make (and those are usually described on the upgrade page).
If I were you, I'd start with Laravel 8.0 as you go through the Laracasts, and when done, go to the upgrade page of Laravel 9.0 and checkout the changes.
If I were you, I'd start with Laravel 8.0 as you go through the Laracasts, and when done, go to the upgrade page of Laravel 9.0 and checkout the changes.
Don't be afraid to investigate the other frameworks as well. Both symfony and laminas have a lot to offer and tend to be less all-encompassing. Laravel is the right choice to get something simple from 0 to 60 quickly, but if you need to do complex things or integrate legacy systems it can be a lot more punishing.
You could try LUMEN which is a lite version of Laravel. Took me around a day or two to fully get what was happening. I'm at the point now where I want to switch a big project I've been working on over to Laravel but it's a bit of a PITA.
Anyway, for hello world stuff or a small api project try beginning with LUMEN.
https://lumen.laravel.com/docs/8.x
Anyway, for hello world stuff or a small api project try beginning with LUMEN.
https://lumen.laravel.com/docs/8.x
Lumen is mainly feature complete and its mostly recommended to just use Laravel and unload the service providers you dont need.
Correct, Laravel + Octane is now recommended instead of Lumen.
I've onboarded plenty of people in the past couple of years to Laravel.
The changes from v5 -> v6 were the larger than most of the changes from v6 to now. Even then, those 5->6 changes weren't that bad.
You can follow along with Laracasts on v8 and upgrade to 9 when you're ready. It will be an easy transition.
The changes from v5 -> v6 were the larger than most of the changes from v6 to now. Even then, those 5->6 changes weren't that bad.
You can follow along with Laracasts on v8 and upgrade to 9 when you're ready. It will be an easy transition.
Also take a look at Code Course [0]. Good stuff and reasonable pricing.
[0] https://codecourse.com/
[0] https://codecourse.com/
Exactly 45 minutes ago I went on Laravel docs and saw the "you're on an old version of Laravel" message on the Laravel 8.x docs. Wow, I thought, Laravel quietly dropped a major release and I didn't even see press for it.
Don't forget to watch Laracon Online, tomorrow on Youtube.
Ooh thanks for this.
Can someone contrast Laravel with Symfony? Why would you pick one over the other when?
I'm just now learning (week 2) Laravel after coming from using other custom frameworks for years. For the record I have my own framework with a fully featured ORM of it's own and 99% unit test coverage for said ORM which is a fork of one my friend started 15 years ago and I have contributed to for several years. We started it before Laravel existed and in many ways it's exactly like Laravel. [https://github.com/Divergence/framework]
But anyway.....
So far what I like:
- Migrations
- The ORM is pretty good
- Query writer is aight
- Blade
- Mixx
- built in CLI
So far what I don't like:
- All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh)
- File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory.
- [php artisan] - each project should have a file in bin folder with a PHP shebang [#!/bin/env php] with +x on the file and linked globally so instead of writing php artisan you would write $projectName instead. Link it globally even.
- .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments.
- Docs aren't great. Eloquent needs a PHP.net -like page where I can see every single member function but instead I google and get the getting started docs which gloss over the best features. I have to manually sit down and read the source code.
But anyway.....
So far what I like:
- Migrations
- The ORM is pretty good
- Query writer is aight
- Blade
- Mixx
- built in CLI
So far what I don't like:
- All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh)
- File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory.
- [php artisan] - each project should have a file in bin folder with a PHP shebang [#!/bin/env php] with +x on the file and linked globally so instead of writing php artisan you would write $projectName instead. Link it globally even.
- .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments.
- Docs aren't great. Eloquent needs a PHP.net -like page where I can see every single member function but instead I google and get the getting started docs which gloss over the best features. I have to manually sit down and read the source code.
> "All routes defined in one single file instead of procedurally in each controller (performance wise this is terrible cause you're running a bunch of regular expressions on each and every request. augh)"
Have you timed it? And do you have a flexible alternative measurably faster that can drop in/ Are you taking in to account route caching?
Not everything has to be in one file. RouteServiceProvider gives you a place where you can programmatically determine which route files, if any, you want to process.
> File structure doesn't adhere to PHP league standard
So what? And... "all php code should in in src or tests..." That doesn't even seem to be documented anywhere. PHP code could live in /config (like... you seem to want above?) - but 'config' isn't /src or /tests.
Have you timed it? And do you have a flexible alternative measurably faster that can drop in/ Are you taking in to account route caching?
Not everything has to be in one file. RouteServiceProvider gives you a place where you can programmatically determine which route files, if any, you want to process.
> File structure doesn't adhere to PHP league standard
So what? And... "all php code should in in src or tests..." That doesn't even seem to be documented anywhere. PHP code could live in /config (like... you seem to want above?) - but 'config' isn't /src or /tests.
This article has and it's pretty bad
https://voltagead.com/laravel-route-caching-for-improved-per...
A good routing framework would not need to use a cache at all. Mine doesn't and I've built huge platforms with it. I say platforms cause my last big one was a website, 3rd party api, and mobile app back-end all integrated into one thing.
https://voltagead.com/laravel-route-caching-for-improved-per...
A good routing framework would not need to use a cache at all. Mine doesn't and I've built huge platforms with it. I say platforms cause my last big one was a website, 3rd party api, and mobile app back-end all integrated into one thing.
> File structure doesn't adhere to PHP league standard [https://github.com/thephpleague/skeleton] All PHP code should be in src directory or tests directory.
The PHP League Skeleton is only for packages. On the other hand, you use Laravel to create full applications so it's not applicable.
Even if somehow the Skeleton is so good its structure might be used for applications, we're under no obligation to follow PHP League's rules because they're just a private organization, not an authoritative source for standards such as PHP itself or PSR standards.
The PHP League Skeleton is only for packages. On the other hand, you use Laravel to create full applications so it's not applicable.
Even if somehow the Skeleton is so good its structure might be used for applications, we're under no obligation to follow PHP League's rules because they're just a private organization, not an authoritative source for standards such as PHP itself or PSR standards.
It's totally a preference thing which I admit. Personally however I think that all namespaced PHP code should go into src/$namespace. Config and tests directory not withstanding.
> - .env file - just use PHP files for configs which opens many possibilities like inheritable config setups. Instead of just dev or staging or prod you would instead have main, dev, production where main is env variables that don't change between environments.
Uh what, .env is standard practices for many languages even in docker. And Laravel doesn't prohibit you to extend the config folder with your custom settings. You can easily do both.
And for anyone who don't know yet, don't commit your configuration to the repo.
Uh what, .env is standard practices for many languages even in docker. And Laravel doesn't prohibit you to extend the config folder with your custom settings. You can easily do both.
And for anyone who don't know yet, don't commit your configuration to the repo.
That's actually kind of why I don't like it. Combining a Laravel project with docker makes you end up with multiple env files and it gets a little confusing.
You're getting it wrong. PHP's (and Laravel) getenv is getting the system's environment variable. .env is a helper that overrides them. It just helping you setup different env var for each project in same system.
If you're using docker, it's fine to just use docker's env_file or environment value, or use Laravel's .env only if you prefer it.
If you're using docker, it's fine to just use docker's env_file or environment value, or use Laravel's .env only if you prefer it.
I'll admit I'm not an expert, but using `php artisan route:cache` does provide some performance boost. About 5x in real world scenarios when dealing with very large route files.
Article with more info: https://voltagead.com/laravel-route-caching-for-improved-per...
Article with more info: https://voltagead.com/laravel-route-caching-for-improved-per...
I doubt the routes are evaluated with regular expressions on every request, more likely it’s matched based on an explode of /
I think quite a lot of the PHP routers are based on regexes, for better or for worse. One of the most famous is FastRoute by nikic that (from memory) merges all your routes into one big regex and then tells you which route to dispatch based on some index that comes back in the match. I don't know how widely that specific library is still being used though or if it's since been replaced by something better.
https://github.com/nikic/FastRoute
https://github.com/nikic/FastRoute
Anyone know if/when they'll push these changes to their micro-framework Lumen (https://lumen.laravel.com/)?
My sense is Lumen's eventually going to go away, with the heavier built-in stuff moved into optional packages like the starter kits at https://laravel.com/docs/9.x/authentication#authentication-q....
Update: Yep, straight from the horse's mouth. https://twitter.com/taylorotwell/status/1441101127496323080
I really, really need to look at Breeze and Jetstream.
Laravel is amazing until you need to do something non-trivial that does not follow the laravel way of doing things so you find yourself fighting the framework.
Everything is coupled to Eloquent for example, and while you can use another ORM, the whole ecosystem and 3rd party libraries need Eloquent, so you have to choose to either do things the Laravel way to take advantage of the community, or write everything on your own.
P.S: It's been 3 years since I used Laravel, not sure if things have changed.
Everything is coupled to Eloquent for example, and while you can use another ORM, the whole ecosystem and 3rd party libraries need Eloquent, so you have to choose to either do things the Laravel way to take advantage of the community, or write everything on your own.
P.S: It's been 3 years since I used Laravel, not sure if things have changed.
Why would you use another ORM?
I've worked once in a project where a very opinionated dev lead "decided" SQLAlchemy was better than the django ORM, so he replaced it. The mess he created was unbelievable, we spent years cleaning things up and some part we even couldn't.
> have to choose to either do things the Laravel way to take advantage of the community, or write everything on your own
Of course! that's the whole point of a framework, to put some guardrails on how to do things.
If you think you can do things better, more performant, more tested, and more documented, good for you, go ahead and just write raw PHP or tie together your own libraries. You can't blame an opinionated framework because bastardising it is not easy. That's a feature in my book.
I've worked once in a project where a very opinionated dev lead "decided" SQLAlchemy was better than the django ORM, so he replaced it. The mess he created was unbelievable, we spent years cleaning things up and some part we even couldn't.
> have to choose to either do things the Laravel way to take advantage of the community, or write everything on your own
Of course! that's the whole point of a framework, to put some guardrails on how to do things.
If you think you can do things better, more performant, more tested, and more documented, good for you, go ahead and just write raw PHP or tie together your own libraries. You can't blame an opinionated framework because bastardising it is not easy. That's a feature in my book.
[deleted]
Doctrine + graphqlite. It’s all you really need for a sane API, you don’t even need a router unless you just want one.
Laravel is great, but sometimes just overkill for simple tasks. That was the reason for me to start PHP Comet, it's like SlimPHP on async steroids:
https://github.com/gotzmann/comet
https://github.com/gotzmann/comet
All else being equal, how do we feel about Rails 7 vs Laravel 9 in 2022? Giving the breadth of both frameworks I am pretty certain there has to be one objectively better choice. Which one is it? Why?
I don't think either is objectivly better - if for no other reason than ruby and php being quite different languages.
Personally I much prefer ruby - but I could perhaps see myself reaching for Laravel for a project depending on requirements.
Personally I much prefer ruby - but I could perhaps see myself reaching for Laravel for a project depending on requirements.
As a Ruby developer I resonate with this. I love a LOT about the Laravel ecosystem, but I also still really love Ruby and Rails.
What requirements does Laravel meet that Rails does not?
Marginally cheaper/easier to deploy. Very robust queue system built in. Where you'd pay for Sidekiq in Rails, that's included in Laravel. Auth is also more streamlined since Laravel takes a stance on what the default is unlike Rails (though I admit most people just use Devise).
I think PHP is still faster as a language? There are also tools available now to run Laravel apps on serverless infrastructure if that's something you don't want to mess with.
I'll admit I'm biased and haven't spent much time with Rails outside of a hello world and various podcasts.
I think PHP is still faster as a language? There are also tools available now to run Laravel apps on serverless infrastructure if that's something you don't want to mess with.
I'll admit I'm biased and haven't spent much time with Rails outside of a hello world and various podcasts.
I'm guessing it's feasible to deploy to shared hosting for example?
I think Rail's latest take on frontend build tools is a great direction. They really messed up their Webpack integration in my opinion, and Laravel Mix isn't much better (but it is a lot easier to use).
Overall, I think it would just be a matter of which language you know better.
Overall, I think it would just be a matter of which language you know better.
Let's say I know neither. Which should I pick and why?
Ah yes, the world of everyone using a bespoke framework that almost always gets rewritten once the original programmer leaves a company is obviously the way forward!
/s
/s
What does everyone recommend for learning testing with Laravel?
The documentation is pretty straight forward. Just follow it and you can get it running in a few minutes.
Yuck.
I thought Laravel was dead. Well looks like some people still like to use these slow and bloated frameworks. I cant say i miss the PHP ecosystem of bloat.
I'll take the bait.
Laravel is far from dead; it's more popular than ever. The older versions that you might be familiar with have seen a lot of improvements over the last couple of years. They're fairly aggressive with deprecating older versions of PHP, while still supporting LTS versions.
Its ecosystem is really flexible, and generally has great solutions for anything web-related with easy configuration. I haven't found Laravel to be slow when building websites, but we always put a CDN in front of it, so it doesn't really matter how fast or slow the framework is.
If you want a lighter-weight core to start with, there's Lumen, which is designed to be an API-only version of Laravel. Forget templates, just return JSON (or whatever).
Laravel is a great solution for a lot of websites and applications. Maybe not some applications you have in mind, and that's ok. Pick the right tool for the job. As someone who used to hate PHP, modern Laravel would be my go-to if I need a backend and can't simply get by with a static site generator.
Laravel is far from dead; it's more popular than ever. The older versions that you might be familiar with have seen a lot of improvements over the last couple of years. They're fairly aggressive with deprecating older versions of PHP, while still supporting LTS versions.
Its ecosystem is really flexible, and generally has great solutions for anything web-related with easy configuration. I haven't found Laravel to be slow when building websites, but we always put a CDN in front of it, so it doesn't really matter how fast or slow the framework is.
If you want a lighter-weight core to start with, there's Lumen, which is designed to be an API-only version of Laravel. Forget templates, just return JSON (or whatever).
Laravel is a great solution for a lot of websites and applications. Maybe not some applications you have in mind, and that's ok. Pick the right tool for the job. As someone who used to hate PHP, modern Laravel would be my go-to if I need a backend and can't simply get by with a static site generator.
> If you want a lighter-weight core to start with, there's Lumen
It's been few years, but last time I tried it, the first thing it did was pulling close to 100 dependencies. I worked on few fairly large codebases (Symfony, Nette) and those were never even close to that. I realise it's not a good metric, but it really felt like an NPM project.
Has this somehow changed?
It's been few years, but last time I tried it, the first thing it did was pulling close to 100 dependencies. I worked on few fairly large codebases (Symfony, Nette) and those were never even close to that. I realise it's not a good metric, but it really felt like an NPM project.
Has this somehow changed?
I worked with Python (Flask/Django) for (4+ years) longer than I worked with Laravel (only 1 year), and yet I'm already 10x more productive in Laravel than I have ever been in Python.
Software projects follow Conway's Law, i.e. [1] the software architecture reflects the team structure. Laravel reflects the needs of business owners and one-man-companies because it is built by a business owner and has an ecosystem supported by one-man-companies who build high quality products for profit. I want beautiful high level abstractions AND a theoretically sound framework that is battle-tested in production. Laravel gives me both.
The number of headaches that Laravel just solves for me, out of the box:
0. Background Jobs/Queues/Rate Limiting/Retry logic handled by the excellent queueing framework
1. Rock solid server deployments/DevOps handled by Laravel Forge
2. Seamless version upgrades handled automatically by Laravel Shift
3. Backend-agnostic full-text search built into the framework with Scout
4. ORM which seamlessly enables caching, lazy loading, advanced subqueries, dynamic scoping, or just mixing in raw SQL when you need it
5. And there's just so much more. I live and breathe Laravel.
[1] https://en.wikipedia.org/wiki/Conway's_law