PHP Easter Eggs

Does that really mean that 37signals use PHP for their site, or does it just mean that they have the PHP module active in their Apache install?

Sat, 04 Feb 2006 at 22:48:58 GMT Link

uh-oh, Ruby on Rails has been exposed. I guess they wrote the original site in PHP whilst developing RoR, which is understable.

Still, I saw the video, so if RoR is as cool as they make out, it should only take them 15 minutes to re-write it. Right?

- Davey

Sun, 05 Feb 2006 at 03:32:14 GMT Link

Wow. Why in the world would DHH be using PHP instead of ROR for their front pages?

Sun, 05 Feb 2006 at 05:55:19 GMT Link

...because he gets a lot of hits and he's smart enough to use the right tool for the job?

My guess is that they needed to do some very simple things like includes and used a few tiny PHP scripts to do it because they needed high performance.

Sun, 05 Feb 2006 at 07:00:25 GMT Link

Actually, the right tool for the job would be Rails' caching, which is quite capable of high performance.

Sun, 05 Feb 2006 at 07:11:33 GMT Link

This still requires loading the Rails base, which is a large body of intrepreted code. For high volume, the equivalent 4-5 lines of PHP for simple things like includes will always be much higher performance.

Ruby-on-Rails isn't the solution to every problem and liking it doesn't mean you have to frown on PHP. There will always be a large place in the world of PHP, especially for simple things that need to be fast. It's nice to know 37signals is pragmatic enough to recognize places where PHP makes more sense and apply it.

Sun, 05 Feb 2006 at 07:36:32 GMT Link

Isn't that kind o fa leak? Apparently, my php sites can output stuff that I'm either not aware of and also that maybe unwanted.

Sun, 05 Feb 2006 at 09:01:54 GMT Link

The 37Signals guys have commented before that there's no business value at the moment for them in reinventing the wheel for their support site/forum.

I'd guess that their home page falls into the same category.

PHP is a remarkably flexible language when it's cost-effective for a minor script on a static page and also cost-effective for a significant web-based application.

Sun, 05 Feb 2006 at 09:33:43 GMT Link

Before Ivo or anybody else gets into a lather over the implications of this, keep in mind that there is a well documented way to disable PHP exposing its existence.

In your php.ini change

expose_php = On

to

expose_php = Off

As well as its documented function, removing the PHP credit from the header, it also disables the easter egg.

Presumably if the RoR people were embarassed to be using PHP, they would have at least done the obvious and changed the filename extensions of their web pages. If they were embaressed and vigilant, they would presumably have also found the expose_php setting.

Sun, 05 Feb 2006 at 13:17:29 GMT Link

Mike Naberezny - Rails' page caching DOES NOT require loading of any Ruby code. They're straight-up static files, which don't get any faster.

Furthermore, in production environments, code is loaded ONCE with fastcgi/scgi.

Sun, 05 Feb 2006 at 19:06:39 GMT Link

With Ruby-on-Rails' caching, the request has to go all the way through ActionPack before the cached content is served by Rails. That's a whole lot of Rails code (hundreds and hundreds of lines) that the Ruby intrepreter has to execute only to grab a static file in the end. My point wasn't the time it takes to load the Ruby interpreter itself or even compile all the Rails code into Ruby bytecode, it's executing all that Rails code every request.

On every request, PHP still goes through the same execution process but it has a very large advantage here of not needing to execute any kind of framework code at all. An embedded include() in the HTML is all the engine tokenizes and executes, and that is a native language construct performed by compiled C code. This is extremely fast.

PHP powers Yahoo!, the world's most trafficked website, for these reasons. Here's an interesting presentation from Michael Radwin of Yahoo!:

http://public.yahoo.com/~radwin/tal...oo-zend2005.pdf

For a handful of pages that are almost entirely static HTML, like the ones on the 37signals website, you don't need a whole framework like Ruby-on-Rails. Solutions like Apache SSI or a few lines of PHP include() are a lot simpler and will always be much higher performance. This is the same reason why I highly doubt you'll ever see really high traffic websites like Yahoo! or the adult industry move from PHP to Rails.

I think Ruby-on-Rails is a nice system for developing small- to medium-scale web applications. For dirt simple tasks like we're talking about and raw performance, it can't compete with PHP and isn't designed to do so. PHP was built from the first day to excel at this kind of work.

It's all about knowing your tools and where to apply them. Be pragmatic enough to keep a big toolbox and apply each tool where it is most appropriate. Otherwise, you are only limiting yourself and the potential for what you can do.

Sun, 05 Feb 2006 at 22:49:43 GMT Link

Mike - Read my last post again. With page caching it DOES NOT have to load any Ruby, Rails, or other code.

Mon, 06 Feb 2006 at 03:19:53 GMT Link

Flat files in the document root (Rails' page caching vs. action or fragment caching) are no different than building HTML offline and uploading to the server. Looking at their site again, I agree that it appears to be a good candidate since it's pretty bare. For pages that are totally static (not "mostly static"), this is always the best option.

However, there's some shortcomings to the Rails implementation of full page caching to consider. For example, GET and POST variables will go to the static HTML page and never get seen by Rails unless special .htaccess rules are written. More importantly, it breaks down quickly because it doesn't work as soon as any tiny bit of the page needs to change. Most sites do something very simple like display your username and a logout button on every page, even if the content is mostly static. In these cases, you're back to the original point.

Mon, 06 Feb 2006 at 06:21:21 GMT Link

Do you even use Rails, Mark? What are you talking about GET and POST vars going to static pages? Routing takes care of caching pages with GET vars, and why would you cache pages that are POST destinations...

Mon, 06 Feb 2006 at 07:32:34 GMT Link

http://scottstuff.net/blog/articles...ion_with_params

Mon, 06 Feb 2006 at 08:14:16 GMT Link

Still... does the fact that http://37signals.com/index.php works mean they use php, or might they have a mod_rewrite? index.php is common so I'm guessing it could be useful to rewrite it to the real index file just in case? Might be a long shot, but hey!

Mon, 06 Feb 2006 at 12:23:47 GMT Link

For me it's much easier to just look at the headers instead of looking for the UID for the image link. You even get the exact version of PHP a site is using - i.e. 37signals:

X-Powered-By: PHP/4.3.5

Both, the header and the easter eggs, are turned on and off with the expose_php option.

Mon, 06 Feb 2006 at 12:27:16 GMT Link

I like the comment about every page request requires ruby to be loaded!!! I'm not an expert but even I read _some_ of the documentation.

Btw does PHP have builtin page caching now?

Mon, 06 Feb 2006 at 12:29:04 GMT Link

Use the right tool for the job. PHP for the simple Things in Life, and RoR for advanced Applications :-).

Mon, 06 Feb 2006 at 16:40:25 GMT Link

37signals are using Python as well. Chris what are you trying to prove?

You wasting time, instead of working on Zends framework a.k.a vapourware.

I wonder how much code have you actually written at that point? http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/.

Tue, 07 Feb 2006 at 00:13:57 GMT Link

No Chris. You're right with the Server header. But the X-Powered-By is only send if a resource is served by PHP. You can see it on your own page here. Only /archive/191 has a X-Powered-By header. All of the CSS stuff or images doesn't.

You could also read the source - it's in main/main.c in php_request_startup(), thus as long as PHP is not used for serving a resource the header is not set.

Wed, 08 Feb 2006 at 15:22:27 GMT Link

Hey, Chris ain't trying to prove anything other than they are actually using PHP for their homepages for some reason. It's all of it. I guess is is not any goog PR to do it counting on the obvious reaction of many people but hey, it at least proves that PHP is quite good to at least make it there and not get urgently removed in favor of their own thing.

Mon, 13 Feb 2006 at 05:42:16 GMT Link

I asked the good folks over at 37signals about their use of PHP. They responded, "We've been running PHP on our web sites since 2000 or so to do simple includes. It simple, it works, everyone knows how to use it, so there's no reason to change."

Makes perfect sense to me.

Tue, 27 Jun 2006 at 03:50:21 GMT Link

Wow, this is honestly an eye-opener, an eye-popper, an eye-something! I know it makes sense that anybody using Ruby would use Php for other things, but I mean THE CREATORS? Is like God drinking tap water.

Jenn

Ruby on Rails Professionals

Fri, 07 Dec 2007 at 22:31:25 GMT Link