Data binding is where it’s at now days when it comes to building client-centric Web applications. Developers experienced with desktop frameworks like WPF or web frameworks like ASP.NET, Silverlight, or others are used to being able to take model objects containing data and bind them to UI controls quickly and easily. When moving to client-side Web development the data binding story hasn’t been great since neither HTML nor JavaScript natively support data binding. This means that you have to write code to place data in a control and write code to extract it. Although it’s certainly feasible to do it from scratch (many of us have done it this way for years), it’s definitely tedious and not exactly the best solution when it comes to maintenance and re-use.

Over the last few years several different script libraries have been released to simply the process of binding data to HTML controls. In fact, the subject of data binding is becoming so popular that it seems like a new script library is being released nearly every week. Many of the libraries provide MVC/MVVM pattern support in client-side JavaScript apps and some even integrate directly with server frameworks like Node.js. Here’s a quick list of a few of the available libraries that support data binding (if you like any others please add a comment and I’ll try to keep the list updated):

	AngularJS MVC framework for data binding (although closely follows the MVVM pattern).
	Backbone.js MVC framework with support for models, key/value binding, custom events, and more.
	Derby Provides a real-time environment that runs in the browser an in Node.js. The library supports data binding and templates.
	Ember Provides support for templates that automatically update as data changes.
	JsViews Data binding framework that provides “interactive data-driven views built on top of JsRender templates”.
	jQXB Expression Binder Lightweight jQuery plugin that supports bi-directional data binding support.
	KnockoutJS MVVM framework with robust support for data binding. For an excellent look at using KnockoutJS check out John Papa’s course on Pluralsight.
	Meteor End to end framework that uses Node.js on the server and provides support for data binding on  the client.
	Simpli5 JavaScript framework that provides support for two-way data binding.
	WinRT with HTML5/JavaScript If you’re building Windows 8 applications using HTML5 and JavaScript there’s built-in support for data binding in the WinJS library.

I won’t have time to write about each of these frameworks, but in the next post I’m going to talk about my (current) favorite when it comes to client-side JavaScript data binding libraries which is AngularJS. AngularJS provides an extremely clean way – in my opinion - to extend HTML syntax to support data binding while keeping model objects (the objects that hold the data) free from custom framework method calls or other weirdness. While I’m writing up the next post, feel free to visit the AngularJS developer guide if you’d like additional details about the API and want to get started using it.

Now that you’ve seen several client-side data binding libraries, let’s talk through whether or not it’s worth it to move shift an application’s focus from the server to the client and some of the issues that may come up.

Client-Centric or Server-Centric – That is the Question

Over the past 10 years Microsoft, Sun/Oracle, IBM, and others have been pushing developers to write server-side code that outputs HTML to the browser. As a result, making the leap to client-centric programming can be challenging if you’ve never done it before. Given the disparity across browsers in the past, generating HTML on the server made sense (and still works fine in today’s applications of course) but today’s modern browsers and even browsers going back to IE6 are much more capable of rendering HTML on their own and performing additional functionality. Enhanced browser features, faster JavaScript engines, and more and more mobile devices like the iPad have definitely shifted the trend from server-side development to client-side development.

One of the questions I hear a lot is whether or not server-side templates and code should still be used for data binding or if it’s worth it to move a lot of code down to the client and support data binding there. The answer isn’t simply “use the server” or “use the client” of course since a lot of factors have to be taken into account. I don’t believe in the “one size fits all” approach since applications all have their own unique characteristics. First off, do you (or the team you’re working on) already have a lot invested in server-side technologies? If so then it may be worthwhile to continue doing what you’re doing and sprinkle in some Ajax where appropriate to minimize postback operations. There’s no hard and fast rule that says you have to convert everything to client-side code. If you’re using ASP.NET Web Forms or ASP.NET MVC it’s pretty straightforward to add Ajax functionality without having to write much (if any) JavaScript code. Going that route won’t be as efficient as doing it with pure JavaScript (or using a library like jQuery) but it gets the job done and you can always start learning the new client-centric techniques along the way.

As far as templates and data binding, ASP.NET Web Forms controls like ListView, Repeater, GridView, and others definitely make it easy to bind data to a template that automatically generates HTML for the browser. If you use ASP.NET Web Forms a lot you’re probably familiar with this, but here’s a quick example of a ListView control template that data could be bound to:

<asp:ListView runat="server" ID="CustomersListView">
    <LayoutTemplate>
        <table runat="server">
            <tr runat="server" id="itemPlaceholder" ></tr>
        </table>
    </LayoutTemplate>
    <ItemTemplate>
        <tr>
            <td>
                 <asp:Label ID="CustomerNameLabel" runat="server" 
                    Text='<%#Eval("CustomerName") %>' />
            </td>
        </tr>
    </ItemTemplate>
</asp:ListView>

ASP.NET MVC has data templates, editor extensions, model binders, and other great features that also simplify the process while generating very clean markup on the server. An example of using the EditorFor() method to auto-generate HTML for a Customer type in an ASP.NET MVC view is shown next. If a custom editor template for Customer is defined the template will automatically handle binding properties of the Customer type to different UI controls.

@Html.EditorFor(model => model.Customer)

Server-side programming definitely isn’t the only game in town any more. Custom templates combined with data binding can be used quite successfully on the client-side leading to a more interactive, engaging, and productive application from the client perspective if done right. Whether you write custom code or use a JavaScript library, you can integrate some pretty impressive functionality directly into the client. Going this route definitely requires a solid knowledge of JavaScript but if you already know a language then JavaScript is quite easy to pick up. With the available libraries out there you don’t even have to write a lot of JavaScript code in some cases. As an example, here’s a simple code sample that uses a framework called AngularJS to perform bi-directional client-side data binding:

<!doctype html>
<html ng-app>
  <head>
    <script src="http://code.angularjs.org/angular-1.0.1.min.js"></script>
  </head>
  <body>
    <div>
      <input type="text" ng-model="age" placeholder="Enter your age...">
      <br />
      <h1>You are {{age}} years old!</h1>
    </div>
  </body>
</html>

As the user types into the textbox the “model” property named “age” will be updated. It’s bound into the h1 element using the {{ age }} syntax. Anytime age changes the text inside the h1 element will change as well. Not bad for zero lines of custom JavaScript. For more real-world applications you can go much deeper and perform some impressive data binding operations whether you use AngularJS or one of the other available frameworks.

For me personally, the server versus client discussion all comes down to data exchange.  Do you want the server to send pre-formatted HTML down to the client or do you want it to send raw data that is dynamically formatted on the client? If you’re looking for increases in speed, better performance on mobile devices, and more, then sending raw JavaScript Object Notation (JSON) data can be a win for dynamic applications especially given that the payload sent over the wire will likely be much smaller.

Making the Leap to Client Side Development

Up to this point I’ve focused on client-side and server-side developer skills but they certainly aren’t the only factor to consider. Who will be using the application and how dynamic does it need to be? Will the application be used on mobile devices in addition to standard desktop browsers? If you want to minimize postbacks, move a lot of the application’s functionality down to the client, and provide an overall better experience for the client then learning JavaScript and one or more JavaScript frameworks may be worthwhile. Moving functionality down to the client isn’t a decision that should be taken lightly though especially for teams that don’t have much experience there. Here are a few things to consider:

1. How well does your team know JavaScript?
2. Do you know different JavaScript Patterns that can be used to structure code and make it re-useable and maintainable?
3. How are you going to divide up your JavaScript files to promote re-use, avoid naming collisions, and support future maintenance?
4. How are you going to load your JavaScript files – an important point to consider if you’ll be working with a lot of .js files since they load synchronously by default in browsers.
5. Do you know how to expose JSON data through RESTful endpoints on the server so that it can be consumed by JavaScript clients?
6. How much of your code do you want available for prying eyes to see on the client? Although there are ways to obfuscate JavaScript code, it’s quite easy to get to it using browser developer tools.
7. How will dynamically generating HTML code in the browser affect search engine optimizations?
8. Have you thought through any security implications of moving a lot of application functionality to the client?
9. Does the application need to run offline?

If you answered “no” or were unsure about several of the above questions then it’s time to invest in educating yourself about client-side development practices. As more and more applications move this direction you’ll see more and more customers demanding this type of rich client functionality. I’ll talking about that very subject in upcoming posts.