Having written some pretty complex web applications, it was clear to me that this hodge-podge way of creating a richer user experience had to come to an end. It had to end because it really wasn’t that rich of an experience to start with. Pages would sometimes repaint when forms were used and sometimes they would update in place. Needless to say the code was overly complex with no generally accepted design patterns.
As I am far into my second significant application using Bindster I am absolutely convinced that data-binding frameworks are central to the evolution of web-based software development. My productivity, level of robustness and agility have all improved dramatically as a result of using Bindster. I am not going to cover Bindster in detail as that has been done on the Bindster web-site but rather talk a little bit about how to think about data binding frameworks and how Bindster differs from other frameworks released since I started writing Bindster.
Thinking the Data Binding Way
For years programming had consisted of input -> compute -> output. Dan Bricklin and Bob Frankston decided that this approach was not going to be very useful for end-user computing and so VisiCalc, the first spreadsheet was born. Anyone who uses a spreadsheet knows that you think differently about things with a spreadsheet. What you see on your screen is the result of a series of calculations on your data which represents the current “state” of the problem being solved. If you change that state, everything is recomputed.
This is exactly the way you think of things when you use a data-binding framework. You get your data setup based on the state of things as returned by the server and then you just map it to the display through data-binding. The magic of data-binding, however, is that unlike a spreadsheet this mapping is bidirectional. Anywhere you map to editable form elements the data will be updated as the user changes it. So the state of your application changes as a result of one three things:
- Data is retrieved from the server
- The user changes the data bound through form elements
- The user requests a specific action to take place via a button/link and your code kicks in
This is different than the approach taken by other modern client-side tools like Backbone or jQuery where the code drives everything. With data binding, you don’t need to render views or deal with events other than those related to explicit user actions like the press of a button or clicking on a link. This results in a more functional programming experience where everything is based on the state of the data model.
These are some of the key differences between Angular and Bindster.
- How they bind – The magic that binding frameworks provide is to know when data has changed and to then update the screen so the change is visible. Angular does this by keeping a digest of the data and then looking to see if that has changed and then re-rendering elements connected to the modified data. The data is examined every time an event occurs. Bindster takes the opposite approach. It re-renders every time an event occurs. It only renders portions of the screen that are visible and it only updates the screen if the data value does not match a cached copy for that particular display element. Both approaches have their pluses and minuses. If you have very large amounts of HTML and very little data, the data-trigger approach of Angular can be faster. If you have very large amounts of data the display-trigger approach of Bindster can be faster. In practice both work well.
Bindster uses three different techniques to cover the capabilities in directives:
- Iteration and conditional inclusion of DOM elements is part of the core of BINDster.
- DOM Controllers are used to create a custom interface between the binding mechanism and DOM elements to facilitate new controls such as sliders.
While these differences are significant both frameworks are capable of garnering huge productivity improvements. My preference for Bindster and the reason that I continue to use and support it are that I feel the ability to create custom tags through mappers and the ability embed more of the binding functionality into script and in particular the object model makes it useful enough to continue using Bindster. This latter function has become particularly important for object oriented development where I want more and more rules to be embedded in the object definition rather than the markup.