Skip to main content
Ben Nadel at CFUNITED 2009 (Lansdowne, VA) with: Mike Brunt
Ben Nadel at CFUNITED 2009 (Lansdowne, VA) with: Mike Brunt ( @cfwhisperer )

Adventures In Angular, Episode 224: The Irrational Demonization Of Two-Way Data-Binding In Angular With Ben Nadel

Published in Comments (6)

A couple of weeks ago, I wrote a post titled, "On The Irrational Demonization Of Two-Way Data-Binding In Angular". That post was a reaction to the unfortunate degree of misinformation that I keep seeing and hearing about Angular. And, apparently this post struck a chord with the fine people over at Adventures in Angular (AiA) as I was subsequently invited back to be a guest on episode 224 of the AiA podcast.


 Adventures in Angular (AiA) podcast, episode 224.  

I had a great time talking with Ward Bell, Alyssa Nicoll, Joe Eames, and Aaron Frost (aka, Frosty) about the state of front-end JavaScript frameworks. And, in particular, the growing - and confusing - disdain for Angular amongst some thought-leaders in the web development industry. Much of what I hear is incorrect; which is truly unfortunate since novice developers won't have the experience needed to be able to separate the valid points from the fallacious statements.

On the podcast, I drew a delicious parallel to the Harvey Dent quote from Batman: You either die a hero; or, live long enough to see yourself become the villain. I think this translates perfectly to the world of web development:


 In this industry, you either change technologies often; or, you live long enough to see your choices become hated.  

At this point, basically, all of the front-end frameworks are great and can help you build, rich, robust web applications. It's far more exciting to learn from each framework than to worry about ranking any particular framework as the best. I happen to love Angular because it is powerful, flexible, and has a bad-ass router complete with axillary routes for Enterprise solutions. But, I'm definitely going to be learning more about Vue.js and React.js since it will only help to create a more holistic understanding of JavaScript development.

Underlying all of this is a growing sense that as I get older, I need to take-on more of the perspective that life is just fascinating. And, that I have to worry less about what people think about my choices, and worry only about keeping my mind open to new opportunities and avenues of exploration.

Reader Comments


I loved the Harvey Dent analogy. Glad to see the community recognizing your contributions and helping to get your voice out there!


Let make it clear: Immutable pattern rely on the fact that it is the only way to get an efficient change detection without relying on any convention.
Software engineering relies on pattern and convention so why such a posture for change detection.
For instance, two way binding exists in the Microsoft world for a long time with success through the implementation of INotifyPropertyChanged interface.
As for many pattern/technics when things become complex you should master your subject to make it work right but after having used two way binding for 30 years on mission critical applications (real time, complex business logic, heavy computation…) I can tell that it works well and that it is quite less complex than immutable with redux.
Why relying on a common implementation/convention is bad?
With Angular I've been using OnPush Change Detection with two way binding over custom mutable entity without any problem.
The implementation is crystal clear and very easy.
The only constraint is to use a custom framework over json business model to get the change tracking: is it such a crazy choice ?
When I see all the pitfalls you have to solve with redux architecture when you need to target complex model (involving aggregation and relationship). I prefer to stick to good old recipe as "Two-way binding" over mutable entity rather to embrace a technology that implies an unnecessary complexity.

My 2 cents



I think we are in agreement. I love two-way data binding. And, like you, I've grown to appreciate the OnPush change-detection strategy so that we can limit the amount of work any component in the component-tree has to do based on meaningful input-binding changes.

Of course, if you mutate data in-place, you just have to take into account that it may not be picked-up by the OnPush. As such, you just have to be careful about how / if / when you modify in-memory data structures.

But, I agree that such considerations don't immediately require something more formalized like Redux or other stores.

That said, I am still trying to wrap my head around all the state-management stuff. I don't reach for it super often; but, I want to be able to use it properly when it makes sense.



It's exhausting. Not only am I worried about solving problems; but, now I feel like I have to carry a lot of emotional burden over my choices. Meh.

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel