Ruby on Rails, PHP and/or JavaScript

Over the last quarter, I have been doing small scale investigations into Ruby on Rails as an alternative to the PHP/Drupal solutions that my company currently employs. Here is a slightly edited transcript that I gave our COO recently, concerning some of my conclusions.


Next Technology Update

As our company has been growing in revenue and opportunities, the available technologies we can use to administer new ideas should grow as well. PHP and Drupal development strategies may no longer encompass all our innovation needs. This report endeavors to evaluate Ruby on Rails and other technologies and recommend new skills and programming languages that our developers should seek to learn.

Even though the genesis of this report was to evaluate Ruby on Rails, upon completion of the investigation, capabilities and possible costs of moving to Ruby on Rail, another direction emerged. We are not yet ready for an endemic shift to Ruby, but a more complimentary move to incorporate more JavaScript/AJAX functionality in our sites would provide immediate innovation opportunities. The ability to validate though JS and/or return values using AJAX calls without page refreshes might be valuable conversion enhancing opportunities.

Also all AJAX and JavaScript solutions can be transferred to Ruby, Perl, PHP or ASP applications, as they are more client dependent than server/scripting language dependent.

Ruby on Rails, for better

Ruby, the programming language, and Rails, an implementation framework, have become the current web developer panacea. At least that is what the hype has been saying. Ruby on Rails has been touted as ‘the Rapid Development’ framework tool, as well a promoting, ‘using Ruby on Rail implies Agile Programming’. Obviously this is over-hyped promotion, but a careful analysis is still needed to determine if we should adopt Ruby on Rails as another tool in our toolbox.

Ruby is similar in aspects to PHP in that it is a scripting language that can process server requests. It also has a command line shell interface to run Ruby commands. Unlike PHP, Ruby is not a procedural language, but a purely object-oriented language. All functions and processes must be encapsulated in objects defined by classes. This is one reason people tout Ruby as such a great tool, since it forces object oriented design on the developer.

Rails is the development framework that has been built around Ruby. It consists of code generation tools, database abstraction and update routines, as well as providing consistent architectural patterns. Rails explicitly helps build code using a MVC (Model (data storage) – View (presentation/HTML) – Controller (logic/processing)) foundation.

The code generation tools help bring prototypes alive quickly, helping development customers see early where the application is going, thus speeding up the feedback loop. All of the database tools help keep the development and production systems in sync much better than Drupal or PHP frameworks do. Also the explicit Object based and MVC architecture helps instill good programming methods into all developers using the tools, making them better overall programmers.

Ruby for worse

But there are many costs to moving over to developing in Ruby.

The first is the long term learning curve needed to master a new programming language it associated library functions. Programming principle are always the same, but implementation in a particular language does vary. Also, a more to a purely Object Oriented language is a paradigm shift for most of us. We implement procedural code, which is very different from Object/Class oriented code. Many developers can take a while to master the waters of a new way of programming. On top of this, all the new Rails framework tools would have to be learned and mastered before efficiencies would be gained over the current PHP development.

Also, the hosting environment of Ruby applications is very different than PHP applications. Though both can use MySQL databases, Ruby natively works rather poorly on Apache based web servers. Setting up and maintaining either new servers or web processes would be required to roll out Ruby based solutions.

On the Balance

Code Generation
Systematized Development
MVC architecture enforced
Database update tools
Developer energy/synergy

Complicated hosting solutions
Long learning curve
PHP editing tools worthless
Must learn Object/Class programming
Less mature libraries/supporting routines (debatable)

Making a web front end to the reporting database project is an ideal Ruby on Rails implementation. Essentially a database information and report interface is needed, which is one of the tasks that Ruby on Rails is set up to tackle. Its inherent MVC architecture makes it a good database manipulation and reporting frontend.

Also, some of the pure PHP sites sites may have been made quickly by and experienced Ruby programmer. But only after the cost of learning the new paradigm has been paid.

If not Ruby, JavaScript

As I was concluding that Ruby is not ripe to us yet, I started to ponder exactly where should we go from here on a technology front. The obviously choice is the one that has been knocking on our door for a while, JavaScript enhancements.

If we want to pay the cost of learning a new programming language, we might as well learn one that does not exclude, but compliments, our existing applications. Moving from server side processing to client side scripting perfectly enhances how our business is developing. Fewer page refreshes and more dynamic content will hopefully translate into better waterfall numbers and over all conversions. Updated audit logs are another obvious candidate for JavaScript re-factoring.

Drupal is starting to swarm with JavaScript/AJAX modules ranging from search functionality, gallery/slideshow implementations, multi-part form integrations, dynamically tabbed content among other things. To either enhance these modules or to innovate our own solutions, we will need to learn JavaScript programming and AJAX processing principles.