The Hidden Law of a Probable Outcome
A good friend recommended we look at switching from AngularJS to ReactJS. Looking at a the reviews and comparisons, one of the strongest reasons to use React is that it is supposed to be so much easier to use. In this moment I learned something about myself and a few other people I know. We never seem to pick the easy technology.
Occam's razor is a wonderful principle "Entities should not be multiplied unnecessarily." which roughly corresponds to "when you have two competing theories that make exactly the same predictions, the simpler one is the better."
So why is it when I look at my own history and that of my co-founders we spend a lot of time extolling the virtues of clean simple code, but in our choice of technology we always seem to pick the hard road.
In 2002 when the world was using Real for streaming video my co-director was creating incredible video sharing platforms for the likes of MTV in .NET (with Flash codecs).
When we built a broadcast center, rather than choosing a traditional matrix based n+1 architecture, we designed our own with a patch field that was indestructible with 1+1 mirroring on each channel for complete stability.
When everyone chose Wordpress we chose Drupal, then when everyone chose Drupal we chose SailsJS (Node). When everyone chose Highcharts we stopped using Highcharts and moved to D3js, when everyone chose Backbone we chose AngularJS, and now everyone is choosing ReactJS we might pick Angular 2 (the jury is still out).
So maybe we are just a little contrary, a touch finicky and enjoy choosing our own way. I would like to think we always choose the harder technology because it is more powerful, but then if we chose the easier technology maybe we could build more quickly?
From here on in this piece gets a little geeky so feel free to drop out if you are not interested in the down and dirty.
We have gotten pretty good at Angular over the last few years and we know its nuanaces, but its hard to ignore React.
React is fast, light, it’s new and shiny. So we went ahead and created a test project with React. We avoided anything complex like routing or data modeling, since we are not interested in bolt-ons at this point.
We normally use Angular and pure javascript, but we are planning to switch to ES6 (next gen javascript), so this was a perfect opportunity to try React with ES6 and the two do indeed play quite nicely.
We created a base project easily with Gulp, and used Bable for transpiling from ES6 to ES5, with browserify for module loading.
One thing was immediately apparent. The Angular HTML markup is a thing of beauty
In Angular
That said, once you get used to the React way, it is pretty nice to work with and the React developer tools are also very handy. I did find myself missing Angular’s form validation and deciding to postpone that work for another time. Also React does have JS in one place and Markup in another which I liked. I am not sure whether I like the jsx mixing of javascript and html, but I can see why some coders would.
React feels a lot more like the old days of writing pure JS whereas with Angular we are constantly creating functions, modules, factories, directives and services. At first I missed the structure of Angular but then ES6 to the rescue and I was creating classes and my world started to feel ordered again.
I also missed Angular’s two way binding, but the reality is that for complex apps two-binding and the Angular digest cycle is a performance headache and we often end-up avoiding it.
React is nice and fast, and with the combination of ES6 it can also be very structured.
Will we switch to React? Well that all depends on our trial of the “radically different” forthcoming Angular 2. What I will say is that we will not switch just for an easier life, but I do like what I have seen of React so far.