A brief guide on everything you should know about RoR.
Speed and adaptability have always been two of the most precious factors for impactful growth in businesses of all kinds. At eagerWorks, we are convinced that creating a successful application claims for an equation that includes both, but with a twist. The Lean Startup methodology, with its shorter product development cycles, business-hypothesis drive, iterative releases and continuous learning, showed the world the power of strategic (nonetheless fast) thinking and acting. So, when Eric Ries (a.k.a. the God of the Lean method for startups all over the world) claimed “Rails has done more for startups than a whole boatload of Venture Capitalists. Rails has had an incredible impact on the startup ecosystem”, all eyes were on this framework. Based on our comprehensive experience with RoR, we couldn’t agree more. Here’s eagerWorks’ guide to the galaxy of Ruby on Rails.
About Ruby on Rails
Ruby on Rails, or just Rails, is an open-source web application framework created by David Heinemeier Hansson, while working on a project management tool at Basecamp. Rails follows the Model-View-Controller pattern paradigm, allowing the development of real-world web apps with less code than other frameworks and with a minimal configuration. Ruby on Rails should not be mistaken for Ruby, which is the programming language in which RoR is written. Being a framework, Rails provides a platform with code libraries and specific methods, a foundation/structure on which devs can build databases, web services and web pages using Ruby, abstracting and simplifying common repetitive tasks.
It’s pretty possible you’ve already met Rails even if you haven’t heard of it before. A lot of famous and massively used applications were built on Rails, like Airbnb, Github, Twitch, Couchsurfing, Shopify, Square, Hulu, SoundCloud, Etsy, Heroku, Indiegogo, Zendesk, among others. So the question rises: Why Rails stays relevant till today, almost 15 years from its launching in 2005? Rumor has it, it has something to do with its 9 main pillars, the so-called Rails Doctrine:
- Optimize for Programmer Happiness
- Convention over Configuration
- The Menu is Omakase
- No One Paradigm
- Exalt Beautiful Code
- Provide Sharp Knives
- Value Integrated Systems
- Progress over Stability
- Push Up a Big Tent
You can take a closer look at each one of them in this post written by DHH himself. What we really like about this tribe culture rulebook is that you can definitely tell that there’s a “RoR way of doing things”: simpler, happier. Putting programmers’ enthusiasm on the first row, along with the “coding by convention” code of conduct, brings the best of two worlds: it decreases the number of decisions a developer has to make (therefore, allowing faster progress in what’s really essential), without losing flexibility. Rails’ emphasis on the use of the Don’t Repeat Yourself (DRY) principle is a great example of that — there’s no need for repetition of the same pattern every time you need to execute routine actions such as database access, user login, email sending, etc. Redundancy is avoided by gems, software packages that contain programs or libraries frequently used to extend or modify functionalities in Ruby applications. In a nutshell, with Rails, you can welcome optimization and tell excessive efforts goodbye.
The Bright Side (of Ruby on Rails)
There’s no need to say that every framework has a bright and a dark side, as everything we know. And its effectiveness (how bright it gets) depends on the project’s requirements such as hosting, scalability, learning curve, ease of installation, documentation, to name a few. Choosing the right framework is an art. Here’s why (and when) we are huge fans of Ruby on Rails.
If you are aiming to build something fast without reinventing the wheel, Rails is your best friend forever. Its simplicity of use and its high development speed have no rival when it comes to developing an MVP (or a prototype), enabling you to build a top-notch web application even with limited time or a limited budget, or both.
Creating an MVP is one of the fastest ways available to implement a new product on the market . You build an app with sufficient refinement and amount of functionalities to show its value to potential customers without beating it all. And, evidently, this works great for startups, the companies that care the most about cost-effectiveness but at the same time need their technology solutions to be out there as soon as possible. And here’s when Rails comes to the rescue.
RoR gives startups all they need: reduction in costs, increased agility to adapt to trends, quicker updates, and therefore a better chance to stand out in high-competitive markets. Rails is the most fertile of lands for MVP development, so to speak. Further in the article, we are going to walk you through all the reasons why the entry barriers for this framework are low. But, not to leave you hanging, here’s an introductory summary: Rails code is friendly and concise, it contains useful conventions, ready-made modules that minimize configuration, simpler ways to automate testing, and built-in dev tools that make the process of programming much more efficient. As you can see, all of this gets the process way faster, too. As developers don’t need to operate redundantly (remember the DRY principle), development speed increases.
But it’s not only Rails’ intuitive and compact syntax, along with its object-oriented nature that make developers write faster and more affordable code. The significant amount of free open-source libraries available (this is also crystal-clear, non-licensing, cost-saving, folks) within a super active and supportive community makes it easier too. We are going to get deeper into the Rails scene, so let’s just say that today there are 160,000+ Ruby gems available, making it pretty probable for you to find that feature you’re looking to integrate in no time.
All of this being said, don’t get mistaken: Rails can also be a great fit for all MVP’s wanna be dream: the larger platforms, with bigger budgets and longer timeframes. Why? Keep reading.
It’s difficult to find a more enthusiastic gang than the RoR family. Rails has more than 77,000 commits and 4,200 contributors on Github. Active members participate every day on this technology enhancement and the amount of dedicated websites, forums, and chats continues to increase. You can say that there’s no question on how to build things on Rails that hasn’t been answered (or is being collaboratively answered right now) on Stack Overflow, which makes its support better than other less followed web frameworks such as Laravel ( with less than 15% of RoR contributors on Github) or even Django ( with less than half of them).
Besides continuous virtual knowledge exchange, the Ruby on Rails community holds once a year the RailConf, the biggest conference focused 100% on RoR experience sharing. Finally, there’s a permanent flow of educational material such as guides, manuals, online lessons and newsfeeds. This cooperative fire, that keeps bringing new versions and improvements to the framework, makes us think that a relationship based on Rails is a long-lasting one.
In software development, updating can be really painful sometimes. Every now and then new technologies change everything, and with everything, we mean “full of bugs you need to google for hours on end” everything, every time a new version it’s released. In comparison, Rails is a walk in the park. RoR new versions don’t force you to redo the whole app from scratch, they even help you to easily accommodate improvements. We believe this is a part of the Rails’ agile software development spirit and why it became MVP and rapid prototyping BFF, as we said earlier.
Another midterm sweet treat from this framework is code maintenance. Rails (actually Ruby) is super readable, which obviously makes it more understandable and less needy of separate documentation. Alongside the Convention over Configuration paradigm, every developer knows where everything is and how to find it. This concept, one of the “chosen ones” in the Rails Doctrine, entails something pretty clear: systems, libraries and languages work with a lot of defaults settings, reducing drastically the amount of initial configuration and further decisions a developer has to make along the way of building an app. In this case, strict commands are gold: you only need to say yes to them and rest in Rails’ hands. You don’t have to create new rules each time, like with other frameworks or languages. With this take on things, a part of an application that is the same to all the other applications out there has a single answer in Rails, and that’s comforting, saves up a lot of time and it’s the best wing-tech for any scared beginner. Goodbye to messed-up projects’ learning curves, you won’t be needing a manual to explain all the code to new crew members. Due to RoR’s defined standards, rules and philosophy, programmers will pick up Rails’ existing projects smoothly at any development stage.
With the startling statistics around web-based, phishing and social engineering attacks in recent years, cybersecurity has become a key factor when choosing a technology to build your website on, especially if you’re in the Retail, Banking or SaaS industries. In this arena, Rails has another strength: RoR’s security was taught from the ground up. It’s built-in mechanisms and comprehensible policy on vulnerability reporting protect applications from threats like Script and SQL Injection, Cross-Site Request Forgery, and Forceful Browsing.
Moreover, Rails keeps a guardian eye on an IT fundamental best practice: Testing. The dream of non-bugs, non-issues applications is closer to reality with RoR’s Test Driven Development approach that assures 100% testing code coverage. Many Ruby gems allow automated testing and Rails’ built-in Minitest suite is full of features that aim to quality excellence such as expectation syntax, test benchmarking, and mocking. Needless to say, preventing bugs leads to reduced development costs and time, already decreased by the fact of Rails being an open-source framework with no licensing costs involved. Win-win all over.
The Dark Side (or When Perhaps Rails is Not Your Best Option)
Taking into consideration everything we’ve said so far (we have very good reasons to predicate that Rails rocks, right?), there are some cases in which RoR could not be the best option for your project. Let’s face it, nothing is perfect.
It’s possible that Rails won’t be your first choice if you want to develop a product that needs to handle thousands of requests per second from the very start. In the IT industry, it’s well known that apps built on programming languages like Rust or Go are faster than Ruby-based ones, and we can’t deny it. Nevertheless, we disagree with the fact that it’s a problem within Rails. Moreover, there are always clever ways of dealing with escalation in an optimized way. For example, if you have a module of your app that needs super fast especial performance (like a chat for 2000 synched users), you can always go for a microservice in another language in that particular section. Nevertheless, let’s face it: very few applications in the world measure its performance on a Twitter-demand level.
In most cases, project bottlenecks are related to architecture or database access. And, with code optimization, we can mitigate risks on large-scale apps that run on Ruby on Rails. If we are not convincing enough, ask Airbnb, Github, Groupon or the UK government, all high profile organizations with millions of active users than rely on Rails power. Quoting Lawrence Mandel, Director of Product Engineering at Shopify, one of the most successful CMS for e-commerces in the world, “ sorry, Rails detractors, we are too busy making things happen at a large scale with DHH’s framework “.
Ruby on Rails’ hard dependency between components and modules makes it ideal for standard web applications but not so much for products with unique, super customized functionalities. It can be challenging, for example, to develop an I/O-intensive web app (that has to deal with access to files, external servers, etc.) with an opinionated framework like Rails: the time will come when adjusting the technology to very specific and unconventional requirements will take more time than building it from scratch. The same applies to the other end of the originality spectrum: if what you need is a static website (a lonesome home or a landing page) don’t even bother to use Rails, it would become a case of serious overkilling.
But then, is 2020 the year to use Rails in your project? Absolutely.
Over the last 15 years, Ruby on Rails has grown to be one of the most relevant web frameworks around. And, against the odds in the ever-changing tech world, it has matured into more than a passing trend. Every technology follows the Gartner Hype Cycle, and Rails is no exception. After it’s triggering in 2005, and its Trough of Disillusionment around 2014, RoR passed the test of time and jumped on the Slope of Enlightenment from 2018 with no perspectives of near future obsolescence.
The impressive number of +130 million downloads so far, almost 570,000 live websites using Rails (some of them with over 200M visits/month), and the recent uprising success of Ruby in popular tech rankings (e.g. Stack Overflow or TIOBE), are proofs of how the tech community and the users know and appreciate all RoR strength points we’ve mentioned above.
Even more, 2020 is a great year for Ruby on Rails. First of all, because of the arrival of Ruby 3.0 and the almost surreal 3X3 goal, a promise of a new Ruby three times faster than Ruby 2.0 before 2020 ends. That will definitely silence everyone who said that Ruby was a tortoise’s paced technology and will make the nearest future of RoR development brighter than ever. But even without being carried out by upcoming events, the present looks great for Rails, with last year’s releases of Rails 6.0 and Ruby 2.7 full of handy, cool upgrades and a lot of new gems and versions. A great example of Rails being still on the run is the fact that 6 out of the top 10 startups accelerated by Y Combinator (house of Airbnb, Dropbox, Stripe, and Rappi, among others) were built on Rails.
At eagerWorks we have no doubts that Ruby on Rails is a great option for soon-to-be-great businesses with small time and limited funding on their hands. We are experts in making the best out of your ideas developing solid MVPs, comprehensible prototyping, and innovative solutions for established companies with Rails. Additionally, we came to prove that RoR also rocks at bringing your +10 years old digital products to its finest today with modern but sustainable technology.
If you have an idea or a current project that needs a boost, or if you want to know more about our expertise with Rails, don’t hesitate to contact us!
Originally published at https://eagerworks.com.