Triumphs of the Worse

I know I seem like an irrelevant dinosaur to you node.js hipsters, but there are some valuable lessons floating around there that the next+1 new hotness would be wise to consider.  They all stem from the questions: what were the popular web languages?  And why?


All of this was started when people realized they didn’t want to duplicate mounds of TABLE and FONT tags on every page of their site.  They needed some sort of template solution, where they could put a common frame around the content, and thus update all of the site by changing that one common frame.  But HTML doesn’t have any usable “include” mechanism, so people were forced to turn to server-side languages to compose the effect by hand.  (Or compile their own templates client side and upload the result, but server-side code allowing for live database access kind of sidelined that approach.)

Perl was the first such language to become popular.  Why?  CGI.pm: it was essentially the first scripting language that came with a convenient way to talk HTTP.  Perl/CGI was bloody inefficient but the capability to have a dynamic page was so alluring that people did it anyway.  Sysadmins would have (rightly) been horrified at the thought of either letting people compile C programs on their servers, or trying to support the myriad ABIs that existed, or worrying about needing libbobcgi.so.

PHP was next.  Why?  You didn’t have to surround your html with print <<HTML; and HTML (without indentation).  Instead, you surrounded as little code as you needed with <? and ?> and it worked.  In addition, it automatically pulled request variables right into real variables, so that you didn’t have those pesky $foo = param('foo') things all over.  That didn’t turn out to be a good idea, but it sure was convenient.  (Also, the arrays were also hashes and everything used $ instead of relying on subtleties.)

And that’s pretty much the peak of mainstream web development, isn’t it?  PHP conquered the world so hard that it spawned a core team, became a real language, grew up into PHP 5, which finally overthrew its biggest competitor—

What?

No.  Not Rails.  PHP 4!

PHP fairly quickly introduced mod_php, which tried hard not to leak resources, and also didn’t give away the server in the same manner as mod_perl.  (I remember discussing with Brian: “How would you run multiple mod_perl applications on one server?”  Our answer was pretty much, “Give each its own apache on a nonstandard port, and proxy to them from the server on port 80.”  Which is precisely how all you kids are building things now…)

PHP doesn’t do any magic, which means it stays quite understandable to the novice.  If you can figure out how to get a PHP script up to the server and then call its URL, it will try to run that script.  It never runs the wrong version from a stale cache, it never poisons itself with persistent variables from run to run, and it has a barge full of batteries besides.  If your PHP supports it, you can see it, no use statements required.

All of which made it even more convenient than Perl/CGI to support for sysadmins, with increased performance.  Relative to CGI.  IIRC, FastCGI was still somewhat esoteric and more complex to program for than regular CGI, which in the face of PHP being easier, doomed it from the start.  And though PHP theoretically performed worse than mod_perl, as I noted before, mod_perl cuts open the heart of apache, embeds the swiss army chainsaw right there for you, duct tapes it back up, and says, “OK. Your turn.”

Rails took the professional web community by storm, because it offered a lot of power disguised as easiness to someone familiar with coding web projects as a pipeline of “parse input → do something → pass data to template → render and output.”  Rails turned that into “do something” but you had to already understand much of web development for that to be obvious.  And with convention over configuration, you still had the option of configuration; if you needed power, then you could configure some up.

But it didn’t get popular like PHP, and after a while, it got enough users that backwards compatibility kept it from churning fast enough for the leading edge crowd, so they went off and built node.js.

So here’s the quiz.  Did you notice a fundamental difference there between Rails/node and Perl/PHP?  Or even Perl and PHP?

Speaking of things people love to hate, did you know MySQL set a goal of 15 minutes from download to running?  Whereas it probably took me that long to find out how to connect to my first postgres install, let alone figure out how to add a user for the website to use.


(This post is somehow inspired by Jeff Atwood on WYSIWYG but I lost the thread of how that fits in long ago.  Something to do with the inherent complexity of separating content, structure, and presentation, versus mingling them.)