There is this constant argument going on in the software development world between faster development times and faster execution times. Well written C will run faster than just about anything, but it takes forever to write. Developers can create apps in Ruby on Rails in practically no time, but the code is slow. Depending on who you ask, Java is either slow to develop or executes slowly. It is a no-win debate.
I have used the “servers are cheap, developer time is not” argument many times in the early stages of a project. It is true. However, you still have to be able to scale the app up to an acceptable level of performance. I usually have a plan for how to do that early on. For me, the perfect scenario is to use a high level toolset that allows rapid development and to use a deployment method that allows infinite fine tuning (which often comes in the form of turning dynamic code into static code). This is one of the main reasons I am such a big fan of JRuby. Rails applications are fast to develop and JRuby has the promise of making Rails applications actually execute fast.
When I first heard about the JRuby project I was enamored with the idea of Rails applications that used Hibernate as the ORM. (For those not familiar with Hibernate, it is a great Java package that provides a highly tunable and cacheable database layer, but it requires a shit-ton of configuration). The thing is, Rails works best when you use the components that come with Rails. Also, ActiveRecord is a very fast ORM for development.
Enter Merb.
Merb is a relatively new Ruby web application framework that allows for you to switch out the underlying packages as you see fit (i.e. decoupling). One of the ORM options for Merb is DataMapper. From the looks of it, DataMapper seems to have mostly identical method signatures as ActiveRecord. Now, I haven’t tested it yet, but it looks like a developer should be able to develop a Merb application using ActiveRecord and be up and running in no time. As the application design solidifies and the need for performance arises, it looks like developers would be able to swap out ActiveRecord for DataMapper and turn a fair amount of magic into hard coded configuration resulting in faster execution.
This is the direction I expect application frameworks to move in. Finding a way to provide rapid-development toolsets that allow developers to be up and running with base functionality quickly with dynamic magic. As the need for speed arises the developers can then go back and convert dynamic magic into static configuration. Sure, the code becomes less flexible at that point, but the alternative is to either spend more time and resources proving an application’s viability or suffering through Twitter-esque performance problems after a concept takes off.
It doesn’t look like Merb and DataMapper are necessarily ready for prime time yet, but I am excited to get some time to sit down and start playing with these.
Note: I have known about Merb for a while, but I just stumbled upon Nashville developer Brad Winfrey’s blog and it prompted me to take a closer look. I like what I see. Thanks Brad.
3 Comments
Catalyst ftw.
Hobo is another interesting project. It’s built on top of rails and gives you a lot more than rails if you just want a simple project up and running quickly. Unfortunately, everything they use is very tightly coupled.
That’s a shame because I think that Hobo’s templating system, DRYML, is better than using erb and partials. DRYML lets you create your own tags and the templates you come up with look a lot like HTML. But the DRYML tags are actually ruby methods. So, if you have a good HTML developer, then you can let them create the face of your site with DRYML and you can keep working on the backend.
On the filpside, trying to create your own tags in rails is a pain in the ass. You have the option of creating a custom formbuilder, but what happens if you want tags from several different form builders? You can overwrite the default tags, or maybe use alias_method_chain, but then what is the purpose of creating your own custom formbuilder?
Anyway, that’s some food for thought. I think Merb, Datamapper (w/ the validatable gem) and DRYML would be a killer combination. Routes and controllers from rails 2.0 could stay. Since they introduced namespaces the routing in rails has gotten much better.
Thanks for the props - and I couldn’t agree more about the directions of ruby web frameworks!
Hope all is well bro.