Adventures In Angular, Episode 224: The Irrational Demonization Of Two-Way Data-Binding In Angular With Ben Nadel
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.
| |
|
|
||
| |
 |
|
||
| |
|
|
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:
| |
|
|
||
| |
 |
|
||
| |
|
|
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!
@Sam,
Thank you, good sir. I had a blast - it's a great bunch of developers.
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
Regards
@Brice,
I think we are in agreement. I love two-way data binding. And, like you, I've grown to appreciate the
OnPushchange-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.
I loved your Harvey Dent analogy, you're so right, and I'm right there with you.
@Phil,
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.