The JavaScript Cheese is Moving: Data-Oriented vs. Control-Oriented Programming

Update: 8/5/2013

CheeseIn 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.

comments powered by Disqus

6 Comments

  • Looking forward to the Angular posts!

  • Thanks Dan, I always find your blog entries very useful for our work. Yes, AngularJS is very intuitive and we are also learning it. We will keenly wait for your AngularJS posts.

    --Thanks Again :)

  • The problem with JavaScript and data binding is that properties can't have get and set (there is a standard but no one implements it yet). Hence all of these libraries require hacks and don't work with control suites unless they have specific support, or you use the (horrible) HTML 5 controls (which have very limited support in most browsers other than Chrome). And most of the control manufacturers don't implement friendly properties for databinding:

    1. A Value property or similar that returns a value for the control.
    2. Nullable support -- all controls must have it with the value property returning null with no entry.
    3. 2 way binding with their parent input control. (this would allow almost all binding libraries to work automatically with this one change)

    This is the most important shift to get html+javascript to be truly useful for LOB applications. But javascript is HORRIBLE at it, and the control manufacturers are even worse.

    Here's hoping these things change fast... but getting enough browser penetration takes years so...

  • I dont think Ive caught all the angles of this subject that the manner youve pointed them out.

    Youre a true star, a rock star man. Youve got
    so much to say and identify so much about that the subject that I think
    you should just teach a class about it

  • Loved the way you explained, getting interested in Angular now. Waiting for your second post.

  • Really enjoyed the post, do these work with PHP at the server side?

Comments have been disabled for this content.