Rails is a Solo Developer's Lever

Over the years I have built a few Single Page Web applications (SPAs) using frontend frameworks such as React and Vue. But recently, I was building a web app with Rails I started thinking about the following:

Rails is a great tool for solo and small team developers because it's really just a lever. It gives you and the team the fulcrum and beam to deal with the same set of problems as a larger team by providing a simplistic mental model through which to reason about the software application.

Let's trigger some software puritans on both side of the aisle and bring up the heated "SPA and Backend JSON Api" versus "Server Side Application" debate. This debate is not really a technology problem, but, rather a personnel problem.

Suppose you have an application that is highly interactive, a calendar or email web client. Giving a dedicated frontend team, say 3-5 of 10 people, a frontend framework total  sense (!!) because it allows those individuals to self-organize and handle the complexity of five parallel change sets at any one time. That is to say, the frontend framework enables creation of a communicable model for the squad to maintain in their collective understanding. Without a communicable model (i.e. spaghetti Javascript and CSS), the difficulty of proposing new change sets and evolving software in a multiplayer environment grows in a non-linear way. This is the misrepresented risk from a technology choice perspective. Frameworks linearize the learning curve for the application's mechanics, allowing new collaborators to ramp on and quickly evolve their end of the software.

Figure: Frameworks linearize difficulty of understanding the model

Flipping the script now, if you are just one or two developers, it might not make sense to use a full blown frontend framework. The reason is that the primary issue you're dealing with is not managing a communicable model between many contributors to handle parallel change sets, rather it is a question of "how much you can get done". Rails provides the leverage here by abstracting certain application decisions and doing the "heavy lifting". This allows the solo developer, to hold the entire application model in their head. That is, the application model might not be a communicable model – Sever Generated JavaScript responses is probably not as easily grasped as parsing a JSON request –  but, it is simple enough to hold in one person's mind and still evolve the application with a sufficient speed.