Exactly. This is not a feature of PHP, but simply CGI.

It's a feature of PHP because PHP isn't a compiled language. C, Java, anything .NET... They all require an added step in the middle.

You haven't done much asp.net development I take it?

Not for many years, no. I'd forgotten about it.

Still surprised I got voted down for that, since C and Java are still correct.

In fact, it's what I hated about Java web development the most... You had to compile, package, and deploy every time you made a tiny change. It was a nightmare.

Even in some parts of the Java world, that problem doesn't exist anymore.

The Play framework uses its own copy of the Eclipse compiler to compile everything on the fly while it is running in development mode...so as you as you save your changes, you can reload your browser and see them immediately.

There are frameworks for Java that doesn't require you to compile / package / deploy for each change. One example of this is http://www.playframework.org/

in .net you can run your site off source files, and the server will compile as needed

It's slower, right? I remember some years ago it would take like 5 seconds on this kind of big web app to show me the newer version of the file I just changed.

In production, or just your dev environment?

You technically can compile ASP pages on the fly in production but it's bad practice, just like making changes directly to production is bad practice. The whole blog post is pretty much a great write up of how not to manage a website.

Was I incorrect that he was talking about small sites, or do people just believe that every site regardless of size should use a deploy script and the other trappings of large application/high volume production development? Because the latter is silly.

He was but I don't think that's a valid excuse.

Doing a tested change and then a pushing to production is a 4 command overhead using git as lazily as possible with maybe an additional 5 minutes spent during initial project setup. You're doing the same coding work, you're just helping to ensure it's not going to create any completely useless work spent undoing mistakes. It's an ounce of prevention, pound of cure argument in my mind.

It's really not that clear cut. To do what you propose, you either have to set up an identical staging environment, or you have to set up a local environment that mimics (and stays in sync with!) the production environment. For a tiny site that sees <100 people a day, where the potential damage of a mistake is absurdly low (so what if 5 people see the broken version while you make corrections?) it's not necessarily worth the additional hassle.

This all depends on what kind of site it is, of course, but in the context of what he's saying, it makes sense.

With additional setup, yes, but PHP has a fast development cycle out-of-the-box which I think is significant.

This mind-bendingly important. In 1999, you could download one single installer on Windows, run it and with literally no further configuration you'd be writing PHP on an Apache/MySQL stack. No other environment even came close at the time and for a long time following.

This is still the main reason why I use PHP: the development cycle is just so fast, and if you are experienced enough to write good code without anyone holding your hand, you can do great work in PHP in a much shorter period of time when compared to most other platforms (at least the ones I've tried).

When people criticise the PHP language I think they really miss the point: it is the PHP platform that is really powerful because of:

1. The shared nothing architecture (it really helps you scale).

2. The rapid development cycle.

3. The portability (Apache, IIS, nginx, persistent in-memory interpreters via PHP-FPM...).

4. The huge amount of native C extensions providing amazing functionality.

Sure the language has warts, but who cares when the platform is this powerful?

As someone learning, I figured out pretty quickly from many forum threads about this topic, that I was simply too ignorant to be confident in writing solid PHP. I am in no rush to do anything useful (just having fun), and I'm trying to concurrently learn Vim and Git. so I chose Python. I might try PHP, if I ever feel I have learned to write OO code competently.

tl;dr: Too many gotchyas for a beginner. I need discipline imposed on me when I'm learning, ymmv.

Yep. And compared to Rails, something like mod_php is just so much faster and less resource hungry, it hurts. I use both regularly in production, and scaling the PHP side is almost trivial compared to the rails side.

Sorry to nitpick but that isn't scaling. Unless I can add double the number of machines and double or almost double the capability, and keep doing so to thousands of machine your application doesn't scale.

In the case of web applications all tend to scale equally well as you can just add another web server. Its the database that causes the scale issues.

Scaling vertically is still a valid strategy, and is scaling. Not every company needs to be able to scale to the moon, and if they don't, it's a poor use of time to focus too much on architecting for scalability.

With a lightweight PHP framework and a sensibly written app, you can stick to one machine for much longer than you can with Rails, and after that, it will require a fraction of the number of app servers. Beyond that, app processing time is generally much lower without all of that cruft, so you don't need to do as much caching, etc. to get a snappy webpage.

Maybe its just me but I don't consider "scaling up" as scaling. In my mind scaling means running on more then one machine.

Don't get me wrong though, throwing a bigger hardware box at a problem is a totally viable solution to most problems, up-to a point.