Thursday, July 8, 2010

Rails3 and The Inevitable Fragmentation

I remember one of the early talks at the Canada On Rails in 2006 had a slide showing how many books one needs to read to be able to write web applications in Rails, versus Java.

Of course Java side had about 10 books: Java SE, Java EE, Hibernate, Struts/Tiles/JSF, WebServices, Ant, Maven, Eclipse, JUnit, etc, etc.

The Rails slide proudly showed the now hopelessly outdated "Agile Web Development With Ruby on Rails", 1st edition.

Those were the times. Back then, during my work for Blurb.com myself and three other engineers managed to learn ruby, rails and build a fully functional e-commerce site in about 3 months. I was blown away by the productivity gains compared to Java, where months could be spent laying out the project, and creating all necessary infrastructure for builds, deployment, automated testing with or without the database, etc.

Fast-forward to 2010. We are on a brink of Rails3 release, and oh boy, has the landscape changed since back then. I would argue that in some ways, you may be better off with Java than with Rails today for a couple of reasons:

  • Rails moves very fast. Books published in 2009 are already outdated. That pretty much leaves blog posts and online documentation as the main source of information.
  • Blog posts are not written as well as books are, they are not edited and are often heavily biased. They are also often outdated, and they are also often hard to find.
  • Rails now supports swapping out view renderers (from Erb, to Haml for example), Javascript libraries (from Prototype to jQuery, etc), ORM layers.
  • Testing frameworks are now (I think) approaching on a dozen. Forget Test::Unit, now it's all about RSpec, RSpec-Rails, Shoulda, Cucumber, WebRat, Selenium, TDD, BDD, ShmoDD. Hot Damn.
  • Finally, to make the matters "worse", it's become very trendy to replace RDBMS with a document-based databases such as MongoDB, CouchDB, or even a step further -- with distributed data stores like Cassandra or Riak. As with any trend, people are doing this regardless of whether or not they actually need it. Although this part clearly has nothing to do with Rails.

As someone who is trying to "quickly" catch up on all the recent changes that happened in the last 18 months during which I did not do any major rails development, it feels like I have to learn a lot of things from scratch, and unlearn a lot of things too. Even though I had three-four years of production Rails experience building Blurb.com and Infectious.com. That makes me wonder, how the newbies feel now joining the "new" Rails ecosystem. I am very curious to find out. I am guessing there is a lot of frustration and a steep learning curve required to master all the frameworks in isolation, and then bring them all together into the project. And that brings us back to where Java was exactly four years ago, and still is today.

I am not at all advocating for you all to go back to coding Java or COBOL :=) And I am absolutely not against Rails. But it's about time we pull the curtain of naiveté and realize that RoR has become the complex multifaceted enterprise framework it was claiming to replace back in 2006, and to become proficient in it may take just as long, if not longer, then with Java EE.

Ironic? I'll let you decide.

6 comments:

cowboycoded said...

Rails does move fast ;-) I would not say that is a bad thing, though. While the outdated tuts and blogs can be a bit frustrating at times, the benefits of the new version of Rails far outweigh the cons in my opinion. If you did Rails development for 3-4 years, I think you will appreciate what they have done in the new version.. and it will not be much of a learning curve for you. Take a few hours to look over the rails edge documentation, read McAnally's Rails 3 upgrade handbook PDF, and take a few days to play around with a Rails 3 app and I think you will change your mind when you see the improvements that have been made. Swapping views, testing frameworks, etc.. is a good thing in my opinion. The Rails team has decoupled alot of the core components as result of the merge with Merb. You can still use the defaults and if you don't want to stray away from Rails ORM, erb, etc.. now you just have more freedom if you prefer something like datamapper, haml or another testing framework. Its also much easier to create plugins, manage gem dependencies and the new query API is very nice. Seriously, take a few weeks to look it over and I think you will really like it. I was thinking some of the same things that you pointed out until I gave it a good look.

The newbies can stick with PHP for all I care. I don't really think Rails is meant for the casual web developer, and it never should have been marketed that way in the first place. Newbies need to learn OO and metaprogramming before they can comprehend and harness the power of Rails anyways.

just give it a good look man.. and please don't go back to java.. you are scaring me ;-) cheers

Anonymous said...

Keep Ruby and dump Rails. There are several excellent options available for building your own apps without being handcuffed to a bunch of "evangelists".

cowboycoded said...

"Keep Ruby and dump Rails. There are several excellent options available for building your own apps without being handcuffed to a bunch of evangelists."
That is like hammering a nail with your hand, when a hammer is right beside you. Wasn't the whole point of the decoupling in Rails 3 so that you can use what you think is useful in Rails, while still having the freedom to use other components outside Rails?? There are still plenty of things you can use in Rails 3 without being "handcuffed" to the rest of it.

More on decoupling here:
http://yehudakatz.com/2009/07/19/rails-3-the-great-decoupling/

Konstantin Gredeskoul said...

@cowboycoded -- Thanks for your comment! Very good points, and I didn't want to sound anti-Rails at all! In fact, I love ROR framework, and all the new features seem like a step in the right direction.

My main point was just to express some nostalgia for the time when things were simple, and a small team could pick up RoR in about a month, and build something very functional in three.

I believe that having the choice and plug'n'play is great, but it sacrifices this quick ramp up time. And I am not talking about newbies to coding, I was talking about experienced programmers coming to Rails from other languages.

And finally, Rails used to have this attitude which was demonstrated by the slide I mentioned. It was probably just a naive point to make at an early stage of the framework.

I am working between Java and Rails. Java is still great for multi-threaded applications which sometimes give you excellent platform from scalability perspective. Rails is better for too many other things, in particular it beats writing JSPs :) Each tool has it's job and Java hasn't fully outgrown itself like Cobol did, and Rails is still not the Golden Hammer. I guess that was the point :)

cowboycoded said...

I hear ya man.. point taken. I don't think there will ever be a Golden Hammer.. at least not in my lifetime. All kidding aside.. I spent many years coding in Java too and it definitely has its place in the enterprise. As does C if you are looking for pure performance. I have been playing around with Sinatra for the past few days and I really like its simplicity. It beats Rails for quick and simple apps in Ruby. I still use Rails for 95% of stuff I code and I guess I share that evangelical attitude sometimes, mainly because I think it is the best tool for most jobs (maybe not mission critical apps or apps that need top-notch performance), and as it matures I like it even more... I can't say the same for other frameworks like Struts or JSF

Anonymous said...

The problem with the Merb merger was that Rails got the wrong part of the team.