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.
(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…)
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.
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.
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...
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).
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.
2. https://docs.laminas.dev/tutorials/getting-started/skeleton-...
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)
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.
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.
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.
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.
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.
> 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.
Free:
- Breeze
- Cashier
- Dusk
- Echo
- Horizon
- Jetstream
- Mix
- Octane
- Sail
- Sanctum
- Scout
- Socialite
- Telescope
- Valet
Paid:
- Envoyer
- Forge
- Nova
- Spark
- Vapor
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.)
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.
Tell me more. I remember when Rails was first released but missed that entire saga.
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.
- 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 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.
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.)