Moving from Server-Side to Client-Side Web Development

Data binding is where it's at nowadays, especially in regard to building client-centric web applications. Developers experienced with desktop frameworks such as Windows Presentation Foundation (WPF) or web frameworks such as ASP.NET, Silverlight, and others are used to being able to take model objects containing data and bind them to UI controls quickly and easily. For developers moving to client-side web development, the data-binding story has been problematic because neither HTML nor JavaScript natively support data binding.

Although it's certainly feasible to write client-side data-binding code from scratch (many of us have done it this way for years), doing so is definitely tedious and not exactly the best solution when it comes to maintenance and reuse. The big question to ask, though, is "Is it worthwhile to move server-side code to the client?" I'll discuss that topic in this article and address a few script libraries that you can use if you decide to make the move.

Related: "Explore the New World of JavaScript-Focused Client-Side Web Development"  and "Localize Your Client-Side JavaScript Applications"

Server-Side vs. Client-Side Development

Over the past 10 years, Microsoft, Sun/Oracle, IBM, and other computer industry leaders 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. Given the disparity across browsers and generally poor JavaScript engines in the past, generating HTML on the server made sense (and that technique certainly works fine for today's applications as well). However, enhanced browser features, faster JavaScript engines, and the proliferation of mobile devices such as the iPad have definitely shifted the trend from server-side to client-side development.

One of the questions I hear a lot is whether server-side templates and code should still be used for data binding or if it's advisable 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, because many factors must be taken into account. I don't believe in the "one-size-fits-all" approach because all applications have their own unique characteristics. For example, a simple factor to consider is whether a given team has invested a lot into server-side technologies. If so, it might make sense to continue building server-side focused applications while sprinkling 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 a pretty straightforward task to add Ajax functionality without having to write much (if any) JavaScript code. Going that route won't be as efficient as using pure JavaScript (or using a library such as jQuery), but it gets the job done, and you can always start learning the new client-centric techniques along the way.

In regard to templates and data binding, ASP.NET Web Forms controls such as ListView, Repeater, GridView, and others make it easy to bind data to a template that automatically generates HTML for the browser. Listing 1 shows a fairly standard example of a ListView control template that data can be bound to.

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. For example, the following code uses the EditorFor() method to auto-generate HTML for a Customer type in an ASP.NET MVC view. 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 isn't the only game in town, though. Generating HTML on the server works well and has the benefit of working in just about any browser available, but custom templates combined with data binding can be used quite successfully on the client side, leading to more interactive, engaging, and productive applications when done correctly.

Whether you write custom code or use a JavaScript library, you can integrate some impressive functionality directly into the client. Going this route definitely requires a solid knowledge of JavaScript, but if you already know a language, JavaScript is quite easy to pick up. In some cases, you don't even have to write much JavaScript code, if you use one of the available JavaScript libraries. As an example, Listing 2 shows a simple code sample that uses a framework called AngularJS to perform client-side data binding.

                              
        You are {{age}} years old!          

As the user types into the text box, the model property named "age" is updated. It's bound into the h1 element using the {{ age }} syntax. Whenever age changes, the text inside the h1 element changes as well. Not bad for zero lines of custom JavaScript! In applications that are more "real world," you can go much deeper and perform some involved data-binding operations on data retrieved from a server, using AngularJS or one of the other available frameworks.

For me, the server-side versus client-side development discussion all boils 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 only raw data that's dynamically formatted on the client? If you're looking for increases in speed, better performance on mobile devices, and more, 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 Jump 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 factors 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 enhanced experience for the client, then you might find it useful to learn JavaScript and one or more JavaScript frameworks. Moving functionality down to the client isn't a decision that should be taken lightly, though, especially for development teams that don't have much experience working on the client side. Here are a few ideas to consider in your decision:

If you answered "no" to or were unsure about several of these questions, it's probably a good time to educate yourself about JavaScript and client-side development practices. As more applications move in this direction, you'll see more customers demanding browser-based rich client functionality.

Client-Side Data-Binding Libraries

Over the past few years, several different script libraries have been released to simplify the process of binding data to HTML controls. In fact, the subject of data binding is becoming so popular that it seems as if a new script library is 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 such as Node.js.

Table 1 shows a list of several client-side data-binding script libraries that can be used. My personal favorite at this point is AngularJS from Google, but many other great options are available -- for instance, KnockoutJS.

Explore the Client Side

Client-side development is becoming more and more popular. Although some applications might work well by letting the server generate all the HTML necessary, many applications can be enhanced by integrating client-side data binding that dynamically converts JSON data returned from the server into HTML. In a future article, I'll provide a closer look at one of the available libraries for data binding, AngularJS.

Learn more about client-side development: