I write web applications rarely and reluctantly. I am not the most qualified to initiate a project based on the following ideas. If I did, it would likely  fall into a state of disrepair once my ephemeral attention has shifted back to playing with stock prices. However, I think it is a good idea. I am hoping someone who has both the time and interest codes it up. This is a new level of lazy.

var user_model = [
    // column name , generalized type,   , validation rule,   hidden?
    ['first_name'  , 'text'              , 'name_regex'              ],
    ['last_name'   , 'text'              , 'name_regex'              ],
    ['middle_name' , 'text'              , 'name_regex'              ],
    ['birth_date'  , 'date'              , 'over_18'                 ],
    ['location'    , ['double','double'] , undefined,        ,   true],
    ['addresses',  , 'has_many'          ,                           ]
];

Basically, from a Rails perspective, replace your ruby database migration DSL with code that parses the above JSON (e.g. user_model.json) and creates the appropriate schema. Replace your ActiveRecord validations with the validations from the json model. (Depending on your language, there may be differences in REGEX syntax. Having some well defined common REGEX definitions, such as EMAIL_VALIDATION, might be appropriate.) On the client side, you can display most forms automagically, based on the order defined in the json model (if it is in fact an array.) Furthermore, you can also run client side validations before submission. (If your validations are so weak that sharing them remotely represents a security risk, you are probably doing something wrong.) It might also remove the need for many controllers. A lot of CRUD is so generic that it might be possible to have a single /:model/:action/* controller. Scaffolding is not DRY. Finally, as the lingua franca, sharing model definitions outside your project’s language is simplified.

Any takers?

I consider myself a programming polyglot. I am proficient in five to seven languages and am competent in many more. Consequently, like many programming polyglots, I am a bit of a snob. PHP programmers tend to be unilingual or bilingual (Javascript). They are unenlightened. If you asked the average PHP programmer to explain a closure, they would probably express bewilderment. Brutes! Like I said, I am a bit of a snob (and the preceding text was satirical…mostly).

As is the case with much snobbery, this is ill-advised. Prior to PHP, I remember writing applications through CGI, mod_perl, or full-blow C extensions to Apache httpd. It was not very productive. Enter, PHP. From the beginning, PHP was designed as a template language to make web development easy. As such, additions to the language and its tool set were evaluated against a fitness function that emphasized ease of use and productivity for web development. At the time, it was the strongest solution to a problem of increasing prevalence.

Fast forward a few years. I had been out of the web development scene completely when a bout of temporary insanity inspired me to attempt building an online dating site (thanks, Markus Frind). Since I used Ruby extensively for non-webdev, Rails was my obvious framework choice.

Does Rails have advantages that cannot be replicated in PHP? Of course! The most glaring advantage of Rails over PHP is the fact that PHP is not Ruby. Ruby is lovely language. Seriously. Ruby allows you to think in code. It is incredibly productive. You can take very complex abstractions and implement them in Ruby with ease. However, web development is not very complex. Most web development is CRUD. Sure, Ruby might be slow (although 1.9 is looking nice) but most applications really do not require high performance. And when scalability does become an issue, Rails is rarely the bottleneck.

Do I miss ruby gems? Sure, but Pear works. Moreover, integration with PHP is often easier than it is with rails. When was the last time you noticed that popular api or library lacked a PHP interface? Most sites release official PHP libraries (s3, ec2, facebook, gdata, …)

Conversely, PHP has one several advantages over Rails. Most notably, immediacy. Deployment via SCP is very satisfying. Moreover, PHP now has many rapid-development frameworks that employ MVC and active record patterns (e.g. CakePHP). While you don’t have the elegant sexiness of Ruby, you have almost everything else.

Do PHP programmers tend to be weak programmers who produce mediocre code? Maybe. If so, it can probably be attributed to the law of large numbers. There is a virtual army of PHP programmers; there are very few DHHs. For large-scale, very complex problems it may be better to use a language that naturally excludes poor to mediocre programmers, but this is not true for web development. Besides, there is no shortage of criticisms of the rails community.

Finally, there is nothing to stop you from using PHP for the CRUD front-end and Ruby or some other language to do more complex heavy lifting (e.g. spidering, categorization, etc). It seems to have worked well for facebook.

echo "Hello, Old Friend";

UPDATE(OCT-27-2009 @ 1:39)

END_UPDATE
This post was motivated by an open-source project I am currently coding. It is not yet released but for the purposes of this footnote, pretend it will have a deployment pattern similar to Wordpress. I started writing it in Rails. However, after speaking with several people who will be end-users, I realized that the most important factor would be ease of deployment. While Phusion is a game-changer for deploying Rails applications, I think PHP is still easier for most web developers.

Also, for the sake of disclosure, I should make it clear that I am not an expert web developer. As you might notice from this blog, most of my work is in complex systems. Most of my time is spent writing code in C or C++ with Ruby acting as glue.