During my college years, as a software engineering student, Java was the new kid on the block. Fortunately, I had a few visionary professors eager to tag C++ as something of the past and move forward to the wonderful world of “code once, deploy anywhere”. Most of the assignments were in Java, but we also tried other technologies such as C, C++, Cobol, OCAML… and JavaScript.
As soon as I started to work with JavaScript, I got the immediate feeling that it was designed with an hack & slash approach to get something done and should not outlive more than a couple of prototypes. No one back then was willing to bet the farm on JavaScript, but we couldn’t be more wrong. Twenty years later, our industry allowed JavaScript to move to the back-end and now it’s everywhere.
Table of Contents
Why Ruby on Rails in the first place?
The years following my graduation were, as foreseen by the university professors, spent coding in Java. I loved how Sun designed the language and Java VM, but I always questioned their over-complicated way of designing the Standard Development Kit (SDK). It seemed like they were eager to use every pattern in the famous book written by the Gang of Four, and the first contact with J2EE gave me the impression that Martin Fowler offered Sun the draft to his yet to be published book Enterprise Design Patterns, and they made a TODO list out of it.
The Java ecosystem was so over-engineered that it became a common practice to factor two weeks in a project plan just to bootstrap a slightly complex product. To make things worse, the entire Java community started to release over engineered frameworks, and the world gave birth to marvellous things like Struts and Eclipse RCP.
You can’t imagine how happy I was when I first bumped into Ruby on Rails, somewhere on version 1.x. It was easy to foresee that this was going to be big, and thus, the reason why we went full throttle on Rails when starting Imaginary Cloud.
I never liked scripted languages as I highly appreciate the work done by a compiler to detect typos and data type errors, but I’ve been looking so long for a good web framework that I fully embraced the Ruby on Rails promise. There was finally something able to allow a good dev team to fast deliver something more complex that a set of static webpages built in Dreamweaver.
Ruby on Rails took such a disruptive approach that the community exploded and almost every new project on the startup world was using it. Some of those startups grew pretty fast and validated that Rails was ready for scale. You can always find people saying that Ruby is slow and Rails requires a lot of computational resources, but by then, if you wanted to hit the market fast and still use the same codebase while crawling a hockey-stick shaped growth, more servers was always a good answer. Yes they were expensive, but this option was still cheaper than rewriting the entire codebase. And one could always re-engineer the sluggish components of a system in a more performant language. Ruby always integrated pretty well either via web API or shared library.
Why JavaScript & Node now?
Despite the great advantages of using Rails in a new project, there was an area where Ruby was not able to penetrate, and not even Rails was a good ambassador. I’m talking about the corporate world. There are of course some exceptions, and one can always point some successful corporate use cases where Ruby was adopted either for new projects or as a rewrite of existing ones in. But we’re still to see a mass adoption of the technology by well established companies. There are several reasons for this, but this opinion was developed based only on gut feeling and I have no clear data to validate it. Thus, I’m not going to elaborate on the reasons why Ruby is not massively used on the corporate market.
All things considered, I think this was a missed opportunity and the software industry now offers many viable options to Ruby on Rails. Some used extensively by startups (i.e. Phoenix), while others have some penetration on corporates because they’re built on top of technologies that corps already use (yes Django, I’m talking about you). But if you want to be able to help both corporates and startups, you can’t go wrong with JavaScript & Node.js. I’m not saying that Rails is not fit for purpose. Most of the times it is indeed fit for purpose, but not fit for context. And by context I mean our context – i.e. being able to work in an environment where both startups and corporates are willing to bet their future stack on. Although this is true for the former, it is not true for the latest. Startups and corporates love JavaScript. And in my view, the JavaScript ecosystem is mature enough to deliver all the good things that Ruby and Rails have brought us, and a lot more in areas where Ruby and Rails were never able to shine. Let’s take a look at the findings.
JavaScript & Node.js can deliver the same as Ruby and Rails
We did a thorough research on the Node.js ecosystem (through investigation and field work on a good number of projects) to identify the components of our reference stack. You might consider that some of those findings work in favour or against Node.js, depending on your goals. Your mileage may vary, but we’ve been able to find good solutions for things like database migrations, authentication libraries, admin / back-office extensions, automated testing, object mocking, etc. So far, there was nothing that we were able to do in Rails that was hard to achieve in Node.js. Our findings go in the direction that there is a replacement for almost every Rails feature or Ruby gem.
The JavaScript community is more active
Unlike Ruby, JavaScript dominates the web front-end, and with Node.js it became famous on the back-end. It’s easy to understand why JavaScript is more popular, but I also think that the community is going through a “cool” phase, similar to what happened to Rails in the early days. There is a lot of land grabbing going in the community, and this is driving a lot of innovation. But I also suspect that we will see some consolidation in the upcoming years with libraries and frameworks being left to die. Ruby on Rails community is also big and pretty active. But as Rails matured, it lost it’s cool factor and the community stabilised. This also means that we should expect less innovation.
Javascript can deliver native mobile, Ruby also, but…
We’ve used RubyMotion since the early days and published several apps in the App Store. I must say this was a great framework, developed by very bright people. The support for automated testing was remarkable. This was pre-swift and delivering for iOS in Ruby was much nicer than using Objective-C. But RubyMotion took an awful amount of time to support Android, and the “build once, deploy everywhere” promise was not possible by the time Swift came out. Swift’s syntax is much nicer than Objective-C, and it was a strong enough reason to stop using RubyMotion on new projects. You can still use it today, although the founders sold their business and it kind of stopped in time. I suspect that the framework was not able to get enough traction to enable it to keep on track with the innovation being pushed by Apple and Google on the iOS and Android platforms respectively.
And on the JavaScript corner you have React Native. It allows you to deliver native apps for iOS and Android. It’s developed by Facebook and heavily supported by a big community. Also, it’s free to use (RubyMotion is not).
JavaScript on the front-end, JavaScript on the back-end
Going back to what I said in the beginning of this article, my bet was that JavaScript would have a painful death. I couldn’t be more wrong. It’s remarkable how it managed to stay relevant all those years, up to the point where someone was able to execute their master plan and push it to the back-end. I still think there are big problems with the language, but then again, Rails became famous and Ruby also suffers from some design flaws. I don’t think anyone was able to highlight this better than Gary Bernhardt on his incredible lightning talk on CodeMash 2012.
There are considerable efforts being made to improve the language design with the latest releases for ECMA Script. But we still have to wait for a large adoption of the new releases in order to take advantage of it. There is also the option of using a transpiler like Babel, to use the new features available in the new ECMA Script Standards without sacrificing backwards compatibility for older browsers.
The fact is, you can now release a complex web and mobile project without the need to use several languages, and this helps reducing the development costs and, if you’ve been in the industry for long, you have to admit it. This is a pretty cool achievement.
Drawing a line in the sand
All things considered, for us, JavaScript is fit for purpose and context. We’ve officially stopped recommending Ruby on Rails for new projects and will opt for a JavaScript based architecture by default. Nevertheless, we will support existing Rails projects, as I think that the technology is mature, ready for production and it won’t die anytime soon because of its mature and stable community.
This content was originally published here.