React+Flux Take 1

For 2 weeks now, I have been rewriting part of our website. The Flux architecture has proven to be so simple, gone are the headaches of 2-way binding which I formerly tried to promote. I used to pitch like "With 2-way binding, never will you touch the DOM again!" and "jQuery will be reduced to an AJAX library".

Since I was assigned to a relatively new app to build, we decided on Ember for a more "formal" approach. Months into development, Ember proved too hard to wield and eventually dropped it. I decided move on my way by using a bunch of micro-libraries and crafted my own architecture. I was at peace until...

I was reassigned back to the main app because of the piling technical debt due to its lack of architecture. This time, a senior developer wanted to try out React+Flux. Little did I know, I was already doing the same thing with a bunch of small libraries.

Rather than moving over to React+Flux, I stuck to my routine of using micro-frameworks. They tend to avoid "the hype" - where the community praises a framework so much that they cover up inherent problems. Aside from that, they update "per need" rather than update because they can, keeping the library small and the API stable.

Being familiar with the approach (I must be an FB dev in disguise), it really does excel in flexibility but it has its flaws. References for a "correct way to do it" is almost non-existent because you can do it any way you want. Also, you end up writing too much boilerplate - a problem that bothered a co-developer who is into Ember+Ruby.

One small step for developer, one giant leap to changing the world. If only the same can be said for me leaping over to... never mind. Back to work Joseph, back to work.