ReactJS: Rest for the Weary

Some years back while I was still in college my first internship came to an end. Although I had been programming from when I was a young teenager, this internship had brought me to web development. At this point I was still quite like a traveller without a map. I had some idea of what was possible, but hardly even knew enough to get started with anything. I had some ideas around a website that I wanted to make but no idea of what technologies to use. At that point my only real experience was using in-house software that I no longer could use.

From 0 to 60

Starting with a google search, and with all the passion in the world, I began ill fated attempts to utilize some then-modern JavaScript libraries and some not so modern attempts on how to serve the website (full stack frameworks, Platform as a Service, Amazon Web Services, etc... were not in my vocabulary at that point).

It was a bit of a crazy journey from there both personally but also professionally. I went from internship to internship, fell in love with Ruby, fell into a habit of implementing every idea with Ruby on Rails (for better or for worse) and was always learning. At this point I had used but not loved Backbone, Angular, Node, and many other libraries and frameworks. In this same time period I graduated college, and landed my first full time job as a web developer.

Being Weary

React had always been in the back of my mind. I knew it was there but had not yet given it an opportunity in a side project or anything of the sort. At this point I must say I am no source of authority on JavaScript libraries or frameworks. It should also be said that while I do both client side and server side development, I am more notably a back-end developer. However I want to give one perspective on the client side JavaScript situation that we find ourselves in now.

All of the frameworks and libraries I had used tried to be two or more things at once. In the case of Angular it tries to be a full on client side framework, which not only has conceptual suggestions on how to do things, but real restrictions on how to do everything you do. For many projects this was a good thing, but for the same reason it could never be my go-to solution. Some even take this to the server side (Meteor), and in these cases when it comes to going from development / concept to production the ease of access of making that todo app seems less important. Finally others, even though they do not try to be a full framework, they still attempt to solve two distinct problems in two distinct pieces such as Model - View (Backbone).

Finding Rest

What I love about React is that it is about building user interfaces. That's what it does, no more, no less. While it does include an aspect of controlling the Model (via state and props) it does so without the normal template / data distinction which means that you don't have to restructure your code to fit React into it. As someone who has done more jQuery based user interfaces then I care to admit, I love the idea of grabbing a chunk of bug-prone jQuery and replacing it with a self contained React component. Doing that same thing with any of the other frameworks would require introducing many things that go beyond the conceptual limits of pure JavaScript (such as templates, models, controllers, changes to how your JavaScript dependencies work, changes to the markup, etc...).

The fact that the React documentation defines what a component is and then says, "This function is a valid React component because..." illustrates the point very clearly. The idea is that a React Component is a JavaScript concept first, before it is a JavaScript library​ or class. In addition, that concept is bound by the conceptual limits of JavaScript. That quote goes on to say, "it accepts a single 'props' object argument with data and returns a React element." React doesn't try to be meta-JavaScript. it is just a JavaScript library for constructing user interfaces.

In some sense all you need to have in order to be "doing React" is to have a function that returns a React element. Ultimately this means that you can take almost any chunk of poorly written JavaScript and replace it with a React component. No need to create an entire Eiffel tower making that single component work, just include the library.

I hope this helps!

Oh and by the way, one caveat: JSX is a JavaScript language extension that helps with writing clean React code. Obviously this breaks many of the things we mentioned above. This is very much "meta-JavaScript" and requires changes to how you deliver your JavaScript. However I have not found this to be a big deal, and once it is setup, all the benefits I mentioned hold true once again.