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.
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.
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.
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.
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
This content was originally published here.