The JavaScript Cheese is Moving: Data-Oriented vs. Control-Oriented Programming
In a previous post I listed several of the JavaScript data binding frameworks that are available and talked about why they’re essential as applications move more and more functionality to the client. Data binding is a key aspect of client-centric programming that can significantly minimize the amount of code written, simplify maintenance, and ultimately reduce the number of bugs that crop up in an application. Without data binding you have to locate each control in a page with code and then assign or extract a value to/from it – something I call “control-oriented” programming. Here’s an example of control-oriented programming:
function loadApprovalDiv() { var subTotal = parseFloat($('#SubTotal').text()); $('#ClientSubTotal').val(subTotal.toFixed(2)); var salesTaxRate = parseFloat($('#SalesTaxRate').val()) / 100; var salesTaxAmount = (subTotal * salesTaxRate) * .9; var deliveryFee = parseFloat($('#DeliveryFee').val()); var adminFee = ((subTotal + salesTaxAmount + deliveryFee) * .05); var total = (Round(subTotal) + Round(salesTaxAmount) + Round(deliveryFee) + Round(adminFee)); $('#ClientTotal').val(total); var deliveryAddress = $('#Delivery_Street').val(); //See if they entered a suite if ($('#Delivery_Suite').val() != '') deliveryAddress += ', Suite ' + $('#Delivery_Suite').val(); deliveryAddress += ' ' + $('#Delivery_City').val() + ' ' +
$('#Delivery_StateID option:selected').text() + ' ' + $('#Delivery_Zip').val(); var data = { FinalSubTotal : subTotal.toFixed(2), FinalSalesTax : salesTaxAmount.toFixed(2), FinalTotal : total.toFixed(2), DeliveryFee : deliveryFee.toFixed(2), AdminFee : adminFee.toFixed(2), DeliveryName : $('#Delivery_Name').val(), DeliveryAddress: deliveryAddress, DeliveryDate : $('#Delivery_DeliveryDate').val(), DeliveryTime : $('#Delivery_DeliveryTime option:selected').text(), MainItems : generateJson('Main'), AccessoryItems : generateJson('Accessory') }; $("#OrderSummaryOutput").html( $("#OrderSummaryTemplate").render(data) ); }
Looking through the code you can see that a lot of it is dedicated to finding controls in the page and extracting their values. This works absolutely fine – after all, many applications take this approach. However, when an application is focused on controls and not on data a lot of extra code and plumbing ends up being written which complicates things if control IDs are changed, new controls are added, or existing controls are removed. If you only have a few controls that’s not a big deal, but as the number of controls grows it becomes problematic. I think the cheese is definitely moving when it comes to client-side programming and that the smart money is on building data-oriented applications rather than control-oriented applications like the one above. That’s why we’re seeing more and more data binding frameworks for JavaScript being released.
What is Data-Oriented Programming?
I refer to applications that use data binding as being “data-oriented” (here’s a previous post on that very topic) since they’re focused on the actual data as opposed to writing code to access controls in a given page (“control-oriented” as mentioned earlier). I’ve built a lot of control-oriented applications over the years and found that making the transition to building data-oriented applications definitely requires a different thought process. However, making the move to building data-oriented applications is well worth the effort and ultimately results in better applications in my experience. I think it’s especially important for client-centric applications built using JavaScript.
Although I’m a big fan of jQuery, I’ve started realizing over the past few years that when it’s used mainly to build control-oriented applications (where jQuery is used to find controls, update values, extract values, etc.) a lot of unnecessary code is being written that could be eliminated by using a data-oriented framework. jQuery absolutely has its place in applications, but using it to build control-oriented applications isn’t a good use of its functionality in my opinion given some of the other options now available. It’s great when you require low-level DOM access but not as great when an application has a lot of CRUD operations going on. This probably sounds a bit controversial given the popularity of jQuery (and to people who know I’m definitely a huge jQuery fan), but when you understand what a data-oriented application is and why it’s important, then using a data-oriented framework makes more sense for many CRUD applications.
The Role of Data Binding
By using a data binding library/framework you can wire JavaScript object properties to controls and have the controls and object properties update automatically (a process referred to as “two-way” binding) as changes are made on either side without having to write control-specific code. This means that you don’t have to write selectors to find controls in the DOM and update them or grab values. If you’ve ever worked with application frameworks such as Flex, Silverlight, or Windows Presentation Foundation (WPF) then you’re used to this type of functionality and I’m willing to bet that you can’t live without it. Data binding is addictive once you start using it.
With application frameworks like Flex or Silverlight the data binding engine is built-in so you use whatever the framework gives you. The challenge in the JavaScript world is that there isn’t simply one “best” data binding framework to choose. Many different script libraries/frameworks are appearing on the scene with their own set of pros and cons.
I’m a big fan of data binding libraries such as KnockoutJS but have been spending more and more time lately using a framework called AngularJS to perform data binding, routing, Ajax functionality, validation, and much more when building data-oriented applications. For a “getting started” example of using AngularJS for data binding check out this post to learn a few fundamentals. Data-Oriented applications are definitely where it's at in my opinion and where things are heading.