.jpg)
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.
There are many options out there that can be used to solve the same problems that Ruby on Rails has been solving for a long time. There is Phoenix/Elixir, Django/Python, and so on. Then there is… <all the different frameworks>/Javascript. While Elixir and Python are great languages, I want to focus on Javascript which has the potential to solve the “Higher Costs” problem the best (see below).
The javascript community is enormous. Its reign as the web’s language has been long and fathomless. With this huge community there is great support out there for every skill level. But with that it can be hard to find great communities. Where do you even start?
When building an application with Javascript there are A LOT of choices. Javascript vs TypeScript, React vs Angular, Express vs Serverless, Linting Rules, Testing… and so on. On the one hand this is amazing. Need some specific functionality for your application, there is likely a pre-built solution out there for you. But again, with all that choice it can take longer to figure out what is the right solution. And if you look at all the new framework drops that happen, it is enough to make your head swim. Again, where do you even start?
With an open-ended system like you can build with Javascript, each codebase becomes its own very special snowflake. This makes it harder to onboard new people and can definitely slow down development if you make a mis-step that needs correcting. 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 because of: convention over configuration, a single framework, easier devOps, etc. but does Javascript have anything comparable to that?
Where Javascript really excels is the availability of developers. As Javascript became a more complete package, able to handle both the client and server sides and now with Typescript, more and more people are getting exposure to it in the full stack. If we look at the time to find and hire a developer, it averages well over a month. If you then look at the pool of Javascript developers vs Ruby developers from StackOverflows yearly survey, only about 6% used Ruby in the last year vs 67% have used Javascript. At ZEAL we have frequently hired a JS engineer and then had them take time to come up to speed on Ruby. This can be a very costly process.
Another point is that Ruby developers have a higher average salary than Javascript developers. Ruby is in the top 5, where Javascript isn’t even in the top 20. Compound this with what new developers are looking to learn and the numbers flip, Javascript is at the top while Ruby isn’t in the top 20. This paints a clear picture of things to come.
Since Javascript is supported on the backend and in the browser, it makes a ton of sense as a choice. You can hire one developer and know that they could potentially work on all the things with less context switching. Even within the web application Javascript ecosystem there are still too many choices.
In order to truly replace Rails, I need something that is a joy to work on. While all of the building blocks are there in Javascript we need something to tie them all together to make it a full stack solution.
Founded by Tom Preston-Werner (founder of GitHub), it has a great determined core team. RedwoodJS answers both the shortcomings of Rails and the open-endedness of Javascript. Most of the core team are coming from a Rails background, but how is RedwoodJS a joy to work with?
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.
Javascript has been around a long time. This has allowed RedwoodJS the benefit of that history by picking a sound stack. You can then add in other things on top of this to gain the same flexibility you would if you were rolling your own. This established a great foundation with which to build from.
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.
RedwoodJS combines the best-in-class underlying javascript framewords: TypeScript, React, GraphQL, Prisma, Jest, and Storybook. They keep RedwoodJS up to date with these libraries with regular releases. This can ease the maintenance of an app since they are taking care of many of the components.
RedwoodJS benefits from the amazing Javascript community. Javascript’s library of open source functionality is immense. You can find just about anything you need from connecting with different APIs to building UI components. And just like Rails, the Redwood core team is open to libraries that could enhance everyone’s experience.
RedwoodJS has the same kind of benefits that Rails does (or used to have). Rapid application development means less money being spent. With the dev ops generators, hosting becomes easy, saving time and money. On top of this it is much easier to find javascript developers as stated above.
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.
While there are things I wish they had, the ease of the framework makes up for the shortcomings. They are rapidly putting out new releases and continue to mature their framework. All this makes me excited to be able to work with a Javascript based framework that brings me joy and can be a solution that lowers the cost for bringing solutions to life.
Photo by Alex Geerts on Unsplash
Are you ready to build something brilliant? We're ready to help.
.jpg)
