With React, I Don’t Need to Be a Ninja Rock Star Unicorn

San Diego Comic-Con 2011 - Lego Ninja, The Conmunity - Pop Culture Geek from Los Angeles, CA, USA

Followers of my blog may remember my microservice period. There was a time I could not shut up about them. Now, several blogs and not a peep. Am I over microservices? Not by a long stretch.

For us, microservices are gravity now. I remember an interview with Billy Corgan of The Smashing Pumpkins where, when pressed about his choice of guitar strings, he answered: “I use them”. That’s how I feel about microservices – now that we live and breathe them every day, they are not exciting, they are air. The only people who get exited about air are SCUBA divers, I suppose, particularly if they are running low.

ReactJS, on the other hand, is interesting to us because we are still figuring it out. For years we were trying to have our cake and eat it too – merge the benefits of server and client side rendering. I guess my answer to ‘vanilla or chocolate ice cream’ is ‘yes please’, and with React, I can have my chocolate sundae for breakfast, lunch and dinner.

The problem with ninja rock star unicorns

The magical creature from the title is of course the sought after 10x developer. He/she knows all the modern frameworks, sometimes reads about the not so modern ones just for laughs, and thrives where others are banging their heads against their desks repeatedly.

Rock star developers not only do not shy away from frameworks with high barrier of entry such as Angular, they often write there own, even more sophisticated and intricate. Nothing wrong with that, except that you cannot hire a full team of them, and even if you could, I doubt team dynamics would be particularly great. The reality of today’s developer job market is that you will likely staff a team with great, competent and potentially passionate developers. I say potentially because in many cases their passion will depend on you as a leader and your ability to instill it.

The React connection

This is where React comes into play. Careful readers of this blog may remember my aversion to JavaScript frameworks in general. For modestly interactive sites, you can go a long way with just Node.js, Express, a templating library such as Dust.js and a sprinkle of jQuery for a good measure. However, a highly dynamic app driven by REST APIs is too much of a challenge for jQuery or vanilla JS alone. I am not saying it cannot be done, but by the same token, while you can cut your grass with box cutters, it is massively less efficient than a lawn mower. At the end of the day, you need the right tools for the right job, and that means some kind of a JavaScript library or a framework.

What kept me away from Angular for the longest time was the opinionated nature of it, and the extent to which it seeks to define your entire world. Angular is a cult – you cannot be in it part time.

“Angular is a cult – you cannot be only a part time member.”

Not an Angular cult member

I have already written about why I got attracted to React from a technical point of view. There are great things you can do with isomorphic apps when you combine great React libraries. But these are all technical reasons. The main reason I am attracted to React is its philosophy.

We are all idiots at times

Angular used to pride itself as a ‘super-heroic JavaScript framework’. Last time I checked, they removed it from the home page (although it still appears in Google searches – ironic, I know). I presume they meant that the framework itself gives you super-hero powers, not that you need to be a super-hero developer in order to use it, but sometimes I felt that way.

I am singling out Angular somewhat unfairly – most MVC JavaScript framework approach the problem by giving you tools to carefully wire up elements on the page with events, react to watched variables, surgically change styles, properties, collections and so on. Sounds great in the beginning, until you scale to a real-world application, and things become really complex.

This complexity may not be a big deal while you are in the thick of it, coding like a beast. You may be a great developer. The problem is that the moment you turn your head away from that code, you start the ‘idiot’ clock – until that time when you no longer remember how everything fits together.

Now, if you are looking at your own code and cannot figure out how it works, what are the chances another team member will? I long ago proclaimed that dumb code is good and smart code is bad. Not bad code, just straightforward, easy to understand, ‘no software patent here’ code. Your future self will be grateful, future maintainers doubly so.

React allows us to write boring code

Let me summarize the key React philosophy in one sentence:

“Something changed in my application’s state. Better re-render it.”

React in a nutshell

I cannot emphasize enough the importance of this approach. It does not say “watch 50 variables and do surgically change DOM elements and properties when something happens in one component, then cascade those surgical changes to other components also watching those components”. Behind this, of course, is React’s ingenious approach of using a virtual DOM and only updating the real DOM with the actual changes between the two. You can read about it on React’s web page.

After many years of ‘surgical’ JavaScript DOM manipulations, there is something completely counter-intuitive about ‘just re-render’ approach. It feels like it should not work. It feels wasteful to keep creating all those JavaScript objects, until you realize that they are really cheap, and that the true cost are actual DOM manipulations.

In fact, you can use this approach with any JavaScript rendering engine – Mustache, Handlebars, Dust. The only problem is – if you try the ‘something changed, re-render the component’ approach there, templates will re-render into inner HTML, and that is wasteful. It is also potentially disruptive if users are interacting with form elements you just recycled under their feet. React, on the other hand, will not do it – it will carefully update the DOM elements and properties around the form controls.

Increase velocity without increasing bug rate

The key design goal of React was to help real world projects running code in production. Developers of modern cloud applications are under constant pressure from product management to increase velocity. The same product management of course expects you to maintain quality of your apps, which is very hard. It is not hard to imagine that shortening the cycles will increase the bug rate, unless the code we write is simplified. Writing ‘surgical’, intricate code in less time is asking for trouble, but React is easy to understand. There is uniformity in its approach, a repeatability that is reassuring and easy for people who didn’t write the code originally to understand when they pick it up.

Developers take great pride in their work, and sometimes they get carried away by thinking that code is their deliverable. They are wrong. What you are delivering are user experiences, and code is just means to an end. In the future, we will just explain what we want to some more powerful Siri or Cortana and our app will come to existence. Until then, we should use whatever allows us to deliver it with high velocity but without bugs that would normally come with it.

For my team, React is just the ticket. As is often in life, YMMV.

© Dejan Glozic, 2015

5 thoughts on “With React, I Don’t Need to Be a Ninja Rock Star Unicorn

Add yours

  1. Thanks for the nice series of articles Dejan! Especially the PayPal article (at last, after reading allot of blog and tutorials!) showed me a real life complete example of a ReactJS webapp.

    In this article you recommend the use of ReactJS for making a more-than modestly interactive site.
    But what would you recommend to create a modestly interactive site?

    I’m not talking about a small single page website but a heavy content website. I really like the way of componetizing everything in ReactJS but it feels to overkill for a non-interactive site*. The focus in my components would be more HTML/CSS than JS. A template language like Handlebars (more HTML-isch?) seems more suited for this job it looks to me.

    Any ideas/ways/links/frameworks (I’d rather not…)/… to help me find a solution for my use-case?

    * some small javascript enhancements

    1. Jeroen,

      Thank you for the kind words. As for the suggestions, my qualification is always that you need to use the right tool for the job. JSX has its quirks, and React itself adds overhead (something around 30kb minified gzipped). I always think that each tool needs to earn its place at the table, and for lightly interactive sites, something like Dust.js (what we recommend and use extensively) could simply be the ticket. I would normally not bother with vanilla JS unless really critical – jQuery would work nicely in this context. We like Dust.js because it has been proven in production and used by companies such as LinkedIn, PayPal, Yahoo, Netflix. Of course, Handlebars is fine too (very similar actually).

      My point is that you probably don’t need anything beyond Dust/Handlebars and jQuery. The moment you start finding yourself wanting a more formal structure – events, models, views etc., you are in the frameworks territory, at which point I recommend React for all the reasons already mentioned.

      1. We are trying to keep our development environment as small as possible. No extra frameworks, no jQuery, etc…
        A “feature” we’re looking for is actually “client-side web components”*. Although most of our websites are unique, some parts (small components, not pages) can be reused. For now, reuse equals copy/paste the HTML template, CSS and JS files.

        I already used DustJS for a small hackathon project, do you know any methods of creating such small components (template file, CSS, JS) that are easily used in a bigger template? If possible with vanilla Node.

        I’d love to npm install a component and use this in my website.

        * isomorphic would be a very nice extra

  2. Of course, you can always go without jQuery. As for Dust, you can compile Dust views into JS and load them on the client, pass JS data into them and render like that. Of course, you will at that point develop your own component model, which may or may not result in a ‘custom’ framework of your own :-).

    As far as I know, Web Components is the only ‘native’ component model that was supposed to do what you need, but as you know their support is spotty across the browsers, and shims are as heavy (if not heavier) as frameworks you are trying to avoid. Using npm to install a component is unfortunately not possible as far as I know without something like React + WebPack to handle the workflow, which does not seem to be what you want.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: