Seven reasons why a Rails, Redux, React, and React Native stack is fantastic for new startups

Will Little

I was on the phone with a developer friend of mine the other day talking about plans to update a book project of mine to teach startup founders Rails, Redux, React, and React Native when he mentioned:

“You know, I wonder how many technical books finish with a very different toolset than what they started out with, given that the landscape changes so fast…”

Good point. I bet the answer is tons.

And sure enough, I started writing Introduction to Web and Mobile Development for Startup Founders ~4 years ago with Backbone.js and Embedded Coffeescript templates (Eco) in mind. I had just built some single-page apps with this front-end stack and was jazzed about it.

I'm now, however, in a position where I need to update the advice I give myself and aspiring startup founders regarding a go-to software stack.

Here are seven reasons why I'm all-in with Rails, Redux, React, and React Native:

ActionCable

Modern web applications need a way to push information to web browsers (chat, notifications, live updates, reloads after deployments, etc.). Back in the day I remember wrestling painfully with various not-well-supported PubSub and WebSockets solutions, but now with ActionCable in Rails the development process is amazingly easy (seriously, here's a quick demo I put together).

ActiveJob

Performant and scalable web applications need to defer as many tasks as possible to background jobs. Heroku published a simple graphic explaining why (given a web-based RSS reader example):

You can imagine how attempting to do all this work in the web process would be a slow experience. Before ActiveJob, Rails developers were left to hack together their own solution (full of gotchas like not being able to send an ActiveRecord object to the job). But now we have a built-in solution that will perform background jobs for us in memory, which is nice for the very-early-stages of a startup that doesn't want to pay the additional hosting cost of background workers. ActiveJob then easily supports queuing solutions like Delayed Job or Sidekiq/Resque with Redis as needed.

ActiveJob's Github page sums it up well:

The main point is to ensure that all Rails apps will have a job infrastructure in place, even if it's in the form of an “immediate runner”. We can then have framework features and other gems build on top of that, without having to worry about API differences between Delayed Job and Resque. Picking your queuing backend becomes more of an operational concern, then. And you'll be able to switch between them without having to rewrite your jobs.

Predictably containing state in client, server, and native apps (Redux)

Redux is a game changer. If you've ever wrestled with massive technical debt in front-end-heavy web experiences, especially as it relates to containing and controlling state, then you can appreciate why a solution like Redux is important.

It may not seem like a big deal to try and write your own JavaScript to keep track of such things, but it becomes a serious issue as you grow. Always.

In addition, being able to use the same paradigm across server-side and native experiences is a serious win. And live code editing combined with a time traveling debugger never hurts.

UI components that auto-update and “just work” based on a one-way data flow of properties (React)

Manipulating the Document Object Model (DOM) becomings increasingly painful — and slow — as your application grows and you encourage users to stick around and interact with a single page.

Back in the day we could get away with maintaining state in custom JavaScript solutions and updating the DOM with jQuery, but those days are long gone (for the better).

Facebook engineers and an army of open source developers are the force behind React, which is simply a User Interface (UI) library (not to be confused with frameworks like Ember or Angular). It's a beautiful thing to be able to use pure React to build presentational components (i.e. state-agnostic, they just do what they are told), and React-Redux “container” components that handle updating and feeding the presentational components. Learn more about this by reading Dan Abramov's article Presentational and Container Components.

Quickly spinning out iOS and Android apps while not needing to ever go “pure native” in most cases (React Native)

One of the most common frustrations both founders and VCs have when it comes to the growth of digital companies is the expense and time it takes to build apps for desktop, mobile web, iOS, Android, MacOS, etc…

React Native is a serious game changer in the market of meta-level mobile frameworks. While many people lump it together mentally with Appcelerator/Titanium, Phonegap, Xamarin, Ionic, etc., React Native is fundamentally and powerfully different. The way it approaches native components, asynchronous execution, touch handling, styling, polyfills, and — perhaps most importantly — its extensibility (i.e. you can literally create modules in ObjC/Swift for iOS and Java for Android as needed) is unparalleled.

Improving developer efficiency

For founders with the ability to scale their teams with a relatively blank slate compared to established companies, betting on JavaScript and React with a Redux paradigm is smart because it streamlines the development experience across platforms. This saves the company money and speeds up development exponentially.

Plus, Facebook “uses React Native in multiple production apps and will continue investing in React Native”, which is hard to beat with other app frameworks, and they've cleaned up their licensing/patent issues. Also, Redux plays very nicely with React Native, and many of the people working on React and React Native are literally on the same team. If you look at the top React contributors and React Native contributors, you will see some of the same people on both lists.

And if you think betting on Facebook as a foundational supporter is a bad idea, take a look at their stock price over the past five years and where they are heading with their business and products. Like it or not, for the foreseeable future they are a pretty safe bet.

Leveraging (and participating in) the large and battle-tested Rails and React communities

Finally, the Rails community and React community are both amazing and have published a ton of gems and components to speed up engineering. More than ever before, web and mobile development involves knowing what pieces are out there and how they fit together. While of course understanding the nuances of what happens closer to the metal is beneficial, you can get away with being an excellent web/mobile developer without being an expert in Computer Science because of the code out there that is already written for you to use.

Plus, when you need help, Google searching and the variety of forums out there (mostly notably Stack Overflow) are quick to provide guidance. I've been profoundly impressed with the resources and people available to lend a hand over the years (i.e. I have many people to thank).

—

In conclusion, the Rails, Redux, React, and React Native stack is, in my opinion, a solid choice for startup founders to consider as they work on spinning up new projects. Of course, there are tons of topics within these worlds that I didn't talk about (e.g. Rails has a nice API-only mode now), and at the end of the day it's safe to go with a scalable stack you know well (as long as it has plenty of talent available to work on it) because validating and executing the ideas to grow your business is vastly more important.

Also, if you're a die-hard JavaScript fan you may be wondering why I don't suggest ditching Ruby all together and run with JS-only solutions. While I'll write more about this in future articles and am very open to changing my mind, the short version is because Rails in my opinion is more mature and beginner-friendly than the server-side JS solutions out there. Most founders I work with are interested mainly in solving business problems as quickly as possible; i.e. they prefer spending time doing things like acquiring customers versus writing tons of server-side JavaScript.

That being said, there are a bunch of frameworks and packages/libraries/patterns out there that are maturing quickly, and I think the day of recommending JS solutions over Rails for new founders will indeed come at some point. Even then, however, I'm confident that previous teams that stuck with Rails won't be disappointed.

Author's note: my main writing projects at the moment are books about idea-to-funding startup operations and web/mobile development for aspiring technical founders. Feel free to subscribe to my newsletter and I'll let you know when I get new content up. Thanks!