The only argument I can think of is that you already have a team of PHP experts and they don't want to transition to Ruby, Node or Django.
Prior to taking up Laravel and Vue, it was becoming monotonous to build out websites.
However now with Vue taking up the bulk of work and relegating Laravel to effectively an API for:
- authentication and roles.
- database layer for retrieval and submission
- server side validation
- gateway to the message queue
Fact is, there's so little to use PHP for. I have contemplated moving to GoLang (and may do so in the future). But there is a reason why I stay with Laravel. It's just far easier and far quicker for me to code in PHP than using Javascript (node), GoLang and Python. Couple that with using composer which is a decent package manager. I can iterate very very quickly and have reliable robust code.
Of course, you can argue that the same can be achieved with Rails, GoLang, Python, Javascript, etc, etc. That's great, stick with what works for YOU.
I'm simply not going to put any effort in learning Rails or getting better at another language I know.
I'd rather put in more effort to building out more features and grinding out what matters and that's making sure code turns into $$$. Which is something I think we can all agree with. Use the best tool that you can work with that will do the job well.
But honestly, the main reason is that you can find PHP developers everywhere and they are cheap. Given that you want to build a project that grows and advances, that is maintainable, for which you require a vast ecosystem to kick-start your ideas and a lot of very good tooling and free sources of knowledge, you won't find a better platform than PHP.
Ok, Perl might be an alternatively hugely developed language but it is really complicated to find new developers for it. In contrast, you will find a lot of developers, testers, sysops that have the knowledge for working and administering the PHP tech stack. Yes, you could use the coolest language but how would you be able to pay super expensive Go/Kotlin/Node developers once your company has left start-up mode and is there really any gain from that? The risk to be betting on a dying horse might be too high or, less dramatic, everyone is just cooking with water.
If you want to earn money from your company and not just sell your expensive personell at some point it makes sense to start easy and advance the people you have. If you are building API based systems you are not locking yourself in a technology anyways. Given how flexible and fast-moving technology is today one could probably also find a good argument that you absolutely should always base your projects on PHP.
But now instead of exposing it as html pages, you expose your django/ruby models using an api like graphql or rest. So then you can use all new fancy js frameworks like react or vue.js.
Ruby and Django developers are as around as much as PHP developers.
So I'm not a PHP developer anymore, and haven't been for years. Neither is anyone else with options, I'd guess, unless they've found some rare shop that pays real money for them, which I'm sure do exist. I don't actually hate the language. It's OK for what it does. It's a helluva lot less yak-shavey than most of the other popular web languages, so that's nice. I'd work in it again if it paid alright and I wasn't worried the next role wouldn't (that is, that I was killing my earning potential by gaining yet more years of experience in it).
Anyhow.
One of my favourite things about the Ruby community is that nobody would ever suggest that we're popular because we're cheap. I don't want to work with people that are an easily replaced commodity. Nobody good is cheap.
Do you realize this sort of thing is no longer a reflection on the language (folks are immune to it). For people who want to hate just to hate, why are you here on HN? Seriously, go find a subreddit to flame on.
It should not be negative to ask why someone might choose a PHP framework given so many other options.
I do find it amazing how little credit Rails gets from other framework communities given how many of their features are directly lifted from concepts that Rails originated or popularized. It's possible that Laravel developers don't know migrations came from Rails, for example.
Anyhow, if you're asking about my opinion, personally... don't confuse hate with pity. I've had to make some changes to a Laravel backend for a client project lately, and if you honestly believe that it's nicer to work with than Rails, we have different working definitions of nice.
For a few cases off the top of my head where PHP/Laravel > Ruby/Rails IMO:
- Waaay less magic in Laravel. Controllers are explicitly named, and views are explicitly rendered from methods (Unlike in Rails where everything can be done based on the naming convention of the files).
- Ruby/Rails has too many ways of doing the same thing. Laravel is quite streamlined in that regard. A big part of this is Rails abusing meta-programming IMO (for example, compare ActiveRecord vs. Eloquent).
- I find Laravel's documentation to be top-tier - I rarely have additional questions after reading the relevant sections. And there's official built-in support for a ton of 3rd party services (e.g. Stripe subcriptions).
- Some support for static types in PHP (better than nothing, but nowhere near where I'd like them to be).
- Blade > ERB IMO. Less noise + easier to read. And again, explicit calls to view.render(["var" => $var]) vs. implicit @var insntance variables tacked on to the controller.
Apart from that, PHP is:
- Less prone to memory leaks due to it spinning up a process/thread per request (which can be quite a big advantage - since it means you don't need orchestration overhead for smaller projects).
- Fast enough that performance isn't really a concern (compared to the amount of stories I've heard about migrating away from Rails due to performance problems - I've never heard the same about Laravel).
It feels to me like Rails blazed the trail for developer happiness a few years ago - but these days it seems like a bit of a relic.
The improvements in both the language/community plus how people are using JS since The Good Parts was quite a significant improvement.
But people largely went through that whole process because of the ubiquity of browsers not because JS was a good idea. There are so many better alternatives on the server side for web, I don’t see the point in PHP going through that whole renovation unless it’s to hire more and cheaper developers.
and may be being cheaper to hire is a bigger importance than you'd care to admit. After all, the person paying the bills wants it to be as low as possible whilst still achieving the result. And they call the shots.
PHP developers are cheap because in general they're very junior. Junior Javascript developers are cheap too.
As compile-to-JS has matured, many of us have switched to things like TypeScript. That kinda ruins your glib analogy.
But Javascript is compiled in the browser, by many browsers, and so is hard to nail down an environment.
PHP runs on the server which is pretty much a fixed environment. It has more options to it yet it feels like it hasn't made use of it.
Weird, because thousands of developers are extremely happy building with Laravel.
EDIT: ok sure, it won't scale as well as Lambda without extra work.