Client-Side Templates FTW!

Because I like blogging about technologies other developers are using and taking all the credit for them, I’d like to introduce you all to Client-Site Templates, a “new” technology supported by ASP.NET.

Thanks to the whole Web 2.0 thing and AJAX becoming more mainstream, web devs are thinking of more and more creative ways to present data. The first major breakthrough (and most used today) is the async post backs, where data from a browser is sent back to the server without having to refresh the entire page. That alone improved the user experience tenfold in my opinion, as you no longer have to wait for browsers to re-render menus or other static data when you’re only changing a small element on the page (i.e. selecting from a drop down list). Alot of this AJAX stuff was first presented to web devs in the form of 3rd party libraries (prototype, jQuery, etc.), but Microsoft (and I’m sure other server-side languages) have begun to support AJAX by combining existing server controls with AJAX functionality.

The newest wave in this AJAX movement is Client-Side Templates. While this has been going on for awhile, ASP.NET is starting to formally support it with some Web Services and the like. Right now, when you go to an average website, what’s happening is this:

  • User clicks “submit”
  • Browser sends entire form’s contents to the webserver
  • Webserver redirects request to asp.net application
  • asp.net processes request (talks to DB, etc.)
  • asp.net goes through each server control defined on the page and renders the HTML using data
  • web server returns HTML to browser
  • browser redraws entire page

With AJAX, you get this:

  • User clicks “submit”
  • Browser runs some javascript code to send only data that’s required (as defined by the page) to webserver
  • Webserver redirects request to asp.net page
  • asp.net processes request
  • asp.net only renders controls in response to request (i.e. only re-renders about 20% of the page)
  • web server returns JSON to the browser
  • javascript on the browser redraws only a portion of the page

AJAX is better, as there’s less load on the server (only dealing with areas it’s concerned about instead of the whole page), and the user only sees a targeted portion of the webpage change in response to their input. With Client-Side Templates, this takes the process one step further:

  • User clicks “submit”
  • Browser runs js to send targeted input
  • Webserver redirects request to web service
  • Web service processes request
  • Web service returns JSON (no rendering of HTML controls required) to the browser
  • Browser runs javascript to render controls based on template defined on page

So the server isn’t bothering to render controls anymore, instead we’re using javascript on the browser to create the HTML on the client. This not only saves the server a step in processing, but also cuts down the amount of data that is sent back and forth. To illustrate:

Old Way
1
2
3
4
5
6
7
8
9
10
<!-- url: GET www.intraiq.com?user=chad&age=26&
              birthday=02/05/1983&favoritegames=quake,wc3,gow2,fo -->
<html>
  <head>
      <title>page title</title>
  </head>
  <body>
      Hey <span>Chad</span>, how's it goin?  You're <span>26</span>!
  </body>
</html>
New Way
1
2
// url: GET www.intraiq.com?name=Chad&age=26
{Name: Chad; Age: 26;}

Also, because it’s a webservice, we can start applying built-in HTTP caching checks to the service calls. ASP.NET AJAX automatically adds the if-modified-since & e-tag (a hash code used to identify objects, i.e. an image) headers to web service calls, and we can code our webservices to handle that – if a web service determines that there’s been no change in its output based on the modified check date and/or e-tag, it can simply return the “304? HTTP response code instead of data, and ASP.NET AJAX will simply stop there. This is especially useful if someone’s polling a service constantly (i.e. stock quotes, sport scores, etc) and drastically cuts down on both server load (just check if data’s changed, don’t actually retrieve or process it), and data transfer (sending “304? instead of ”{Name: Chad; Age: 26;}“.

And of course I have to give props to both Thu and Wilson for actually implementing these ideas. I’m just the one who gets to talk about them.

Comments