Sunday, March 20, 2011

Java vs. Ruby on Rails - It is a Dead Heat


For web technology entrepreneurs in the process of developing a new online service, there are five important choices that must be made regarding web technology. Some of the following choices have options that are mutually exclusive and others that are inseparable. I put server side language first, since in many cases it narrows down the options for the remaining choices:
  1. Server side language: Java, Ruby on Rails, PHP, Python, ASP.NET or other
  2. Database: MySQL, Oracle, PostgreSQL or other
  3. Web server: Apache, IIS, or other
  4. Hosting environment + hosting serviceWindows or Linux +Rackspace, Amazon EC2, Google App Engine, or other
  5. Developer tools: Eclipse, .NET Visual Studio, or other
The issues and pressures web technology entrepreneurs balance when making the aforementioned choices typically have this priority:
  1. Time to market: how long will it take to program the desired features, configure the hosting environment, and deploy the software. Some ideas need to be implemented quickly to capitalize on a time-sensitive opportunity. In addition, the sooner you receive feedback from your user base the sooner you can adjust your business model.
  2. Costs: on a tight budget, free open source software and cheap shared hosting environments are attractive. On the other hand, the licensing costs of enterprise servers and support may be what you need to scale your system.
  3. Long term scalability and growth: how many users can your technology mix support, will you need to switch hosting environments to support a rapid increase in user activity, and how quickly can new programmers learn and be productive with your technology?
In a nutshell, Java is not good for entrepreneurs because it is too complex and too slow to develop, configure, and deploy your web application. Ruby on Rails will get you off to fast start because it excels at time to market and low costs but leaves you hanging when it comes to scalability. Here is my entrepreneurial web technologies report card:
Time to Market:
  • Unit testing: both Java and Ruby provide comprehensive unit testing frameworks for testing objects.
  • Controller testing: I give the edge to Ruby on Rails because you can test your controllers (including aspects of your view templates) side-by-side with your objects without having to rebuild or recompile the rest of your web application. The Cactus Servlet testing framework and StrutsTestCase are not as easy to use as Ruby on Rails' controller testing framework.
  • Rapid feedback: Since Ruby is a scripting language you do not have to recompile (i.e., Java) your code in order to test your changes.
  • Code conventions: Ruby on Rails epitomizes the use of conventions while Java has lots of competing frameworks (e.g., Spring, Struts, JSF) that each like to invent their own conventions.
  • Developer tools: Eclipse offers outstanding developer tools for both Ruby on Rails and Java. Eclipse has slightly better tools for Java including more comprehensive code completion and code generation.
  • Code library complexities: Ruby requires much less thinking when comes to installing plugins, third party components, upgrades, and other libraries. Java library compatibility can be a circular (tail-chasing) mess, especially regarding XML libraries (i.e., JAXB, Xerces, Crimson). Specifically, it can get complicated trying to figure out the order that XML libraries are being loaded into the Java classpath. For example, I used to struggle to understand which versions of Java, Tomcat, and the web services libaries were compatible with each other. Upgrading one of the three might cause a problem with one of the other two. Ruby gems, albeit not flawless, makes it really easy to add and install new libraries and, what's more, the gem tool will prevent you from installing incompatible libraries.
Cost:
  • Software Licensing: Java and Ruby on Rails are can be configured to use 100% open source software and, thus, be free to use forever. However, it is likely that a successful online service will eventually need proprietary software regardless of your server side language. I give the higher mark to Ruby on Rails because Sun allows its proprietary enterprise partners to lead the way with many of the enterprise level software solutions requiring subscription or licensing fees (e.g., JBoss, BEA/Oracle, WebSphere).
  • Hosting services: In my experience, hosting Ruby on Rails is cheaper than hosting Java web applications but that both come a distant second to PHP hosting.
Scalability and Growth:
  • New developer learning curve: as a result of code conventions and limited code library complexity, Ruby on Rails has a much flatter learning curve for newly hired programmers. Specifically, a new developer can get up to speed with a Ruby on Rails web application really quickly by simply reading this book: Agile Web Development with Rails, 2nd Edition
  • Multi-threading: Java application servers allow you to run multiple web applications in a single process with the single process managing the multi-threading with minimal configuration. However, Ruby on Rails mongrel clustering requires that each web application have its own static number of mongrel threads. This a problem because the server's memory use is very inefficient. Specifically, a static number of mongrel processes for each of your rails applications means that daily or hourly fluctuation in site traffic could max out your one of your mongrel clusters or at the very least put an unbalanced load on one of them.
  • Service up-time: during deployment of an updated web application, some of the Java application servers can "automatically manage client connections so that existing clients continue to use the older application, while new client requests are directed to the newer application". On the other hand, anytime I installed an updated Ruby on Rails application, there would be at least 30 seconds where all of my mongrel clusters (i.e., multiple Rails applications) would be out of service. Obviously, I may not have been doing things the best way possible but the point is that Java makes it easier to maintain service up-time.
  • Clustering: In conjunction with multi-threading and service up-time, Java application servers provide comphrensive clustering capabilities whereas Ruby on Rails requires duct-taping Apache and Mongrel together.
  • Command line scripting: for data backups and other asynchronous processes has proven to be unchallenging for both Java and Ruby.
  • International language support: Java has native support for creating web sites that need to serve multiple languages. On the other hand, I have yet to see any international language support from the Ruby on Rails community. If I was going to do a multi-lingual web site, I would not choose Ruby on Rails.
It is a Dead Heat

The results of my entrepreneurial report card show that both Java and Ruby on Rails score a grade point average of 3.07. The report card GPAs resulting in a tie is merely coincidence and is not a product of report card manipulation.

More importantly, Java and Ruby on Rails can both fail you; albeit in different ways. Ruby on Rails can fail you on scalability and Java can fail you on time to market. On the other hand, Google's App Engine is very intriguing because it guarantees scalability and low costs. Unfortunately, it appears to sacrifice time to market because you have to learn and use Python. Specifically, Google encourages you to use their Python webapp framework. Therefore, expert Python developers using Google's App Engine may be able to score straight As on my entrepreneurial report card. Other than that, there does not appear to be a combination of technologies that can score high marks on all of the aforementioned entrepreneurial issues.

7 comments:

  1. I believe ruby on rails scalability problem can be solved with (http://www.heroku.com/) "Heroku (pronounced her-OH-koo) is a cloud application platform for Ruby – a new way of building and deploying web apps.
    Our service lets app developers spend 100% of their time on their application code, not managing servers, deployment, ongoing operations, or scaling"

    ReplyDelete
  2. Great article. Why do you score Ruby support for internationalization an 'F'? Looks like it is well supported (http://guides.rubyonrails.org/i18n.html?)

    ReplyDelete
  3. This is a reprint of a 2008 article of the same name. Too old to be of any real use.

    ReplyDelete
  4. I think a few key things are missing here.

    Ruby/Rails has a lot of "Gotchas". There are lots of times where you get silent failures, or weird errors.

    The documentation is actually quite bad. You will find 10 ways to do the same thing on various sites and blogs, but only 1 of them are correct. Sometimes books that are even 2 months old are already out of date. Ryan's Railcasts are often out of date today.

    Try developing in CoffeeScript with Rails 3.0.7 or 3.1pre right now, and it's actually quite a pain. It is hard to believe they are going this route in 3.1. As of today, it does not tell you what the compiler errors actually are like ERB does!

    Sometimes when you want to do something "complex", the "how" is very different from the "simple" use case. Maybe that is what makes Rails productive, but try making a 7-table join with ActiveRecord and be successful at it on your first try. You have a better shot of getting it right in Hibernate. I am not kidding.

    The ORM also leaves a lot to be desired. It doesn't cascade to children by default, and creates/updates work differently when setting new related objects to the object that is being inserted. It could learn a lot from Hibernate.

    I am not saying Rails sucks, but there are a lot of "gotchas" that will actually slow a new Ruby/Rails developer down. If you know Java and don't know Ruby/Rails, you will probably be better off with Java/Spring/Hibernate unless you want to learn Ruby/Rails for a specific reason.

    Ruby/Rails is also a lot slower. I don't care what people say. If you know what you're doing in the Java world, you're going to have a much more efficient system running on just 1 server than with rails.

    ReplyDelete
  5. I think there is another point missing in this (very good) article. The possibility to find good RoR-coders is a serious problem for entrepreneurs. Maybe if they code, they will be faster than a Java-Team. But in fact first you have to find the RoR-Coders, after launching, you need to iterate or to scale your product - finding coders is again a bottleneck. Of course, you can cure this fact by better planning reliability or higher costs. But actually, money and planning reliability is hardly a characteristic of entrepreneurs.

    ReplyDelete
  6. Why do you give rails an F on International language support?

    Site translation is built into rails through i18n libs. I think you need to read up on the i18n documentation for Rails. You can even have db backends for translations, making it a breeze to translate.

    I've worked on both ror and java multi-language sites, and I think RoR or Java are equally good/bad when it comes to translating a site. It all comes down to the the extensions you use for each of the platforms, as the native translation libraries are acceptable on both platforms, but not ideal.

    ReplyDelete