Arguing for ReactJS

  1. Its incompleteness — it’s not a “fullstack” framework like Meteor or Angular. It doesn’t have a router, a model system and many other common framework features. People say it’s just the “V” of the MVC, but this is far from accurate, and we’ll discuss that.
  2. Its syntax — it mixes HTML and Javascript. People look at JSX and they say “but… why?”. And some people even advocate mixing CSS.

First of all, what is React?

React is a javascript library to create components. A component has a look, defined by a render method and some states, defined on getInitialState. The look is based on the current state. That’s pretty much all. And the fact this is all is what makes React so hard to explain, because people have this feeling that this just can’t be all.

Addressing negative arguments

Incompleteness. Vice or virtue?

When Rails came, one of its main selling points was its “fullstackness” (I hope it’s a word). Since, most alternatives to it mimicked the completeness of the solution, having a database abstraction layer, a routing system, a templating system and so on.

Is React just the V of the MVC?

As Andre Medeiros points out in his great presentation, React goes far beyond the V. This is because a React component have state, so, in a sense, it’s a Model, it handles the mapping from inputs to state changes, so it’s also a Controller, it renders the component, so it’s a View — or Presentation as he puts it – and they also communicate and depends on other components. So the assumption that all you have to do is to find a suitable model and controller libraries is just false.

Why mixing HTML and JS? …What? CSS too???

The holy grail of web development, 10 years ago, was the separation of HTML, JS and CSS. Everything should inhabit in its own kingdom, separated by files and folders, only referencing each other using includes.

Positive arguments

There is an ecosystem

As I write this article, React just passed Ember in number of stars on GitHub. It’s only behind Backbone and, of course, Angular, but growing way faster than its “competitors”.

Easier to reason about code

One of the main positive arguments given about React is that it’s easier to reason with. This is definitely a true statement, and its power and importance can’t be neglected.

vanilla jQuery toggler
React toggler


Here’s a magic word. In the back-end world, reusing pieces of code is a reality. Think gems or eggs. But in the front-end it looks like we have to rebuild everything every new project. It is true that things like a DOM traversal tool or a URL parser are easily reusable, but when it comes to the content itself it looks like every project is a different beast and every piece of a layout is an idiosyncratic being that rejects gregarious tendencies.

Growing a project

Most front-end projects I’ve worked on started small and eventually grew considerably. Some of them were refactored to a different framework at some point, or injected some ad hoc structure to handle the complexity increase. On both cases this demanded a fair investment of time and effort, halting some product features — but as any important refactoring it gave more development speed later, of course.

Final considerations



Vita brevis, ars longa, occasio praeceps, experimentum periculosum, iudicium difficile.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Vita brevis, ars longa, occasio praeceps, experimentum periculosum, iudicium difficile.