If you’ve scanned my blog in the past, you know that I am a big fan of Python and have been obsessed with Django recently, which to date is the most elegantly designed Web framework I have encountered. So far, other than using it on a very small project, I have mostly just been exploring Django and looking forward to using it on a more significant project that’s on my schedule for this summer. Unfortunately, it looks like I won’t be using it on that project after all, and the story behind it, which involves a good deal of office politics and my reasoning as I try to find a way through it, may be of interest to some.
Basically, my supervisor and manager came under significant political pressure within the organization to use a particular component–a Java based platform for content management–from several groups with their own hidden agendas. (Being any more specific might get me into trouble if anyone were ever to read this…) Although my supervisor and manager respected me enough not to dictate that I use this component, it was clear that if I didn’t my professional life and theirs would be made more difficult.
The component in question is large and complex and our organization has no past experience with it, so I’m anticipating a large learning curve, and new estimates for the project are much riskier as a result. Add to that the fact that this component addresses almost none of the project’s stated requirements, and the project I was once looking forward to is now just another soul draining exercise that we as software developers face all too often.
Although using this component doesn’t rule out using Django to develop its front end (there is no built-in user interface, you have to build your own by communicating with the component through SOAP based Web Services), Django is no longer an obvious choice to use for such development, and so, I decided to take a step back and re-evaluate the changing landscape of this project to see what technologies might better fit.
My hope had been that with this project, I could introduce Django into my rather technologically conservative organization and steadily move us away from slowly building overly complicated systems in Java and focus on meeting our users’ needs more directly and more quickly. Ultimately, I am starting to realize that this is not going to happen as quickly as I had hoped; I will need to continue living in a Java based environment (that ironically, I was instrumental in moving the organization toward in the late 90’s) for the foreseeable future.
And obviously, Java has many good points. Among them, there are many, very mature and robust, open source libraries for Java, and in fact, its the various projects like the Jakarta libraries that saved Java from imploding during the several years that Sun tried to push Enterprise Java Beans down our throats.
Java has been my primary language in my day job over the past decade, most of which I spent as a Web developer. I was an early adopter of the Struts framework, and was very happy developing in that environment for several years. Then I began doing more back-end programming in my day job at the same time that I began doing freelance Web development in my spare time and subsequently learned PHP and Zope/Python. Now that I am returning to a Web project in my day job, the thought of returning to a structured build/compile process for Web development and learning a large framework like Spring does not appeal to me at all. I have come to really respect the practical approach of PHP and the powerful, concise syntax of Python, and I miss these qualities when I program in plain ol’ Java in my day job. Ideally, I would like to have the best of both worlds: an agile language with powerful, concise syntax like Python (and without the explicit build step), with the capabilities of Java’s many open source projects that would allow me to interact with my Java environment. (Yes, Python also has many mature, robust open source libraries supporting it also, but I hate to say that Java is really in a class by itself in this area.)
I used Jython briefly several years ago. However, Jython has had a very spotty history, and although it seems to be getting attention again (because of JRuby’s influence), even at its height, it was always behind (C)Python and never reached its full potential. Then several years ago, Groovy looked like Jython’s successor, especially after Sun gave it its blessing. So Grails, “Groovy on Rails” was an option that I seriously considered.
But given Sun’s sudden endorsement of JRuby, seemingly at the expense of Groovy, and some reading that I have done that suggests that through JRuby, Ruby on Rails (RoR) can be transparently run in a servlet container like Tomcat, the question arose, why not just use RoR itself and program in JRuby, as Ruby is heavily influenced by Python?
I have some familiarity with Ruby, enough to know that I would like Ruby for the same reasons that I like Python: its a dynamic language with a powerful, concise syntax. RoR obviously has many adherents, and again, although my knowledge of it is superficial at this point, I suspect I will prefer it to the many competing pure Java Web frameworks for many of the same reasons that I like Django. My hope again, is that I will have a more agile, productive environment to work in while being able to integrate with my overwhelmingly Java based environment, essentially using JRuby as a glue for the Java components within RoR.
Now, I have heard the rumors of RoR’s lack of scalability and the slow performance of JRuby. However, in my case, this project is not mission critical, with a relatively small population of users that will not grow significantly, so even if these claims are true, I don’t expect to be affected. Besides, as a long time Java programmer, I tend to be skeptical of these types of criticisms–there are still some people who occasionally trot out this same tired claim about Java, refuted many years ago. Also, I think that performance and scalability requirements are often overstated to begin with–not many of us will be building the next MySpace or Facebook. I also think that these claims come from an overly simple understanding of the many, complex factors involved.
For me, and many others I suspect, “time to market” is a bigger consideration, as are the economics of maintaining what you’ve built. RoR and JRuby are still young, and I’m confident that performance and scalability will improve over time. With this choice, I am looking at Sun’s commitment to the development of JRuby and the widespread adoption of RoR, and I’m betting on the future.
So basically, I am trying to make lemonade out of the lemons I’ve been handed in this situation. I know that I will enjoy learning Ruby and RoR, because I always enjoy learning new languages and frameworks, both for their own sake and because it gives me a deeper appreciation for all languages and frameworks in general. I do feel sad about turning away from Django, and the fact that if I am successful, I may not return to it, but I hope that my time spent with Django will give me unique insight into RoR. As I’ve written here in the past, I think these two communities have a lot to teach each other.
I’d be interested in people’s opinions and reactions about the reasoning I’ve presented and the choices it has led me to. It’s my hope that the combination of strengths of JRuby, Java components and RoR will balance the programming flexibility and productivity I want with minimal integration issues. But I am still in the process of figuring this all out, and this is just the direction I am leaning toward. In particular, if people have used JRuby in Tomcat with RoR, I’d be very interested in hearing your experiences (especially bad experiences or “gotchas”).
Otherwise, here is a smattering of resources that helped influence my thinking about “JRuby on Rails”, in case you are thinking about this type of architecture yourself.
- Why Ruby on Rails is the perfect framework for building next generation Enterprise Apps
- Language Wars
- Ruby vs. Java Myth #5: It’s a zero-sum game
- JRuby on Rails
- JRuby on Rails: The power of Java, the simplicity of Ruby on Rails
- JRuby on Rails on JRubyWiki
- Advanced Rails Deployment with JRuby
- Deploying a Ruby on Rails application in GlassFish
- How to deploy a self contained Rails application on Tomcat, painlessly!