I agree with you that WordPress and Drupal aren't examples of great code. It has to do with the fact that CMSes take a long time to gain traction and acquire a true community, and WordPress and Drupal were started at a time when MVC was almost unknown in the web community. By the time they got traction, the oldest code in the codebase was, well, ugly. Things that have been added to WordPress and Drupal recently are usually okay code-wise.
First of all, how it started isn't as important as where it is now. And what we have now is a full-fledged programming language. Secondly, if you can build large-scale maintainable websites with PHP, who cares how the language got started originally. It's all about what you can do with the language - and in that regard PHP is a great tool (although certainly not the only tool available).
"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -- Rasmussen Lerdorf, inventor of PHP
But to your point, he also said: "I've never thought of PHP as more than a simple tool to solve problems."
In the context discussed in this thread, "framework" means code that includes MVC, URL routing, and often an ORM. PHP in itself doesn't offer that; you need a framework such as CodeIgniter or Zend Framework on top. So no, PHP isn't a "framework" in itself (at least not in the way that Django is).
> it also has dead-easy deployment, cheap and reliable hosting
Matters for a single 15 years-old developer. Deployment is never easy when you get do anything non-trivial, and the cheap hosting... hosting for other languages start at $5 or $10... The only cheaper hostage PHP has is free.
> good documentation
That's highly debatable. I've also seen the PHP doc comments being pimped, I could never find anything worth more than a laugh in that cesspool.
Regarding hosting I wasn't just talking about shared hosting. Setting up a LAMP VPS is just a couple of clicks. Compare that to setting up e.g. Django or Rails. I personally love Django, Flask, etc., but setting up a website is still faster with PHP (depending on your setup, of course).
Try to instruct a noob on configuring Apache for vhosts or adding users to mysql then come back and tell me the deployment story for LAMP is so good.
Node.js wins for deployment if you ask me. Node.js + riak handily beats the pants off of the LAMP stack. It's so easy I'll tell you how to do it right now:
1. Install node, ./configure && make && make install
2. Install riak, make all rel && mv rel/riak /usr/local && export PATH="/usr/local/riak/bin:$PATH"
3. Install your app: scp -r remote:/my/app /web
4. Install dependencies: cd /web/app && npm install
5. Run your app: node /web/app/do/something/cool.js
Back to my coffee.
(I'm being somewhat facetious and these instructions don't get you startup services and such, but I do believe that Node.js stacks are much simpler than traditional stacks and easier for devs that have to wear the sysadmin hat too)
They'll be puzzled when they copy and paste something but their vhost still doesn't work because they didn't, say, enable vhosts in httpd.conf in the first place.
If they can install and configure Apache on a remote server, they can install and run node. I don't think it requires any more skill to copy and paste different commands into the console and you don't have to edit any configs or ask questions like "what distro? does your distro configure apache for vhosts out of the box? do you have an httpd.conf or vhost.enabled? run nano and hit ctrl-o to "write out" the file..."
Honestly though I don't think noobs do these things anyway. They will just ftp stuff into a directory on their host if they're using PHP. If they're using node I think the easiest deployment scenario is doing a git push. So practically speaking PHP is still the easiest for a clueless Windows noob to use.
To use WSGI (which is what most people would use instead of mod_python) you have to write some lines in your server configuration plus a script that loads your framework of choice.
Compare that to getting CodeIgniter up and running: SFTP the files into the server, and you're up. No server configuration needed.
One could argue that this is not a feature of PHP itself, but that doesn't change the fact that "normal" PHP solutions are simply faster to get up and running.
(Read my tone here is debatish and not di^kish plz)
In what circumstances does the fact that a Hello World can be setup in 5 mins versus 10 actually matter?
We spend thousands of hours developing software.
Five mins versus 10 is truly moot.
Besides, you're going to get into httpd.conf to configure a vhost before long -- mod_php or mod_wsgi -- so it's not as if it's a hands-off experience with PHP.
That's what I get for being poetic. I've done a lot of python development but not all that much for the web. When i have, I used Tornado. Which is also really easy to get running.
Yeah, Django and Flask are just as easy (if not easier, thanks to services like Dotcloud) to deploy as PHP.
Let's take your VPS example. Install nginx, gunicorn, and your database of choice. Set up gunicorn to serve your app, set up nginx to serve static and proxy to your gunicorn instance. Do any app-specific setup.
That doesn't take any longer than deploying a PHP app, at least not for me.
Several PaaSes support PHP, too, so no major difference there. In a VPS environment, however, setting up PHP doesn't require anything - it works right out of the box - whereas Django and Flask require more packages to be installed /and/ require some lines of server configuration and a script that loads your framework.
In a VPS environment, however, setting up PHP doesn't require anything - it works right out of the box
Well, you do need to install the AMP part. Since you're installing and configuring three components, why not install and configure different ones? It's not more or less work either way.
If you're talking about AMI/StackScript-style pre-built VPSes, there are plenty for various Ruby, Python, and Node stacks as well as PHP.
Since when were the 15 minutes you might save by setting up PHP instead of a reasonable software development environment worth more than preventing the years of torment and pain you'll suffer from choosing the wrong technology?
Nope. You have to set up a webserver (Apache or whatever) and PHP. Then (to get on par with Django+virtualenv practices level) get some PHP framework of choice...
Sure, PHP comes pre-configured out of the box. But there are no real differences between `apt-get install python-django` (comes with a development web-server, runnable as ./manage.py runserver) and `apt-get install apache2 libapache2-php`.
Exactly. There are tradeoffs to be made when making any architectural decision. PHP may not be the right choice for someone, but it might for someone else in a different situation that values the characteristics you highlighted. However, it is ultimately a potential hire's choice what they want to grow their experience in.
"If you're moving away from the US you'll see a significant drop in salary though"
Depends on whether you're moving from popular dev centers such as Silicon Valley or New York City, and of course it also depends on where you're moving to. My guess is wages here in Denmark should be able to match or beat US wages outside of Silicon Valley and New York City.
I'm foreigner studying in Denmark, and I'm curious, how are the dev/programmer salaries in Denmark? And if you have any knowledge, how is the marked for game development?
"The most important change is that most navigation elements continue to be visible even when you scroll down. The navigation bar, the search box and the search options sidebar have a fixed position"
Strange that "position: fixed" hasn't found its way to popular websites before now. It's been supported by major browsers since the early zeroes (or late nineties?), the only exception being IE (for which you can easily make a fix).
http://derstandard.at/ has fixed pieces of the interface for at least a few years but I really, really don't like it. Try it yourself. It looks good as long as you're actually not interested in the material inside. Unless you're designer of the site showing the features of the site to the boss, you're not likely to use the menus inside of the fixed areas. But this also explains why some sites end up having such interfaces. In my view, this is a sign of Google turning soggy inside as in:
Like all features, "position: fixed" can be applied in useful ways and in not so useful ways. I agree that Der Standard's way of using it isn't too good, but overall fixed positions are an excellent feature if you ask me.
