td-berlin Tech Blog

Why your company should adopt React.js really soon

Roman Heinrich / mindreframer
• reactjs

Personal background

First my personal story, how a developer with little frontend experience ends up sucessfully leading 4 full real life frontend projects for real customers in one year.

In 2014 when I have joined TD, the applications here were mostly plain Rails applications with some Javascript to configure jQuery plugins + some glue. It was OK, but nothing special and the development experience worked fine for usual cases but restricted heavy logic on client by design.

Angular.js scars

My background was Rails/Ruby backend / DevOps with basic JS skills. I have worked with Angular.js before on a previous company building heavily configurable UI and got burned by seemingly simple requirements.

Custom directives in Angular.js break down and grow unimaginable confusing, as soon as you start composing directives in one each other. It felt literally like pushing squares into holes and I carried this trauma until May 2014 with me, trying to understand what went wrong. The team toughened up and used the XML principle: “XML is like violence. If it doesn’t solve your problem, you’re not using enough of it.”. So team members really dived deep into Angular.js, we bought advanced books for it and wrote crazy code just to work around the issues with wrong abstractions.

But I had learned the lesson: simple and easy are very different beasts. Angular.js made simple things easy, but left you dangling on hard things. The bidirectional bindings (the advertised advantage) became the root of the problem. They made the UI unpredictable and caused performance problems when used in big complex components. Also there were so many new concepts to learn and to combine, and one final issue sealed it for me:

directives can not be cleanly composed.

Not by mortal engineers who don’t study in Angular.js University and don’t get out with a shiny PhD of Angular.js . Just take a look at this - The Hitchhikers guide to the directive

var myModule = angular.module(...);
myModule.directive('directiveName', function (injectables) {
  return {
    restrict: 'A',
    template: '<div></div>',
    templateUrl: 'directive.html',
    replace: false,
    priority: 0,
    transclude: false,
    scope: false,
    terminal: false,
    require: false,
    controller: function($scope, $element, $attrs, $transclude, otherInjectables) { ... },
    compile: function compile(tElement, tAttrs, transclude) {
      return {
        pre: function preLink(scope, iElement, iAttrs, controller) { ... },
        post: function postLink(scope, iElement, iAttrs, controller) { ... }
      }
    },
    link: function postLink(scope, iElement, iAttrs) { ... }
  };
});

After that realization I have immediatelly lost any interest to invest more time into Angular and my fear of big complex frameworks grew bigger.

Vue.js - Angular.js lite…

My next candidate was Vue.js. I was hoping that by using a smaller library with more focus something would change. It worked fine on a small prototype, but got confusing in face of real requirements. After trying to bend it for a couple of weeks I gave up…

React.js - just give it 5 minutes…

And then I took a harder look at React.js and was blown away: all the decisions made suddenly sense! In stark constrast it

So, in face of uncertanty you pick weapons that give you unfair advantage. And React.js gave me just that.

Fast forward one year and we have build 4 rather stable and good looking dashboard applications to greatest customer satisfaction.

The team morale is high, even strange and sometimes ridiculous requirements seems doable and we enjoy finding new ways to express our thoughts in React.js code.

We found React.js to be fundamentally a critical part of our applications.

In the following I’ll try to collect the plenty reasons, why it became so critical.

Software quality benefits

It reduces complexity by giving every component a uniform interface: call components with your domain options hash. The way to use them is very clear and explicit.

You can programatically compose complex UIs with arbitrary client-side logic. You have very fine control of what is happening in the browser and have a very well thought-out life cycle system of hooks to react to events.

Your code is performant by default. Sometimes, when you need to go that extra mile, just implement shouldComponentUpdate with couple of lines code as illustrated here https://facebook.github.io/react/docs/advanced-performance.html and you probably improved your UI significantly.

You can write unit-testable code without complex tooling, and React.js allows you to test against VDOM for simple logic.

You can reason about uni-directional data flow through your system if you adopt Flux architectures (or use any of plentyful Flux implementations)

Concepts from Fuctional programming are suddenly very real in your UI:

People benefits

Any good software developer will pick up React.js is very short amount of time. That way you drastically reduce the onboarding time for new team members.

Your company will attract good, quality focused people.

To improve your React.js code you just have to improve your JS skills in general, because their public API is incredibly stable and very small.

You can apply common sense best practices and all the refactoring patterns that you already understand and love - https://sourcemaking.com/refactoring

Most concepts are not framework specific and once it made click with React.js components and Flux, you are free to structure your code in any meaningful way.

Team members feel productive and can have meaningful discussions on a solid engineering ground. Knowing all the browser quirks and excessive DOM knowledge becomes less an issue, you can hide behind React.js abstractions.

Ecosystem benefits

The ecosystem is currently exploding. React.js has taken the modern JS community by the storm. It was so desperatly requried to have a meaningful abstractions to build highly complex but predictable UIs.

Due to very flexible component life cycle you can integrate React.js with ANY JS library, without exception. There are plenty of wrapper libraries for any kind of third party JS library and it is quite easy to write your own.

The energy level of the community is simply astounding, every day there are many new libraries, articles, webcasts, screencasts, the React.js Conf 2015 was a huge success.

The grateful community is iterating over so many interesting challenges, that we even did not try to solve a couple years ago.

Unexpected / Future benefits

React.js allows you to write isomorphic JS applications, that return full static rendered HTML, which is then made dynamic on client. That way your SEO rankings don’t suffer and your users immediatelly see content, even when the Javascript is not fully loaded.

Also it is possible to write apps with serializable app state to allow your engineers advanced debugging techniques. Circle.CI implemented this and are loving it - http://blog.circleci.com/local-state-global-concerns/ !

When you start using immutable datastructures, like Immutable.js, it is trivial to implement Undo-Redo functionallity in your application, and now it is rivalling desktop applications in terms of flexibility and feature richness.

The mobile development (Native iOS, Android, Webview with Cordova) might move in future to React.js style development, React Native is really hot technology at the moment.

To quote some happy users on this Hacker News thread https://news.ycombinator.com/item?id=9751539

CSHELTON:

React’s advantage is the declarative style, very easy to reason about your View logic. Team productivity is up, fixing/changing older UI is easier/quicker, it’s great. At this point we have around 60 pages, hundreds of components. It scales very well.

CYBICE:

I’ve moved from angular to react and i’m happy. Simple, really simple!!! interface. All you need is to remember just few methods of one (ONE!!!) class. It’s fast enough to create interfaces with a lot of objects. With react and react-native i start publish my projects on github, because they has a simple structure and can be easily supported. I almost forget jQuery, it’s really rare situation when i need to access real DOM.

CHANTASTIC:

I like React because it’s closer to JavaScript than any other JS library I’ve used. The public API is tiny; you get better at React by getting better at JavaScript. The only thing I don’t like about React is the rapid churn in architecture best-practices (Flux et al). This is in stark contrast to Ember—which nails conventions and tooling but is written far about vanilla JS. We use React because components are a great abstraction for the web. React components are also very transportable, making them a great addition to integrated systems like Rails. I like to focus on transferable skills. I don’t want to be a Backbone/Ember/Angular/whatever developer. I want to be a good JavaScript developer. React makes that happen.

COLINMEGILL:

Unbelievably productive. I don’t think there is another good choice right now. I’ve been on every other framework (large, complex backbone apps, companies you’ve heard of) and the codebases have been insane. New programmer onramp time is down a lot, time to feature is down a lot. The codebase complexity seems to scale linearly with actions and stores, other frameworks felt more like quadratic (jk, don’t respond to that).

NOTDUNCANSMITH:

I’ve used it for multiple apps at this point and it’s been a huge win for me in terms of productivity … Also, having worked with both Angular and React alongside less experienced developers, I’ve noticed developers in general doing a lot less stupid shit with React (not to say none, just less). Angular doesn’t have many strong philosophies about programming, so it’s largely up to the programmer to make good decisions rather than have the framework make the right thing feel right - the latter, in my opinion, being what growing developers need.

LASTOFUS:

I’ve been slowly injecting it into a project that was previously all JS + jQuery. Things I love: - All of the view state, event handlers, and markup in a single place. This makes it super easy to reason about. - Very easy to learn and get up to speed with relative to a full framework. I found it even easier than Knockout which is saying a lot. - Injectable into a pre-existing project that was not designed around using ReactJS.

SCRIPTLE:

I use React for almost all my projects and I’m definitely happy with it. It addresses one of the main problems - many developers in your team contributing to the same code. React IMO helps us write predictable code even when there are many developers contributing to the same code.

GUSCOST:

I’ve been using React and Flux for a few enterprise projects, and although I don’t have tons of experience with browser applications it is the most helpful and pleasant JavaScript technology I’ve ever used (aside from maybe jQuery, but that solves a very different problem).

To sum it up:

As developer:

As team leader:

As business person:

React.js rocks hard and you should evaluate it for your next project! Just do it! It was one of the best decisions in my developer’s career and it will be also yours! “Just give it 5 minutes!”

If you are interested in working with stable and advanced React.js code base, visit us, we’re looking for good frontend developers!

List for resources to get you started:

Carefully selected resources to get you up and running:

Best Articles that explain Reactjs

Unit testing React.js

Large Collections of everything React.js related