I'm using redux both at my day job and on my side startup. For the day job, right now, it's simple enough we don't really need redux. But it was already in play when I joined and it's not really a bad thing in terms of team communication in code so... On my side startup, I definitely need redux. I have a lot of related data that is rendered in multiple ways and soon I'll be hooking up websockets and emitting changes from server-side that will flow into the client UI via redux to keep some things in sync.

Redux does add complication. But it also cleanly solves a big problem. I've heard good things about mobx instead of redux in terms of reducing boilerplate/total lines of code. So that might be one thing to try if starting a new project today or refactoring.

The purposed solution in the blog is pretty bad. It only works if you have a few things being updated. It might work fine for the author's use case but it's a bad idea to assume it will work well for all use cases. If you want to go this route, please try Backbone.js and come back when you get sick of ghost event listeners (event listeners that didn't get unbound). Obviously, there are ways to work around those issues but it requires understanding them (both by you and any other devs who join the project -- some with less experience might have no idea about these gotchas).