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.
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.
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
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
And the Winner is…