And you’re absolutely right about mixing HTML, CSS, and Javascript, however I think you read my post too closely. I was simply referring to how these technologies work in tandem, and not actually meshing them together in one script. That being said, I’ve found that some more advanced AJAX effects make holding to this rule darn impossible at times.

Keep in mind that the push these days is also to keep your HTML, CSS, and Javascript separate, for the long-observed obvious reason that mixing bits and pieces together gives you a mess of a file with some four different languages that all serve completely different functions. You can put CSS directly inline in your HTML, too, but for the most part we don’t, and there’s a very good reason for it.

Regardless, you don’t have to use this approach no matter what language you’re using. In Perl you can either print HTML the old-fashioned way or embed PHP-style with Mason. Python’s Mako lets you embed however much Python you need within your templates, but still supports very simple looping, conditionals, and expression substitution. Ruby’s rhtml is just Ruby embedded in HTML; if you really wanted to, I see no reason you couldn’t put your entire app in rhtml. Not that you ever should. But you CAN.

Also, do not compare PHP to Rails. PHP is a language. Rails is an entire framework, built with a certain paradigm in mind and meant to do certain kinds of work for you. Compare CakePHP to Rails, or compare PHP to Ruby. But don’t compare a raw language to a framework and then complain that the framework takes away too much control. You can do CGI-style web programming in plain Ruby just fine. If you really have such problems with frameworks, though, I suspect you either haven’t used them very much or have been trying to fight the one you used instead of working with it. Everything in the RoR MVC family is designed to be as flexible as possible and get out of your way if you really want it to.

Re Aston: I am not aware of a Linux distribution that ships without Perl, and most come with Python. I would also not call a language that drastically changes in functionality based upon the settings in some global file one that works well with *whatever* web hosting environment you happen to be in.

I also scratched my head a bit after reading that day’s post from Jeff’s blog (which I also read regularly). Curious to know why he randomly decided to flame a language he admitted to knowing little about. But, you know, whatever.

I don’t disagree with much of what he said either, but I think you’ve made an excellent case for why PHP is so valuable - flexibility.

If I’m a web developer and I have 100 clients hosted in all different shared hosting environments, I can’t depend on every server to have Rails, Perl, or C#. Some will, some won’t.

But just about every shared hosting service nowadays comes with at least PHP 4, so when a client needs an admin tool, CMS, shopping cart, or any other form of server-side scripting, I know I can always fall back the web largest common denominator to work well with whatever web hosting environment I happen to be in.