Our internationalization plattform Lingohub started as a side project developed solely with Ruby on Rails. I had troubles at that time translating the software I was working on. It became pretty clear that my vision of such a platform goes far more beyond what I could achieve as a side project. I teamed up with Markus Merzinger (@maerzbow) and Lingohub was born. Markus and I are both seasoned Java Programmers, we together have 20+ years experience working on small and really large Java programs. We both weren’t Ruby/Rails experts when we started Lingohub, but after working 2,5 years solely with Ruby/Rails I would say our Ruby skills are pretty solid. Nevertheless, we decided to move our entire code base from Ruby Rails to Java/Spring and I want to share with what drove us to do this (drastic) step.
Growing Pains
When we started, it was just Markus, Svetlana (Designer) and me. With Lingohub growing out of the Beta phase our team grew as well, but not easily. Finding good Ruby developers was extremely hard. The really good ones were already involved in some other startups and the rest wanted to start their own company. And of course the quantity just wasn’t there either. From a gut feeling I would order the availability of good programmers: Java, C#, PHP, JavaScript, Groovy, then Ruby. Of course someone could argue “Wait a really good developer doesn’t care which programming language!”. Kinda true, but everyone has their own weapon of choice and normally they stick to it, so we missed some good developers simply because they didn’t want to learn Ruby.
However, finding good developers was only one aspect. The main reason was working together. Ruby is a fun language and you can do really cool stuff with it, but I couldn’t get my head around it to really manage a large Ruby codebase. Especially, with other people working on the same. I always had the feeling that we never got the abstraction level right.
With a dynamic language like Ruby, a good test suite is crucial. We are having a great test coverage (over 3000 specs running on Codeship on every push). Nevertheless, some changes were made with the feeling “I hope I don’t break anything”.
Java simply feels more future proof.
I know companies working on a large Ruby codebase with many people and are happy. Maybe it is just us, but Java feels more future proof.
Tool Time
We switched from Ruby MRI to JRuby a while ago simply because we don’t wanna miss the JVM and its ecosystem. Hence, some parts of our code were written in Java and since beginning of the year, new code is solely written in Java. Java feels really good again and Boy did I miss a great IDE. I was a heavy power user on Eclipse. When I started Ruby/Rails programming I used Netbeans with Ruby support and ended up depending on Rubymine. Rubymine is great, but IntelliJ is just on another level. My code style is evolution driven. E.g. most of my variable names change 2-3 times till I think I got it right. The code refactoring of IntelliJ (and probably Eclipse and Visual Studio as well) is just such a productivity boost. Hands down, I never wanna miss great tooling again.
One thing I never understood about the Ruby community is the acceptance that no good debugger exists. “puts” have their purpose, but setting a break point, seeing what’s going, changing values on the fly, is just invaluable. The same applies to profiling. Honestly, I never tried Ruby profiling seriously because it just seemed too complicated. Java already provides everything we need including an acceptable UI.
I could write much more about tooling (e.g. FindBugs) and I probably will in other posts. There are just some things any developers just needs in his/her repertoire.
We prefer static over dynamic
I know there is no right or wrong in this, but I always liked to explicitly state what an object is or can be. It makes me think more about how to structure my code and it also provides valuable information when you read the code. I don’t know how often I had to look up the calling chain to exactly know what kind of object is coming in to a Ruby method. Of course you can document it (in Groovy you can force to check it), but doesn’t that defeat the purpose? Further static allows easier and more powerful tooling for IDE’s as well.
I picked a random example from our Ruby Lingohub code, went through and documented my thoughts on understanding it.
Ruby code is really readable, a lot like “normal” (prosa) text. However, this also means that Ruby code is as ambiguous as “normal” text as well! As a developer I want or better need to know exactly what is going on, this is why IMHO static typing is much better suited for coding.
Old or young woman? In Development you wanna avoid ambiguity.
Gems vs Jars
I love Gems and Bundler. I think it is one of the reasons why Ruby/Rails could hold on the last years. Bundler is just great and does nearly everything I expect from a dependency management tool. But Java has caught on. If you don’t mind XML, Maven is your choice, but the real competitor to Bundler is the Groovy-based tool Gradle. Comparing both I would still prefer Bundler, but Gradle just does fine.
Where Ruby defintely shines is with creating and publishing Gems. It can’t go easier than that. Bundler includes a Gem template to create the initial structure. In your Gemfile you set the local path to your Gem folder and voila you can use it. Gem development is really easy and smooth.
However, the biggest problem that I see with Gems is their quality and code activity. Don’t get me wrong, I really appreciate all the hard work that is done by the individuals that create these Gems, but the problem is that many projects are (actively) maintained by one guy. I have seen a couple of Gems inactive or simply gone because priorities of the maintainer changed. Most Java Jars are maintained by companies and also used by many companies. So even in the case if a company goes out of business, chances are good that another company takes over.
Rails is not an advantage anymore
When I first read DHH’s famous 15-min Blog post, I knew this was big. A lot changed since then. Web development became much more sophisticated and also complicated. User expect nowdays beautiful and extremely responsive web applications. This lead to new developments of frontend end frameworks like AngularJS. Since the beginning of this year all our new views are created with AngularJS and communicate over REST API with our backend. Saying that we are pleased with the end result would be a major understatement. As a regular Lingohub user myself, I know that the new UI just feels right. We even migrated some views to AngularJS just because a Rails view didn’t feel right anymore.
How compares Rails to other frameworks like Spring if just need REST? Not good. Development with Rails isn’t faster anymore. Frontend developers and designers are glad to use pure HTML/CSS/JS (with some GruntJS love) and the backend developers are glad that there are defined interfaces between controller and view (one of the weaknesses in Rails). Hence, frontend libraries made Rails a ‘normal’ framework. Not obsolete, but also not better than the others.
Despite all the above reasons, I am extremely thankful for Ruby and Rails. Using a completely different programming language and framework made me a better developer. And of course it made Lingohub possible and helped us getting started. We could quickly explore and create functionality. The reason for this article was to share thoughts on our current technology decision, which is definitely not the end of our tech journey.
Please use the comments to share you current tech stack and your experiences.
The post Why LingoHub is switching from Ruby on Rails to Java + Spring MVC appeared first on He. M. Ju..