Why We Build Your Web Applications and Startups Using Ruby on Rails
People commonly asked us why we use Ruby on Rails and not other frameworks like Python Django, Java Spring, etc. Many people would expect a framework feature-by-feature comparison answer from us and sadly, we do not really provide that. What we usually share is the culture, community and thinking of the Ruby on Rails community that makes it the winning combination for web applications and startups.
Rapid Development
First off, we need to understand that startups generally have lower budget and limited time. A startup has a new idea and normally it is not validated (at least not thoroughly yet). The startup would not want to spend more than 6 months to build the idea. That’s too long and too costly to do so. If the idea failed, the startup would have wasted a lot of time and resources. So a startup typically needed a way to develop their idea (or at least a prototype) fast that is good enough to go to the market.
Ruby on Rails fits in very nicely for rapid development because one of Rails’ principle is convention over configuration. This means that Rails will choose a lot of ‘common sense’ configuration by default so that the developer can quickly jump into coding the application instead of wasting hours setting it up. As an analogy, to create a website you would need to setup 20 different configurations before you can start coding your first homepage. Would you prefer to set 20 configurations manually one-by-one or use a default set of 20 configurations and just change the ones that are different from the defaults? Most of other frameworks would require the developer to setup all 20 configuration before the developer is ready to start coding on the real functions of the application. Rails lets the developer to just jump straight into coding and start doing the real work.
Convention Over Configuration
In a bigger picture, convention over configuration also helps tremendously in setting the development culture for the startup team. Every developer has his/her own style of coding. This makes working together on the same code base for more than one developer a nightmare. Over time, the different of style of coding by each developer will make the code base more and more fragmented — eventually reaching an unmaintainable state. Convention over configuration forces developers to keep to the same coding convention and makes the code base readable for any Rails developer to work on. This is essential for growing your own development team.
Through convention over configuration, Rails adopts many common best practices in every succeeding version of Rails. For example, Rails added the asset pipeline in Rails 3 which optimises the way static assets are delivered in production site. By making asset pipeline a default in Rails, all developers are “forced” to use this best practice. From a startup perspective, this is great because your application will be up-to-date with the latest best practices. In case you are wondering, there is always an option to turn off or change the default configuration of Rails.
Rails continues to adopt more best practices such as russian doll caching, secret keys management, etc. This continuous improvement in the framework translates to best practice adoption in your web application and development. Developers learn and improve along with Rails. This provides good continuous education to the developers to ensure that they are up-to-date with the world’s current trends and practices.
Test Driven Development
Other than a limited budget and time, a startup is almost always changing and adjusting its strategies to fit to the market. Combine that with the nature of software development which by itself is a fluid, ever-changing and endless refinement process. And now your startup web application is constantly undergoing small refinements (at best) to major overhaul (at worst). To manage a constant evolving software, the code base itself must be able to adapt to changes. Is anyone familiar with the problem of “fix one bug, two more new bugs appear” whenever you are adding refinements to your web application?
To prevent bugs and issues from surfacing while maintaining an evolving code base, we need test cases to prevent regression bugs. Not manual test cases, automated test cases. Automated test cases are test cases that we can run it from a command and it will test the web application automatically, quickly and painlessly. Imagine it as a computer software that automatically tests your applications to tell you if it is working correctly. Test cases ensures that the additional code that the developer has added does not cause more bugs in the application. This allows the code base to evolve without suffering from previous bugs or issues. This also gives startups a great peace of mind especially during those times where they are launching their web application to the public.
We really think that test cases are cool and wonderful — the salvation to evolving softwares. We think that everyone in the world should adopt it. But in reality, it is not really adopted by many frameworks and developers. In this respect, Ruby community is one of the most staunch adopters of test cases. Ruby developers are testing fanatics. Ruby community has such a large number of different testing libraries that Ruby developers are arguing among themselves which testing libraries or styles are better while developers in other frameworks are still arguing whether they should have test cases or not.
“Writing tests for units that are small and do only one thing is a real pain and feels unnatural. On the other side, writing units that are not small and do more than one thing is very simple — only much later you will feel the pain. Thus, working test driven puts the pain up front, and therefore help you drive good design.”
A test-driven Ruby culture has 2 wonderful “side-effects” in the community: better code quality through code refactoring and more stable open source Ruby libraries. This creates a high quality coding standard among Ruby developers and better code products that the community can use. Startups benefit from this by leveraging high quality community-contributed Ruby code to quickly develop their application. Win-win for both startup and developer.
As a side note, Ruby on Rails is a 10 year old (since 2005) framework while Ruby is already 20 years old! Many people may think that Rails is just trendy now, they failed to see the real value beyond the hype from the media. Developers stayed with Ruby on Rails because it brings them real benefits such as test driven development, convention over configuration, etc. All these translates to better development for startups and web application.
Rails Framework
Last but certainly not the least of all, Rails is a framework that seeks to maximise developer’s happiness and sustain productivity. As a developer myself who is passionate about coding, I want to relish the challenge of writing great code and producing great work for the world to use. I do not want to work in a stressed-out environment, fighting bugs, reading ugly codes and having low satisfaction in my work produced. Coding should be happiness. Ruby on Rails embraces this. The community embraces this. Any startup will definitely want productive and efficient developers working on their web application. Happy developers are more productive and more efficient at solving difficult problems. They produce much better work than stressed out developers.
In conclusion, choosing Ruby on Rails is not about choosing a framework. It is about choosing the community, the culture and the best practices that you wish to adopt into your startup and web application. Ruby on Rails provides one of the best (if not the best) culture and development needs for startups and web applications. Try it. You will love it. We already do. :)
