I don't think Android's DataBinding necessarily has a lot in common with Angular but I am not very familiar with web development so I might not a very knowledgeable opinion in this topic.
What DataBinding allows is to automatically produce 'optimal' binding logic :
-the result is entirely native code, nothing is created at runtime, nothing uses reflexion, so there is no obvious perf cost to databinding.
-the binding logic tries to be as smart as possible.for example if only some properties of the binding have changed, only the corresponding setters will be called. This can be interesting performance wise because instead some setters can be quite costly. Text is an obvious example, it might seem trivial but correctly rendering text is very complex, so if you can skip a setText instruction, you might gain some time on your UI computation, allowing you to more easily stay in the 16 ms timeframe. Even very good UI code usually does not optimize that much.
-binding code is often not very interesting : 'if name not empty then setText, otherwise set visibility to gone'. Reducing the number of code needed to achieve this is a good win, productivity wise.
If I am entirely fair, there are 2 things I strongly dislike about DataBinding :
-The binding code appears in the layout files. Keeping code and layout separates was a very good idea. It seems that the UI Frameworks team thinks that it is an acceptable compromise though, so I am ready to give them the benefit of the doubt.
-I wish to use something better than XML for layouts. Performance wise it does not matter since the compiler transcodes the XML layouts files in a more optimal binary format, but it is unwieldy at best for human writers & readers. The noise/signal ratio is just very poor and it lacks some features, for example letting us make some operations in the layout declarations 'width = dimensionA + dimensionB' would be very useful (it is of course doable in a custom view's code, but it would save us some boilerplate code to directly allow us to do this declaratively in a layout).
It makes simple apps simpler, and that's a good thing. It also gets coders on the right track toward a ContentProvider and Cursor-based implementation of the observer model, instead of going off into the weeds with an ORM.
One of the really neat things about Android is this type of thing is generally backported via the Support Library. In fact Data Binding is available all the way back to Android 2.1:
6 comments
[ 2.9 ms ] story [ 20.1 ms ] threadEveryone was super excited about two years ago with data binding in the web, until they started having tons of performance problems (e.g. angular.js).
Yes, native code by definition runs faster than javascript in the browser. Orders of magnitude faster.
Databinding in the browser also wasn't designed in, there's no direct support. AngularJS is a wrapper around a ton of functionality.
If an API is built to support that natively, it will fly. Period.
It's also something iOS and OS X have had FOR YEARS. no one can complain about those being poor performers.
What DataBinding allows is to automatically produce 'optimal' binding logic :
-the result is entirely native code, nothing is created at runtime, nothing uses reflexion, so there is no obvious perf cost to databinding.
-the binding logic tries to be as smart as possible.for example if only some properties of the binding have changed, only the corresponding setters will be called. This can be interesting performance wise because instead some setters can be quite costly. Text is an obvious example, it might seem trivial but correctly rendering text is very complex, so if you can skip a setText instruction, you might gain some time on your UI computation, allowing you to more easily stay in the 16 ms timeframe. Even very good UI code usually does not optimize that much.
-binding code is often not very interesting : 'if name not empty then setText, otherwise set visibility to gone'. Reducing the number of code needed to achieve this is a good win, productivity wise.
If I am entirely fair, there are 2 things I strongly dislike about DataBinding :
-The binding code appears in the layout files. Keeping code and layout separates was a very good idea. It seems that the UI Frameworks team thinks that it is an acceptable compromise though, so I am ready to give them the benefit of the doubt.
-I wish to use something better than XML for layouts. Performance wise it does not matter since the compiler transcodes the XML layouts files in a more optimal binary format, but it is unwieldy at best for human writers & readers. The noise/signal ratio is just very poor and it lacks some features, for example letting us make some operations in the layout declarations 'width = dimensionA + dimensionB' would be very useful (it is of course doable in a custom view's code, but it would save us some boilerplate code to directly allow us to do this declaratively in a layout).
http://developer.android.com/tools/data-binding/guide.html