Technology Choices: One Decision Made

I've hit that pivotal point. The database design is done, the prototype is far enough along, and I've set my list of requirements. I now actually have to decide what to program this thing in.

And VOILA! It's PHP!

Actually, it'll be PHP5, to be exact. It was a tough call but I'll explain why it edged out everything else.

Cheap

That's right. You can't beat free. Even though I'm on the fence on going open-source, it's great that other people aren't. I'm a cheap bastard and PHP fit right in my price point. Now, theoretically, every language is just as cheap. ASP.NET is somewhat of the exception in that it requires a Windows machine which costs money (Yeah, yeah, I've heard about Mono)

Cross platform

Again, most of the languages are available cross platform so this, again, is a pretty minor point. But it's nice to know that what I develop could theoretically run on a PC, Mac or Linux box.

Popular

Here's where the things start to tip into a specific direction. PHP is wildly popular. There's a huge development community that has already developed a lot of the components I'll need to put my application together. Similarly, .NET has a popular community but fails in the above two points (again, yes, I've heard of Mono but Mono doesn't have the popularity of PHP).

It's nice to know that there will be a larger base of users to which I can discuss issues with.

Speed

Admittedly, I think all languages can be used to develop fairly speedy sites. But some languages (.NET and Java, in particular) are designed with certain programming processes. These processes build layer upon layer of code to make integrating and developing projects easier. This is fabulous from a developers point of view but not so fabulous from a performance point of view. There's a reason why both Java and .NET pre-compile the code to an intermediate stage and that's to improve performance.

Familiarity

Admittedly, this played a small factor. I picked a language with which I've had prior experience with to help lessen the learning curve. Trying to learn a new language would have slowed the development process down and I don't need to be doing that!

Big deal

To be honest, most of these issues are minor in the grand scheme of things. And in no way am I saying that everyone must use PHP for their web application. Use what you feel comfortable with but most of all, just think about the process and decide for yourself what works best for you.

Published November 04, 2004 · Updated September 17, 2005
Short URL: https://snook.ca/s/276

Conversation

11 Comments · RSS feed
MarkBu said on November 04, 2004

So my experiance has been with Perl and I was wondering if you had some comments about why you would choose PHP over Perl.

Marten Veldthuis said on November 04, 2004

You mention PHP, ASP.NET and JSP. Were these the only ones considered or did you consider more?

Reason I'm asking is because I recently fell in love with Ruby On Rails [1] which has a very open and friendly user base, and to me seems *much* more suitable for a enterprise-grade application like the one you're building. Great things about RoR are things like automatic ORM (only specify the relations between classes, *all* the rest is done automatically by RoR). It's also oriented towards helping you easily do things like unit-testing and functional testing.

RoR has support for MySQL, PostgreSQL, SQLite, and writing your own database adapter would probably take about 100 lines of code.

Ruby is available for about any operating system available, and RoR can run on any webserver supporting cgi, fastcgi, mod_ruby and it also comes with support for the Ruby-based WebRICK server.

I'm not saying PHP would be ill-suited, but merely wondering if you considered RoR and if so, why you didn't choose to go for it. (though ofcourse I silently hope it's not too late to convert you into a fellow Rubyist ;-)

[1]: http://www.rubyonrails.org

Jonathan Snook said on November 04, 2004

MarkBu: to be honest, I didn't take a look at Perl. It's been around for so long, I don't know anybody that actually develops in it anymore. Most I know have moved on to PHP.

Marten: I looked at Ruby but not RubyonRails. I had decided against Ruby because even though the language itself seems really nice, it isn't as popular as PHP (thus, not the same size of community to rely on). It also meant I could forego the learning curve of a new language. I'll look into RoR further, though, as it does look interesting. If not for this project, maybe for others. Thanks for the link.

Jonathan Snook said on November 05, 2004

Marten: I did some more research into RubyonRails and it MIGHT be a possibility. The largest problem that I might run into is my lack of single table inheritence. Now, it might be possible that I could build on top of the framework in such a way that the XML that I store in a field can be extended. But I'm not sure how the interface is generated so I'm not sure how easy it'll be to use (I still have lots of reading!)

Jason Jystad said on November 08, 2004

I'll be interested to see what you think. Please at least post a comment about you conclusions/reasoning with regards to Ruby on Rails. I have been looking at it for some upcoming web applications of my own.

Marten Veldthuis said on November 13, 2004

Jonathan: Single table inheritance is possible. What you do is add a 'type' column to your database table, and simply inherit from another model class. Then when you save your class, it will write it's classname to the 'type' column. So say you've got a class A and a class B:

class A < ActiveRecord::Base
# set your basic class stuff here
end

class B < A
# set stuff special to B here
end

If you read all A from the database, things which are actually of type B will come back as a B.

Jonathan Snook said on November 13, 2004

Sorry... I miswrote. It's the lack of multi-table inheritence that I'd have problems with. RubyonRails handles single table inheritence very well. :)

David said on November 30, 2004

When you look at the path between HTTP Request and HTTP Response back to the client... it would simply be much quicker to develop using an ISAPI, NSAPI, or Apache Module, rather than the scripting languages if you're after sheer flexibility and speed (Interpreted PHP Vs Compiled C++, no contest)

I am surprised at how quickly you knocked ASP.Net off, but granted, if your main targets are the PHP freeloaders (c'mon... they are! ;) ) then fair enough, but having a few years of PHP and recently taking up DotNet, I believe I'm qualified to say that ASP.Net is a better option for CMS Development than PHP

But hey... I don't know the projects requirements enough to demand that you use Mono instead oh PHP

Hope it goes well for you though :)

Jonathan Snook said on November 30, 2004

My hesitation with Mono as with Ruby had a little to do with how new each project is. I want to be sure that I'm building on top of a proven foundation. PHP is at version 5 and Postgresql is turning 8 soon.

And, as mentioned, there are simply just more developers who deal with PHP than a Mono environment.

Creating ISAPI, NSAPI or Apache modules would probably be a best case scenario for the reasons you mention but outside of what I feel I could take on right now.

And I hope it goes well for me, too. :)

Baris Balic said on December 05, 2006

Hey Jon,

Just wondered if you've done any comparative work between scripted and compiled languages and the speed at which they operate, I would be surprised if PHP were faster than .NET primarily due to the fact that more translations are going on. Although I agree there a number of levels to the composition of .NET specifically that might slow things down.

Jordi B said on March 15, 2007

Baris,
in php you can enable a cache for scripts once they have been compiled. In this case, there is not so big difference in performance between them.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.