Hacking Startups

Jan 16 2009

Choosing a web dev platform: Rails or PHP?

When building your next web app, you can create value by improving existing web dev tools or by making a compelling app.  If you’re interested in making a great app, it’s best to use the best of existing tools and let others improve them.

Most web pages served today are produced by one of these platforms:

  1. Static HTML (brochure-style sites)
  2. C or C++ (search engines mostly, some backends)
  3. PHP (most high-volume apps)
  4. Perl (legacy high-volume apps)
  5. Java (many high-volume apps)

In addition, a large number of new apps are written in Ruby on Rails.  It does not account for a noticeable fraction of page views, but it does account for a large fraction of innovation. Then there’s Python.

Since you’re building an app, you can’t use static HTML.

Perl as a webdev language is obsolete.  It used to be the default during the infancy of the web, and large apps continue to run smoothly on Perl, but it should not be used to build new ones.

C should not be used for an initial implementation.  Instead, it can be used when the app needs to handle huge volumes to rewrite the critical bits.

Java is a matter of cultural fit.  If you say the words “enterprise software” with a straight face, plan to run Oracle on Solaris, and outsource good chunks of work, you don’t need me to tell you to use Java—you probably aren’t even considering other options.  For most web apps, however, and for almost any startup with technical founders, Java is a poor choice.

This leaves the choice at— Rails or PHP?

If you need to integrate with something in PHP, go with PHP. For example, Facebook apps should be written in PHP by default.

Rails allows programmers to work much faster, and is more pleasant to deal with.  If you need to hire, better people will be available to work on Rails.  This is because Rails is very high level.  The downside of high-level tools is performance.  It’s not just slower.  It’s much harder to make faster.

PHP runs about 40 of the top 100 sites.  It’s the default no-brainer choice, lower-level and uglier than Rails, but perfectly workable.  It’s easy to hire for, and easier to make fast.

To choose, consider these factors:

  1. Size of app, particularly UI: large apps are easier with Rails
  2. Size of team: small teams can do more with Rails
  3. Quality of team: PHP is easier to work with
  4. Need for change: changes are easier in Rails
  5. Expected initial traffic: high-volume apps are easier in PHP

Unless learning Rails looks hard or there’s a huge marketing budget in place at launch, consider Rails.