Fullstack developers, newbie coders and anyone looking to build a comprehensive web app has to wade through flame wars when picking out the right technology for their project.

Ruby on Rails and JavaScript are the Monitor and Merrimack in today’s programing language battles. Unfortunately, most of the debate focuses on the wrong questions.

Rather than pit JavaScript and Ruby on Rails against each other, the two languages complement one another and often fill different needs. Most internet discussions overlook this essential point.

A robust team is strengthened by having developers comfortable in both stacks as well as greater business awareness. In fact, engineers need to go beyond understanding only development, the more they integrate into the entire business cycle, the stronger the whole team is. Once the needs of the business or client have been ascertained, then it’s appropriate to start asking what stack to use.

Different Stacks for Different Apps

It’s the role of a sales team and project manager to understand what a customer needs before building a web app. Only after this has been established does it makes sense to start talking about what tools to use.

Ruby on Rails is the star back end of large, monolithic sites such as Basecamp, Hulu and GitHub. Large apps that run on an absolutely massive scale can really benefit from being written in Ruby.

Smaller projects, and startups in particular, have been gravitating towards Node.js backends in recent years. JavaScript is king for building microservices that can be stacked up like building blocks as a startup scales. This is precisely what Uber has done with JavaScript.

JavaScript is Everywhere

Even the most passionate Rubyist can’t avoid JavaScript on the front end. In fact, this is where JavaScript can compliment a Rails project. A cutting edge website requires a front end using modern JavaScript such as AngularJS or React to provide the best possible UI. This is why a team that works primarily with Ruby on Rails still needs developers who are JavaScript experts.

One of the key arguments made in the JS vs. Ruby on Rails debate is that using a single language on both the back and front end of a website adds simplicity. This is certainly a selling point for CTOs and project managers as familiarity with a single language is now enough to manage a complex project.

The Rails Community

Ruby on Rails has a robust community that allows developers to quickly build large and complex back ends. Ruby gems exist for many basic tasks and save programmers from having to reinvent the wheel for each new project. Furthermore, gems are vetted by a strong community, which adds to the overall security of projects built with Rails.

The value of a strong developer community shouldn’t be underestimated by businesses. This helps engineers work more efficiently, get answer faster and debug code more easily.

The strict, almost draconian, set of best practices for Ruby on Rails also adds to the overall efficiency of large Rails projects. In the Rails community, there is often only a single acceptable way to do things. This makes it easier to add or replace engineers on a project. New developers can easily read code that someone else has written and pick up right where they left off.

Not Quite Anarchy

The JavaScript community is nearly the exact opposite of the Ruby world. The lack of strict guidelines and best practices gives developers a great deal of freedom to creatively tackle new problems. This can be a huge boon to a disruptive startup.

The great flexibility of JavaScript stacks has downsides as well. Integrating new developers into a project often requires a steeper learning curve since the existing code base can be harder to read.

The JS community is still new. At the moment, navigating the node package manager (npm) is a bit like sailing the open seas compared to the safe harbor of RubyGems. This can lead to some security concerns with JavaScript. This isn’t a huge sticking point, though. Things are changing quickly, and in all likelihood, the JS community will soon be as vibrant as the Ruby one.

There’s no Accounting for Taste

Some developers simply prefer one language or stack over another one. This is just a personal, aesthetic preference. The flame wars on programming forums would do well to keep in mind that there’s often no explaining personal taste.

When the question of what stack to use is hashed out from the perspective of personal taste, businesses are forced to make critical decisions based on little more than the whims of engineers. This decision making paradigm is fraught with problems. The tool was made for business, not business for the tool.

Adding Depth to a Team

Once you get past the false dichotomy of Ruby vs. JavaScript, it’s much easier to see how an engineering team is enriched by being able to work with both languages across multiple frameworks. This doesn’t mean that every developer has to work with each technology.

There’s no reason to stifle anybody’s talents and force them to work outside of their comfort zone. Some clients have a business model that is best served with Ruby on Rails, others with a JavaScript back end. There’s no scarcity of either type of project. The question is both/and instead of either/or (&& and || in both Ruby and JS!).

Having a tight-knit group of developers who are familiar with a wide range of languages, stacks and technologies makes solving problems on-the-go that much easier. It’s not rare in our office for a Rubyist to have a fresh approach to JavaScript problem and vice versa.

And the Winner is…

Both. Ruby on Rails is our go-to solution for large apps, and JavaScript works better for microservices. The entire question is incomplete and needs to be reframed: What tools and technologies will best meet the needs of my business? The answer may very well be the latest JS framework or the old standby Ruby on Rails. Both are great solutions for very different problems.