When in React

May 26, 2018

For the past few years I have spent most of my time working on applications in Ruby on Rails. When I was the Berkman Klein Center I also had an application in a Javascript framework called Meteor.js but for the most part we prioritized back-end functionality over front-end interfaces. This means that for applications like Lumen Database the front-end was written in HTML and embedded Ruby. This past week at MAPC has been a whirlwind of updating my front-end web development skills, primarily by learning React.

The thing I like most about React is the quality of the documentation. The official React tutorial is well written and I refer to it often. Since a large number of developers are thinking about and trying to write in React there is plenty of third party material as well. It is supported by Facebook which is nice to provide assurance it will not be abandoned. There is also a testing framework called Jest that works with it as well. This is clearly mature and well adopted technology.

React is not without its downsides, however. For someone used to using embedded Ruby, the amount of effort required to build something in React is significantly more than simply doing the same thing in ERB and HTML with some vanilla Javascript. Not only do you need to know Javascript concepts but you need to learn about the JSX template language. Doing something in React requires having more understanding of state and where things live than a vanilla JS implementation. React likely shines in complex front end interfaces, which I have not played with yet, but feels more like an anchor than an engine when you’re looking to sprinkle in some front-end magic on a mostly vanilla website. One thing I continue to think about is whether there is something more appropriate for basic websites than using React.

The weird thing about Javascript is it is a language with the wind both at its back and sides. The implementations of Javascript, its package management, and frameworks is large and can easily lead to decision paralysis. The question is rarely whether Javascript itself is future-proof and accessible but whether your flavor of it is. Today React is the safe bet, but tomorrow is anyone’s guess. The world of Javascript changes quickly. This is fun for folks who enjoy learning new technology and frameworks all the time, but less enjoyable for people like me who view code as a tool for building product.

Want to get posts like this in your email?

This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.