Initial Impressions of Ruby on Rails: An Excess of Magic [1]
After a solid 24hrs of working on a school project involving Ruby on Rails I've decided that RoR relies on more magic that I really feel comfortable with. Admittedly, I've only been working with the language/framework for a short time so it's unlikely that I've "got it" yet, but it just seems that magically choosing the template and then magically packing up the controller's instance variables to provide context is just too much magic. The fact that the session and request objects are magically present and that the response materializes out of a method that as far as I can tell returns @user bothers me. Sure it makes getting that initial CRUD application running dirt simple, but once you want to actually start programing you have to figure out where this stuff comes from and goes to anyway (And then there's the generated code2). That being said, once I got a handle on the basic stuff, I essentially started writing Django applications using RoR :D. The fact that I've basically reverted to writing Django applications using a slightly different syntax and API probably says more about my relative level of comfort with Python+Django vs. Ruby+Rails than anything else.
One thing that does stand out as cool is RoR's use of Ruby as a template language. After all, if I'm a Ruby programmer and I like Ruby, using Ruby to write templates sounds like a great idea. This is exactly the reason that I'm not particularly fond of RoR's approach to ORM. If I'm a Ruby programmer and I like Ruby, wouldn't it be great to define my database schema using Ruby. Except that I don't. At least, not if I'm using Rails+ActiveRecord. I define my schema as a series of diffs, serialized as ActiveRecord calls. This approach provides some cool features, except that if I want to know what instance variables an object has I don't look at it's class, I look at the DB which doesn't feel quite right.
I think both Ruby and Rails could provide a productive application development environment on par with what I'm used to with Python+Django; however, RoR does not inspire a profound sense of "Oh-my-god!-I've-been-doing-web-apps-wrong-all-along." but that might just be the fact that I write MVC web apps whether I'm writing Python or Ruby or even Java. That being said, the project's not over yet, I may yet stop worrying and learn to love Rails.
| [1] | I fully realize that writing about Ruby on Rails was cutting edge about 3 years ago; however, I've only just started using it, so I only have initial impressions now. |
| [2] | I don't really like generated code. Not all code generators obviously. I like compilers and JIT compilers and even it's-a-code-generator-that's-logically-equivalent-to-a-compiler, but I'm really not a fan of here-I'll-generate-this-boilerplate-code-for-you which works fine until you realize that you should have generated the boilerplate code with option Y. Now you have to decide are you going to port your changes to a freshly generated template or are you going to port option Y to your current code? Neither of which is particularly attractive. In the case of Rails, I find that the code generation doesn't get you much and at the same time obscurs how the framework actually works. |