We had a long discussion about all of this over email (should have done that sooner) and here are most of the points for anyone reading this:
If you want to add a line in a twitter bio about Laravel, DO IT. If you want to put on your LinkedIn profile that you use Laravel on your projects, DO IT. You’re not hurting PHP. You’re helping it and anyone who was around during PHP’s dark days should know this.
I never suggested you shouldn’t do it, or that you would “hurt PHP”. I said branding yourself as a “Laravel developer” first is damaging to yourself. Lots of people branded themselves as a CodeIgniter developer for a while. What good has that done them now?
People will not be confused by this. Employers will not be confused by this. As someone who has probably looked at 1000 resumes for Laravel developers I’ve never seen even one where the only reference to anything PHP or development related is Laravel.
That took me one minute to find, by searching for Laravel. If somebody searched for PHP they wouldn’t find this same person. People really do need to put both.
If you’re trying to find a junior PHP developer in Utrech, or Cape Town, or Bath and the one developer that could be perfect for you is listing Laravel not PHP then your recruiter might never find them. If the recruiter or employer (remember some companies are not run by technical people) only know enough to know they need a PHP developer then they wouldn’t have a hope in hell of knowing that a Laravel or Lithium developer is perfect for the job.
There is always talk of other projects, other systems, PHP versions, on and on. Why would anyone have a resume or LinkedIn profile with literally ONLY Laravel on it. To me in fact, this is the most personally offensive part of this entire interaction. The assumption that people are so stupid as to need this advice.
I wouldn’t call them stupid, Junior Developers just don’t always know that much about how the careers world works. Yet.
Should you write your packages to be perfectly usable completely outside of any framework. In a perfect world yes, of course. Alas, the world is not perfect. So if you have unlimited time, resources or simply the desire to write packages which work in pure PHP along with the major frameworks DO IT.
Creating agnostic packages are not hard, and can save you time in the long run. Cartalist is an example of a company who were making some software, and along the way released some packages. They released them all as fuel packages because at the time they really liked Fuel and employed the lead developer of the framework.
Then they decided they liked Laravel more, so they had to recode ALL of their packages so they could use them with Laravel, as well as recoding all of their application. If they took the extra effort to make them agnostic then they’d save a bunch of time recoding, and not have to worry about supporting the old fuel ones too.
We both agree that if a package COULD be agnostic, it should.
“IF IT COULD, IT SHOULD” could be considered the overarching theme of the whole post and all conversations around it.
If you want to be friends with other Laravel developers DO IT. Want to follow their blogs, twitter feeds and learn from them DO IT. There is nothing wrong with this. In fact, it’s the very essence of human nature.
Of course you should be friends with other Laravel developers.
We’re interested in being around the people who are interested in the same things we are. We want to work together on those things. We don’t want to part of the faceless nameless herd.
PHP is not a faceless nameless herd, it is a community with names, resources and conversations that are relevant to everyone: not just Laravel. Especially as projects become more and more agnostic, learning about packages that anyone can use is important, but if folks have their heads down in “Laravel-only” mode they’ll never spot them.
It’s worse, much worse. Only a few short years ago we were there remember? Millions and millions of developers using PHP, but no fun, no inner communities that were excited and prospering.
A few short years ago would need to be 2004, in the “pre-framework” time. Frameworks have been dominating ever since then, with entrenched “inner communities” that were “prospering”. Also I know you like Laravel, but you can’t pretend that everything else was the dark ages before it.
Trying to make every meetup a PHP meetup is not the answer. In fact, we’ve already found the answer.
Didn’t say it should be.
Modern PHP is doing better than ever, we need to double down on what we’re doing not step back from it.
No idea how that is relevant. PHP in general is growing with modern tools and Laravel is seeing the benefits of that, not the other way around.
We Hates The Learning, Yes Precious We Hates It
Uhhh no, we don’t! The argument that you shouldn’t get all caught up in being a Laravel community because in 5 years you might have to learn a new framework is just silly.
I understand my wording was bad on the learning aspect. I said this:
“But the other concerns worry me. I don’t want any PHP developers wasting their time on tribal bullshit. I don’t want people having to spend time relearning over and over again.”
Developers are not (or should not) be scared to learn new frameworks. You’ll always have to change your tools and thats fairly common. But, if others make their packages framework agnostic then you drastically reduce the amount of relearning that needs to be done. The Laravel-OAuth2 package for example is obviously better off as a PHP-OAuth2 package, so if your next project uses another framework then you can use that same exact package and everyone wins.
I think the general theme of my blog was maybe too subtle. It was not a series of points to lead to one action: make the Laravel community merge with PHP in general. It was meant to be a series of things for people to think about to avoid shooting themselves in the foot, with code, packages, careers, etc.
The really important line in my blog came at the end, as it was a tl;dr for anyone too lazy to read the whole thing:
“I just ask that you keep that in mind when you are making decisions; developers and community leaders alike.”
You say a lot of the same things here. People should consider keeping agnostic things in mind for when they can, because there are benefits. That is what I wanted people to understand, and it’s what you are in a way helping to raise here.