DataCruxWeb and Rails

This was originally supposed to be a post about the design and implementation of DataCruxWeb, but I realized comparisons to Rails were inevitable and required some explanation, so I expanded the topic to a full post to get it out of the way now.

First, I need to be clear that I didn't set out to create something that competes with Rails. DataCruxWeb is something I developed to help me with my work. I'm releasing it because I think others might find it useful. I have no plans to try to base all development around what shows up in other frameworks. Of course it's open source, so people can do whatever they want.

Rails seems like a great framework, but I'm not an expert in it so I can't provide a in-depth answer as to how it compares to DataCruxWeb. That said, I think I can identify at least three high-level differences between the two:


1. A DataCruxWeb app revolves around a plain-text model file

The DataCrux.conf model file is used to generate tables and columns, validate input, set default sorting, and will be the basis for future features. By contrast, Rails seems to use the database itself as the primarily source of configuration information.

Personally, I don't like using the database for application configuration because you're somewhat limited by the expressiveness of SQL. I also like the portability of a configuration file. I do understand part of the reasoning behind the Rails approach, which is that you don't want to be bured in mountains of XML config files, but I don't find the database as a good solution.


2. DataCruxWeb is easier to deploy than Rails in many cases

Many discussions I've seen about Rails vs. PHP seems to compare the Rails framework to the PHP language. These discussions usually go nowhere. When I talk about PHP, I'm mainly thinking of it in terms of a platform for deployment. It's very fast and very easy to deploy. By extension, DataCruxWeb is easy to deploy.

I've mentioned this in other posts, but deploying a Ruby/Rails system isn't all that easy unless you're interested in FastCGI or lighttpd. Personally, I want to stick with Apache and I'm a bit scarred by past experiences with FastCGI.

We have number of DataCruxWeb apps running on extremely minimal hardware and the processor is essentially idle most of the time. I'm happy with this. Of course, I haven't pushed DataCruxWeb through a very high traffic site yet, so there may be more optimization to do.


3. You can use PHP to extend or replace behavior

PHP is truly the C of the web. Practically every web developer has had some exposure to it, and even those that haven't can pick it up quickly. I appreciate Ruby from a artistic perspective, but I can't expect everybody to drop what they're doing and learn a whole different set of syntax.

Now, being a Cocoa developer, I am sensitive to the idea of knowing when embracing change is in your best interest. I'm sure a number of developers would have been better off if they had just taken the day or so to learn Objective-C several years ago instead of sticking with C/Carbon. But there's a major difference in that Objective-C is a very small language with miminal syntax.

Ruby is the complete opposite — there is a lot of special syntax. On a level, I find this to be a lot of fun, but that doesn't necessarily mean it's something I want to use for production code, particularly when I work with people that don't share my tastes.

PHP's core functionality may be somewhat flatly designed (thousands of single-purpose functions), but its behavior is robust and predictable. If you understand one PHP app, you understand almost all of them.

This is a rather long-winded way of saying that adapting DataCruxWeb to specific needs is easy because everything is written in PHP. But more than that, it's PHP code that's written with a Cocoa/Objective-C mentality. For example, we don't have:


$pass = true;



Instead, we have:

$options[ 'shouldPassMainObjectToSuccessPage' ] = true;



Likewise, the utility functions look like this:

DCStringIsEmptyOrWhitespace()
DCContainsArrayElements()
DCUniqueIDForObject()



The constants look like this:

DCNewObjectRequest
DCSaveChangesRequest
DCEditObjectRequest



I've seen quite a bit of Ruby/Rails code that would make Cocoa programmers wince. I think these people will find the DataCruxWeb standards more pleasing.


Bottom Line

DataCruxWeb and Rails have different designs. Rails is a more mature framework simply because it's been around longer and has more contributors, but I don't think that makes it automatically better for all situations.

People that want to deploy PHP applications might find DataCruxWeb a better choice for their needs. Those that are more used to the Core Data / WebObjects model may also feel more at home with DataCruxWeb.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.