4 ms·
> 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 Rub
by Udo 13y ago
> 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.
- krapp 13y agowhy 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.
- Udo 13y ago> 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.
- krapp 13y agoDepending 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.
- 13y ago