It has been two days since I posted an article on auditing data modifications using the Zend Framework. I have recently published a number of other articles on Zend in general. I noticed a recurring statement that forced me to rethink the pursuit of using alternative frameworks for openEPRS:
“X is easier with Ruby on Rails than it is with (insert language and/or framework)”
When I started openEPRS in 2007, Ruby on Rails was the chosen platform. I liked it because it was easy to learn, concise and held close DRY development principles. It really is an amazing framework, one that is truly a disruptive platform.
Java and ExtJS
Being a Java developer by trade, I became intrigued with the first releases of Java RESTful Web Services (JSR-311). At that time I also started experimenting with ExtJS as a user interface for openEPRS. By the end of 2007 I had become increasing frustrated with amount of time spent on managing converter, resource and data classes that come with using Jersey. ExtJS also seemed to be in a state of flux with a flurry of license changes.
Analysis: high effort and maintenance
There is not a lot to say on the subject of Mono. I tried to develop a basic application framework using ASP.NET. Monodevelop is a non-starter as an IDE, broken functionality and a lack of action from the developer community on reported bugs.
Analysis: valiant effort with a lot of missing functionality
PHP and the Zend Framework
I turned my attention to the Zend Framework in the Fall of 2008. I thought that this approach would provide an environment similar to Ruby on Rails with the added benefit of a widespread deployment platform that is PHP. I was quickly disappointed as I found that it was much more difficult to implement a basic starter application in Zend than it was with RoR. Unit testing, security and build control while available, required a lot of experimentation to make it work as expected. Honestly I was not that impressed with the quality of much of the code. In particular Phing was a major source of frustration requiring a number of patches to get it working correctly.
Analysis: awkward language with the framework having a higher degree of difficulty than necessary.
A major reason for exploring alternatives to RoR was the issue of scalability. When I started using RoR, a lot of concern was raised as to the scalability of the framework. I knew that Java could scale and the same could be said of PHP. With the advent of projects like Rubinius, I am not as concerned with this as much as I was in the past.
openEPRS development will go forward on the original platform of choice. I will be dusting off my old Rails code, updating it to version 2.0 of the framework. Straying off the path has not been all bad. I believe it makes my decision to use Rails an informed one. At the very least I cannot be accused of being zealot as I have put in quite a bit of effort with the alternatives. I know this article does not provide a detailed analysis; however, other articles on this site make the case. Its good to be back!