More than 100 years ago, some guy formulated a theory around evolution, which suggested that the species who survive are neither the fastest, nor the smartest, but the ones that have the ability to adapt to change. Yes, we do admire Charles Darwin -and in some 2020 kind of way agree- so we’ll reference this famous statement to make a point today.

If we adapt it a little bit -following the theory itself- to the technological world we live in, where software has emerged as one of the strongest industries, we would describe evolution slightly different:

“In an era full of opportunities and continuous change, the software companies that survive are not the biggest, not the smartest, but the ones that strategically make decisions based in strong foundation grounds, knowing they have the ability to adapt to change (if needed)”.

The key to surviving in a world that keeps changing in every single way is to constantly evaluate and make strategic choices that uplift our competitive advantages. Still, there is a big incognita around our Darwin-like approach. So, to narrow the strategic decision’s spectrum, let’s consider specifically the daily technology choices as they play a key role in our daily work. Naturally, one of the first things you should be questioning as a software company is “Which technologies should we choose?” Well, today may be your lucky day, we can help you out based on our experience.

At LoopStudio, we have been crafting beautiful software for more than 6 years. We are a team of highly-talented developers and designers, but that’s only one side of the coin. Many things have changed throughout our journey, but one still remains constant: our dynamic duo -or magic formulae to boost our developers and products- React and Ruby on Rails (RoR).

Despite the large number of programming languages and frameworks that arise every day, we choose to stick to these two. Let’s take a look at the reasons why:

One of the greatest benefits of the IT industry is the fantastic community we have built. We can infer this directly from the Rails landing page, which welcomes you in the most friendly way: “Welcome! For everyone who wants to build web applications, whether they’re 30-year-old veterans or only just started to learn yesterday!” You can immediately get involved in the community via Ruby on Rails Discussions, the Ruby on Rails StackOverflow Q&A tag, and more.

As for React, there are many online forums which are a great place for discussion about best practices and application architectures as well as the future of React. Some examples of thousand-member communities are: DEV’s React community, Hashnode’s React community, and Reactiflux’s online chat.

Both are open-source and support your involvement even further by organizing yearly conferences for people to meet in real life. Just as important, both are free to use and have exhaustive well-maintained documentation and even provide official tutorials.

We also leave here a list of 9 websites to learn how to use Ruby on Rails.

You may be wondering which objective criteria we are focusing on to state that something is “easy to learn”, right? We believe an accurate characteristic is its expressiveness. The idea behind Rails is that the language is pretty intuitive: print “Hello” unless a = 0. This means: “Print ‘Hello’ unless a is equal to zero.” That is almost exactly the way we naturally speak.

As for the frontend, React is based on the JSX syntax. It can be naturally associated with HTML and CSS: the basic building blocks of any web developer.

If you work with Agile methodologies, you may be familiar with MVPs and early shipping of product concepts. The Rails framework is excellent for quick application development. It can absorb changes easily. Its testing and test automation capabilities promote rapid development and better quality of your product.

With the concept of schema and migrations, you can easily update your database on the fly, sprint by sprint, without having to immerse yourself into tedious, manual processes.

Regarding React, based on the concept of components accompanied by its modular architecture, we can build small functional portions of code, with reusable characteristics that will help us speed up the development process following the DRY principle.

Following the same line of reasoning, you could speed up the development process as RoR and React offer tons of excellent libraries, plugins and third-party integrations. Many features that you may be thinking of building are just an npm/yarn/rubygems install away. If you are familiar with these, authentication with Devise and tests with RSpec, building backoffices with Active Admin in record time, as well as React Router DOM and Axios are only a few examples that make our lives simpler day by day. Probably it’s not the best idea to fill up your projects with dependencies, but some things are worth considering as they tackle typical technical problems in a simple way.

As developers, we know there are millions of ways to solve a problem. Yet, sometimes we can start with some advantage by following conventions instead of configurations. Typically, dealing with the latter is time consuming and can easily lead us to errors. This paradigm defines an elegant and consistent way of building software. It is not designed this way because some guy just stated it; behind it, there is a whole team of talented developers constantly analyzing new patterns and standardizations that best fit the necessities.

This principle helps developers save time and effort. Because the framework “assumes” what they want to do and how to do it, you don’t have to worry about the details or configuration files.

Although this concept is Rails-oriented, we can take it to a different level towards React. Introducing the hooks concept, there are several rules-of-hooks you have to follow for doing things the right way. Also, most developers tend to follow the popular Airbnb React/JSX Style Guide that helps us set conventions based on good code practices.

By working with Ruby on Rails, you are directly applying the Model-View-Controller (or MVC) architecture. Whether you like it or not, it’s built in the framework. This narrows the chances of coding outside the standards and consequently minimizes the probability of falling into architectural anti-patterns. If your API was built by a certain development team and you are willing to hire a different one for maintaining your project, chances are Rails developers will beforehand be familiarized with what they’ll be facing, as most APIs follow this pattern. This makes you save time and money as the onboarding process will naturally be shortened.

As for React, you can easily decouple and follow the Single Responsibility Principle with React’s core concept: components. They are reusable elements of software that allow us to break a problem down into pieces. If you successfully achieve this, you will be encapsulating many generic components that won’t be constantly affected as new business rules are introduced. For example, let’s think of a dropdown; if you abstract it enough, it doesn’t need to change if you modify the list content -whether you are displaying fruits or countries- because they are encapsulated independently.

Ruby on Rails is the most performant framework -said no one ever-. Although it is known that Node.js or Django are somewhat faster than RoR, it maintains within the high average performance standards. Strongly positioned companies such as Airbnb, use Rails for their platform offering their 150 million users more listings than the world’s top hotel chains combined.

At the same time, Single Page Applications have captured many people’s attention nowadays. They have been popularized by React and other JavaScript frameworks. SPAs offer the ability to construct a rich, interactive user experience using client side JavaScript. They even optimize performance through the use of a Virtual DOM. Yet, if you don’t have much experience with it, you can cause many unnecessary re-renders that will eventually lead to performance issues. You should always monitor instead of trusting your gut feelings, because there’s a lot of room for surprises. Luckily, many tools such as React Developer Tools Profiler, React’s built in hook for memoization (useMemo), lazy component loading among other popular techniques will help you out if you’re facing performance issues.

In a software project, security has to be an all-level concern. Particularly in Rails, you can easily delegate some of these responsibilities. The ORMprotects you from SQL injections and consequently you don’t need to mess around with configurations as they are already built in.

As security is also a developer’s responsibility, React reminds you that using certain methods may expose you to vulnerabilities. For instance, when setting HTML directly from code, the method dangerouslySetInnerHTMLimplicitly warns you.

The combination of these technologies has been tested by leading platforms like Twitter and Shopify. It is proven that this union builds the most dynamic and reliable web applications with high-end development contexts.

Both have been in the business for more than 7 years and have been highly popular throughout time, becoming one of the most stable and robust frameworks in the market. This is an important aspect when it comes to choosing a technology stack: you want something proven.

The community support for Ruby on Rails is captivating and efficient. Moreover, React is a product of Facebook and therefore it offers stability and doesn’t need much change in their libraries.

Not exactly. When a relationship loses its raison d’être, eventually, it becomes toxic. We shouldn’t be making decisions with no purpose nor motivation behind. We shouldn’t be attached just because we have been working with it for so long that we feel too comfortable to consider new opportunities. It’s a decision made on a daily basis; for our actual demands as a software studio (yes, studio not factory) we feel these are the accurate choices.

But we don’t know what the future holds, so we keep up to date and on a monthly basis we discuss tendencies, new features, best practices that makes us question ourselves as a team and refine our processes and decisions to become better every day. What we know for sure is that our developers are fully prepared to welcome new technologies if the opportunity arises. By promoting an agile culture, we are naturally prone to change. All of our team members have an open-minded attitude towards valuable and beneficial changes.

Not exactly, either. Not all companies are the same. More so, not all companies work in the same way. This is not a book recipe to follow straight ahead. As our hypothesis stated: be careful and make strategic decisions wisely. Choose your ingredients based on analysis and identify which type of cake best suits your developers and clients.

Our intention is to point out our way of seeing things, and the main reasons why this formula has brought us so many benefits that we don’t have the need (yet) to adapt ourselves to new technologies.

To sum up, all of our stories have had happy endings with our beloved Rails-React duo. No, it’s not miraculous, it takes time and practice to find what best suits your company and your team (and stand out at it). From my perspective, it is an excellent practice to constantly investigate, question ourselves as a team, and prepare for the changes this modern world has to offer, so that when new opportunities arise you will be able to make decisions based not only on your experience, but in strong foundation grounds constantly discussed by your team.

I encourage you to dive into this React-Rails world or at least try it; after all, as software developers, we all have incorporated this challenging outside-of-the-box way of thinking, which is constantly drawing us into new exciting adventures!