A brief and uninteresting review of ReactJS

You might have heard of React (or ReactJS) lately. It’s a Facebook JS platform thing. You can find lots on it: here, here, or here, or perhaps this well-reasoned discussion. And probably other places: it’s starting to really get talked about a lot.

Naturally I did the obvious thing, and found the smallest possible project I could lever it in to, and implemented it. I wrote a mailing-list-and-whatever-else email system for work (using Lamson and Redis). Me being me, the “user interface” is a bunch of scripts in bash and Python, and `redis-cli`, along with a giant README on just what the hell is going on. 

Once I took it live, I decided “phase 2” was to at least put up a read-only view of things like “who is on what mailing list”. Obvious first choices here are Express or Flask, and a little AngularJS front-end; so React will work nicely. 

The server-side code itself is unremarkable: get a Redis key, then `res.json(result)`. Nothing special, so I won’t bore you with the details.

React itself was somewhat uninteresting. A somewhat dismissive but also not entirely inaccurate description is, “it’s just a thing for making directives”, a directive being what Angular calls its template/view/DOM-manipulation mashup; in other words, UI.

It relies on hierarchy, and at the higher levels all elements are new/non-standard; so in the tutorial it uses a “CommentBox” top-level element which contains a “CommentList” element, which contains a list of “Comment” elements, and so on. If you’ve ever done programming in something like GTK, this should be familiar. Only at the lowest level do you start dealing with HTML. 

Since it’s just “directives”, React contains no methods for talking HTTP, and it has no 2-way data binding. This is not entirely awful, because not every single element benefits from 2-way. It’s also not entirely great, because now you’re back at least partly in jQuery-land. I’ll always have affection for jQuery and will never say bad things about it, but I don’t think it’s a truly unfair statement to say sometimes larger applications can get unwieldy or difficult to manage.

For large projects, then, it seems like you’re just trading one hard-to-maintain method (a twisty maze of selectors and bespoke events in jQuery) to another (just what the fuck is a TopLevelStructuredListElementClass, anyway?). You can look at any “standard” AngularJS app and immediately understand how it gets JSON from a remote service, and with a few minutes of noodling you can probably reason where the Angular service code is and how it works. I don’t see that at all in React. 

I will probably deploy it (instead of rewriting in Angular), because it’s a very small app that does exactly 1 thing and will almost certainly not be changed for years, and maybe I’ll open-source it if I can. That said, I’m sticking with Angular for now.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s