I don't know if there's anything inherently wrong with them.
I'm just saying that I don't see any job listings for them as an interviewee, or see any resumes with them as an interviewer. In contrast to other technologies that HN or Reddit declare to be "dead" or "dying", yet actually seem to run the world with no serious disruption on the horizon yet.
Are you in the US? There are TONS of PHP jobs here in the UK (possibly second to JavaScript, although there are a lot of Java jobs too), and I hear that in general PHP is very popular in Europe, whereas Ruby is more popular in the US (some people use ruby here, but not many).
Laravel is not only fine, but one of the best frameworks I've ever used. It's like rails/django, but less opinionated in all the right ways (while still providing loads out of the box). I think PHP has a very bright future.
Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks.
> php artisan serve # laravel
> symphony server:start # symphony
Same poor thinking that NodeJS introduced, albeit less offensively integrated.
If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to remove the concept of tradeoffs for a "we know better" or "don't worry about it". These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
I can't speak for symphony, but that's just not the way it works in laravel. The "artisan serve" action is used when you want to make a quick demo (maybe). The actual deployment is in an apache server like everything else.
The rest of the actions that use artisan, for the most part, are for creating boilerplate code like database models or empty controllers quickly. They aren't a requirement to use the framework, but are faster and less error-prone than copy/pasting an old empty class file.
The last class of actions that call artisan are for things like cron jobs which you setup once and forget about. Their use case is pretty obvious once you read the manual.
> These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
That's nice to hear, but it's probably not true for the majority of people. The entire point for these projects is to allow programmers to create a rapid prototype for design purposes that can then be iteratively developed into a final product. If they don't make sense to you, maybe it's because you aren't working in that space, and not because the tools themselves are lacking.
