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've been doing web development for 10+ years. Nothing else understands the needs of a business owner AND solo programmer like Laravel does.
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.
> 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 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.
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.
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.)
> 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.
> 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.
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.
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.
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
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.
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!!
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.
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'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'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?
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.
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.
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
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...
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.
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.)?
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.
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)
- [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.
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.
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.
[+] [-] _xnmw|4 years ago|reply
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
[+] [-] jw1224|4 years ago|reply
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.
[+] [-] pooya72|4 years ago|reply
I always find these technical decisions to be difficult to gauge when you're starting off.
[+] [-] cutler|4 years ago|reply
[+] [-] chipotle_coyote|4 years ago|reply
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.)
[+] [-] _xnmw|4 years ago|reply
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.
[+] [-] unfocussed_mike|4 years ago|reply
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.
[+] [-] munk-a|4 years ago|reply
[+] [-] defenestration|4 years ago|reply
[+] [-] riipandi|4 years ago|reply
[+] [-] KerryJones|4 years ago|reply
[+] [-] jordanmorgan10|4 years ago|reply
"So, what do you work with?"
"PHP mainly", he said.
I replied "That sucks, sorry man."
¯\_(ツ)_/¯
[+] [-] dabernathy89|4 years ago|reply
[+] [-] 0des|4 years ago|reply
[+] [-] jonwinstanley|4 years ago|reply
[+] [-] aarondf|4 years ago|reply
[+] [-] jackconsidine|4 years ago|reply
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.
[+] [-] geenat|4 years ago|reply
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.
[+] [-] subsaharancoder|4 years ago|reply
- 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!!
[+] [-] throwaway829|4 years ago|reply
A lot of Laravel devs use Valet instead of Docker.
[+] [-] Darmody|4 years ago|reply
[+] [-] ceejayoz|4 years ago|reply
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.
[+] [-] KerryJones|4 years ago|reply
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?
[+] [-] folkhack|4 years ago|reply
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?
[+] [-] TimWolla|4 years ago|reply
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.
[+] [-] ziggus|4 years ago|reply
[+] [-] celestialcheese|4 years ago|reply
[+] [-] hackandtrip|4 years ago|reply
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
[+] [-] masterof0|4 years ago|reply
[+] [-] ricardonunez|4 years ago|reply
[+] [-] sequoia|4 years ago|reply
[+] [-] dabernathy89|4 years ago|reply
[+] [-] mattl|4 years ago|reply
[+] [-] PZ81JUXJE7uJ|4 years ago|reply
[+] [-] e12e|4 years ago|reply
[+] [-] unfocussed_mike|4 years ago|reply
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).
[+] [-] XCSme|4 years ago|reply
[+] [-] daveaiello|4 years ago|reply
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.
[+] [-] jackconsidine|4 years ago|reply
[+] [-] exceptione|4 years ago|reply
[+] [-] neals|4 years ago|reply
[+] [-] deergomoo|4 years ago|reply
[+] [-] hparadiz|4 years ago|reply
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.
[+] [-] sibit|4 years ago|reply
[+] [-] ceejayoz|4 years ago|reply
[+] [-] chakhs|4 years ago|reply
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.
[+] [-] midrus|4 years ago|reply
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.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] withinboredom|4 years ago|reply
[+] [-] Ambix|4 years ago|reply
https://github.com/gotzmann/comet