I have been involved with web applications for a very long time. Since the 90’s when PERL earned the title of a write-only language and cgi-bin dominated web development. The 90’s, where all the pop culture remake stuff is being farmed from right now. Which is making me reflect on my GOTO.) choice of technology, Ruby on Rails.
Ruby on Rails has been solving problems for a long time now. It has been highly successful in allowing some of the biggest names to rapidly develop and launch incredible products. There are a plethora of reasons why and it mostly has to do with developer buy-in. Make the developers happy, and greatness can be achieved. Here are a few of the cornerstones that draw in amazing developers.
The Ruby and by extension the Rails community is a great one. There is so much positive support for developers looking for direction, help, and contribution that it is really heart warming. Yes there are opinions and strongly held ways of doing things, but for the most part it has not equated to toxicity.
With a framework that has been around for so long, there are so many choices on how to build your application. Traditional MVC (model view controller), SPA (single page application), SSR (server side rendering). Not only that but being able to handle different architectures at the same time for different end users/applications as the company/product offering grows.
This was the big selling point of Ruby on Rails. A team could just move faster developing solutions in Rails over other technologies of the time. This was due to several reasons:
The first thing that made everything more efficient was the framework decided on many things for the development team. There were ways to go and tweak something, but you didn’t have to make many decisions right off the bat and could focus on what made the solution you were building special.
Without having to leave the framework you could generate and code up an application. This was super powerful in that the developers only needed to learn one thing. The Rails team could focus on making those things really great. Again if you wanted to you could deviate from the defaults, but usually there wasn’t much need to.
If there was something missing from the framework, a huge library of gems was available to fill in the missing pieces. This goes back to that great community making their contributions. When something was deemed a key addition, it was added to the Rails core making it available to all.
Since development could move faster it also meant that there was less money being spent. Not only that but you could run it on relatively cheap servers and hosting platforms. Over time this item is becoming less true as the cost of Rails developers increases and more frameworks along with more hosting platforms are able to compete.
Developers’ attention is easily captured by the latest shiny object. Languages and technologies wane as new more appealing choices come into view. After so many years, Rails is in decline. While I could find that next Rails job and reap the benefits like a COBOL programmer to the banking industry, I just don’t want to go out like that.
A well designed system can handle many different requirements. But if you are able to handle just about everything, then things may not be optimized. This is where the framework/language flexibility can have a cost in performance. This has a lot to do with the diligence of the engineering team, but ruby does have slower runtime speeds. While they can be overcome a highly successful application may suffer.
While performance is definitely a consideration, cost is really what this is all about. As new technologies emerge and more hosting options are available, the cost savings of Rails can flip to higher costs. Especially if you need people specifically working on DevOps. Not only that, but finding and paying for Rails developers is becoming harder and more costly. Bootcamps have been dropping Ruby on Rails from their curriculum.
The RedwoodJS community is a super friendly place where not only is there a strong and friendly core team, there is also a growing and engaged user base. Since it is up and coming there is also a lot of opportunity to contribute in a supportive environment. Both their Discord and Discource platforms are open to all and are a great place to get help.
The foundation that RedwoodJS puts down isn’t only flexible, it allows engineers to quickly develop solutions. They have generators just like Rails does for all the different types of components used to support developer operations, the API and the front end.
While just having the best-in-class frameworks like React and Prisma under the hood, Redwood ties everything together allowing developers to focus on the features they need to build. You can still get to the configuration if needed.
While RedwoodJS is off to a great start, it is still less than a year out of its 1.0 release. Here are some things that I think would really make RedwoodJS shine.
Are you ready to build something brilliant? We're ready to help.