> What draws people to PHP now? I loved it once but I can not imagine choosing it 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.
why should a PHP app use a templating engine when PHP itself is one?
It's just cleaner, and makes it easier, visually, to separate layout from code. Wordpress seems to be a good example of the opposite case -- it switches directly between PHP and html and there are no 'templates' to speak of, in the way Smarty/Twig etc. people would think of them. It is 'closer to the metal' I guess but also for anyone who's had to edit a theme, really ugly.
Personally I find just not having to worry about context with opening and closing PHP tags and echoing variables (and manually escaping everything) worth the extra bit of abstraction involved with a templating system, which will do the work for me.
> It's just cleaner, and makes it easier, visually, to separate layout from code.
That's true, and I think PHP would be better for it if there were three kinds of files by convention: pure code, layout, and entry points that are actually callable (the other two shouldn't be invokable by typing in their URL). It's trivial to configure a webserver to handle them differently, but it's impossible if you're writing code that needs to run everywhere.
However, I would not say that {$blah} is that much more readable than <?= $blah ?>, not to the extent that the complexity and cost of running a separate engine is justified.
Depending on how the code is structured, it might not matter much either way in terms of legibility (assuming the sight of something like
if($foo){
?>
<b> <?php echo $bar; ?></b>
<?php
}
doesn't set your teeth on edge to begin with), but I do think the former is easier to type and maintain which in PHP to me counts for a lot.
Then again I never use the short tags so i'm adding at least those three characters of overhead per variable anyway. Also, having the views inline couples them to whatever logic they happen to be in, so the templates are less portable. A lot of templating engines will meet you halfway and compile down to classes so they don't reinterpret the templates each time. YMMV I guess.
Yes, but if you're using short tags, things can be better ;)
<? if($foo) { ?>
<b><?= $bar ?></b>
<? } ?>
True, it's not as nice as a templating language, but then again, it doesn't have the aforementioned limitations either. Inlining views is a choice, it tend to avoid this. Just because templating engines prevent this pattern doesn't mean you'll be forced to use it in plain PHP.
Re-interpreting templates is also an interesting case. Of course, native templates will pretty much always be faster so the need to cache isn't as pressing. But still, with the built-in output buffer functions it's easy to do something like
I was playing around with Slim framework recently and I 'discovered' the option in the PDO driver to fetch into a class. Add a parent class to the data classes (with magic setters and getters, having the getter wrap everything in htmlspecialchars)[1] and you really can, probably, accomplish most of what a lot of templating systems do (and a good chunk of MVC with the serial numbers filed off) with a fraction of the code in most frameworks and, say, Twig.
Even static caching probably, using output buffering.
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.