Programming Community Index for July 2013: PHP is regaining ground

As most people who use javascript aren't going to be developers but merely dabblers and jQuery gluer-togetherers.

But on the whole I agree with you, just that there probably aren't that many half decent javascript developers as you think as there's not a massive demand for them (something you'll notice if you ever watch the SO javascript questions, very low quality and some of the high answerers don't really seem to understand it properly either).

I've actually been half keeping an eye out for a javascript dev job and tbh 90% of the jobs I've seen when someone asks for a front end 'developer', they're asking for a designer that can use CSS and knows basic jQuery magic. Not a developer at all in my book.

Relevant: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

(PHP developer with 9 years experience. Now thankfully using Python for new projects, but still supporting PHP legacy D: )

PHP is easily and inexpensively deployed on commodity hosting.

PHP has a large base of existing code that can be re-used and built upon.

PHP has a large base of existing documentation that can be learned to get up to speed on it.

PHP has a large base of existing developers whose knowledge can be tapped into via services like StackExchange.

Most of these advantages aren't really intrinsic to PHP-the-language so much as they are to PHP's position in the marketplace. PHP is popular because it's easy to deploy, but it's also easy to deploy because it's popular -- hosts and admins are willing to put work into supporting PHP that they're less willing to put into supporting languages with smaller user bases, because the upside for doing so is so much bigger. But that doesn't mean they're not advantages.

On the plus side, PHP-the-language has gotten a lot better and more pleasant to use over the last few years. It's still got warts, as you note, but it's a long way from the incoherent grab bag of functions that it started out as. And while it's definitely possible to architecture-astronaut it (cough Symfony cough), it's also possible in PHP 5 to write reasonable clean, modern-feeling code without having to jump through a gazillion flaming hoops.

I'm about to start a new project that's a re-write of an old but still very popular PHP 4.0 site and I'm going to use PHP (probably the just released 5.5). The main reason is that I have limited time to learn another language/platform and PHP just isn't that bad. My PHP code looks extremely similar to my code in just about every other language I use. I have great IDE (phpstorm). I'm familiar with the gotchas and avoid them and I'm familiar with the advantages and I exploit them. I intend to keep things relatively simple while taking advantage of all the modern language features currently in PHP (closures, traits, generators, etc).

> PHP is now, in 2013, the only language that I work with that gives me no way to automatically create getters and setters for class variables.

That's actually pretty easy in PHP using the get and set magic methods. In my code, any method that starts with the word "get" or "set" can be accessed as a property. With traits, you can apply that code anywhere.

To answer your question about PHP: I think you're phrasing the question in a way that makes it seem more confusing than it really is. People aren't, generally speaking, drawn to PHP. People code in PHP, and have been coding in PHP, and change is hard, and rationalizing the familiar is easy. Those people then hire other people, and train them to use PHP. I would wager that for a majority of PHP projects, there was never even a 'choose what language to use' phase in the planning.

Edit: Another reason that I forgot to mention, which I've seen used several times in practice — PHP developers are replaceable. It's the same argument pointy-haired bosses have been making for using Java for a long time now.

I choose it regularly, although to be fair I also do web projects in Ruby on Rails or Node.js. To me there is no inherent reason not to choose PHP if the nature of the project fits it, it often allows me to get stuff done very quickly, with very little code, and (this might be surprising to some) elegantly.

PHP's per-request execution model is a strength that is often overlooked by people who are mostly using persistent application servers. Starting with a clean environment at every request can be a huge advantage, especially in large projects where PHP allows you to selectively load only what you need. This can be used to severely limit code complexity and unexpected runtime behavior (in addition to the more obvious points such as better resource management).

Language-wise I wouldn't say PHP syntax is pretty, and the standard library is very uneven. There's also some weirdness with the parser that should be fixed. I hope there'll be a reboot that addresses these, but sadly this would probably not come from the PHP core devs. At the same time, "recent" language features have made developing in PHP fun again. For example, I couldn't imagine doing PHP without anonymous functions.

On the flip side, some OO features are superfluous to the point of being a liability. Also, and this is me departing from the party line even further here, framework envy has bogged down PHP by zapping its strengths and unreasonably emphasizing its weaknesses. With the exception of light-weight MVC frameworks, more heavy-handed RoR "clones" and object-relational silliness tends to kill performance and severely hinders developer flexibility. Of course, some newbie developers probably should be prevented from exercising flexibility, but I'd argue that PHP isn't suitable for them in the first place.

You said that PHP is going toward increasing complexity, but I'd argue that this is more due to the proliferation of complexity in its ecosystem - which ultimately comes from importing unsound ideas from other languages just for the sake of making PHP development seem hip and legit by (badly) emulating counterproductive features. Again, this might be unpopular, but for example: why should a PHP app use a templating engine when PHP itself is one? I can see this is justified when unprivileged users are editing the templates, but this case can't possibly account for all the Smarty (and worse) misuse that is happening all over.

People like to switch between languages and frameworks as if nothing changed, but I'd say they're wrong. Building stuff in Node.js is fundamentally different from Rails, which is fundamentally different from PHP. Use the right tool for the job, don't bend runtimes to do something they're unsuited for.