ReactJS - the way forward

Let me tell you a story...

A long time ago I was at a point where my beloved technology, Delphi, started to decay as a viable option for future development. It started to change into this giant big ball of everything point-and-click and the beauty of the Object Pascal language was lost in the process. From my time with Delphi one particular component has always been my favorite: the TDrawGrid. Imagine if you will a grid component that all it needs is a prescription on how to present data in cells. That's right - present data in cells, not specify what is in them through some intermediate state. In fact TDrawGrid was so awesome each and every project that had to do with presenting data in a grid that I wrote was using it instead of TStringGrid. Making text bold or drawing icons in cells was just simply a matter of defining the correct handler and that was it!

You'd think that the ease of presenting data in a fancy way was the best part of it but it was not. The best part was that if the underlying data changed all it took was to invalidate a cell and the refresh of content happened automagically!

Like I wrote before Delphi derailed a lot from what I liked and it was time for me to choose a different boat to sail from now on. Realistically speaking there were only 2 choices: .NET and Java. Since I was working in a Java shop at the time it was only natural to lean towards Java and so I did. I started working on web applications, remote Swing applications, backend services - you name it. That was the time when I was introduced to Java Server Faces - a technology I intuitively knew was just bad. I looked for alternatives and as it turned out Groovy and Grails was my salvation at the time. I spent a year working on an internal application that I created from scratch in Grails and I was having the best time of my life.

Forward a few years and I felt like shedding the burden of being a Java developer and turned my attention to Ruby, Python and JavaScript. I absolutely fell in love with Sinatra and that was why most of my time outside of work I spent learning the ins and outs of it learning Ruby along the way.

Interestingly enough life has thrown me in the direction of client-side applications. That obviously means JavaScript, HTML and CSS. I have worked with jQuery, a bit backbone, AngularJS, Ionic.. And at every single turn it felt like the MVC pattern while great when working on the server is a bit artificially jammed into the browser world. It just didn't feel right, you know? The apogee was when I started working with EmberJS a few months back. Although I think that having a framework that gives you pretty much everything is not necessarily a bad thing (see Ruby on Rails) my opinion is that if you want to create an application that will prove resilient over time taking an all-in approach is not necessarily the best way to go.

And so, a few weeks back I arrived at a presentation from 2014 (man! so many good things happened in 2014!!!) where a nice lady, stressed out like hell, was trying to convey a message that MVC seems to not account for a good, maintainable architecture in the browser. Luckily enough there was an alternative - ReactJS. I spent a couple of days watching videos on ReactJS and Flux and the biggest surprise was how similar it is to the TDrawGrid from Delphi! Finally there is a single source of data that had a simple way of being presented and the refresh is just there and you don't even have to think about it. No bindings, no mutators, no fancy conventions like Ember enforces - just a simple render method that spits out the prescription of how things should look like.

Just like JSF and SwingML/XwingML in Java I really hope that MVC frameworks on the client will one day be a bad memory that lingers to remind me of times before ReactJS. Who knows, maybe I'll even go as far as starting a http://ihateemberjs.com one day like I did with http://ihatejsf.com? Who knows :D