Page 49 - MSDN Magazine, October 2017

Hence, by simply including jQuery on your page, and no other JavaScript, you’ve already consumed 6 times as much bandwidth as you would using a managed AJAX approach. As you start con- suming jQuery in your own JavaScript, this number skyrockets.
Pulling in jQuery UI in its minified and zipped version makes your JavaScript portions increase by 73.5KB. Simply including jQuery and jQuery UI on your page increases its size by an addi- tional 103.4KB (103.4KB divided by 4.8KB becomes 21.5 times the bandwidth consumption). At this point, you still haven’t created as much as a single UI element on your page, yet jQuery+jQuery UI consumes almost 22 times the space of your managed AJAX approach. And you can create almost every possible UI widget you can dream of with this 5KB of JavaScript, including most UI controls that jQuery+jQuery UI can create. Basically, regard- less of what you do, you’ll rarely if ever exceed this 5KB limit of JavaScript. And the other parts of your app, such as your HTML and your CSS, might also become much smaller in size.
Using this approach, you create rich AJAX UI controls, such as AJAX TreeView controls, DataGrid controls and TabView con- trols. And you never need additional JavaScript as you create these widgets. There’s also no new knowledge required to use these con- trols. You simply use them (almost) the same way you’d consume a traditional WebControl from ASP.NET.
The managed AJAX approach has two distinct ways of handling the HTTP requests to your page. One of the handlers is the normal plain HTTP request, which will simply serve HTML to the client. The other handler lets you check for the existence of an HTTP post parameter. If this parameter exists, the handler will render only the changes done to each control back to the client as JSON. During an AJAX request, each control created by modifying the page’s control hierarchy will be automatically recreated for you, with the properties it had in your previous request. On the client side, you have a general handler that handles your JSON properties to your controls and generically updates the attributes and DOM event handlers of the DOM elements on the client.
This approach has a lot of positive side effects, such as not fight- ing the way the Web was originally created by rendering the HTML elements as just that—HTML elements. That implies that seman- tically, your Web apps become more easily understood (by search engine spiders, as an example). In addition, it creates a superior environment for actually modifying things on the client, if you wish to use the best of both worlds.
You can still combine this approach—with as much custom JavaScript as you wish—at which point you can simply inspect the HTML rendered in your plain HTML requests. Compare this to the “magic div” approach, used by many other AJAX UI libraries, often containing megabytes of JavaScript to create your DataGrids and TreeViews.
Thus, you can understand that the 100 times faster and more responsive figure isn’t an exaggeration. In fact, compared to all the most commonly used component UI toolkits, used in com- bination with C# and ASP.NET, it’s usually between 100 and 250 times faster and more responsive with regard to bandwidth con- sumption. I recently did a performance measure between the managed AJAX TreeView widget in System42 and three of the
largest component toolkits on the ASP.NET stack. I found the difference in bandwidth consumption to be somewhere between 150 and 220 times faster and more responsive.
To illustrate what this implies, imagine you’re on an extreme- ly slow Internet connection, where it takes one second to down- load 5KB of JavaScript. This implies one second to download the managed AJAX JavaScript and possibly as much as three min- utes 40 seconds to download the JavaScript parts of some of the other toolkits. Needless to say, imagine what the difference would be with regard to conversion if you built two e-commerce solutions with these two approaches.
Show Me the Code
OK, enough talk, let’s get down and dirty. First, download Phos- phorus Five at bit.ly/2u5W0EO. Next, open the p5.sln file and build Phosphorus Five, such that you can get to your p5.ajax.dll assembly. You’re going to consume p5.ajax.dll in your Web app as a reference, so you need to build it before you proceed. Notice that Phosphorus Five consists of more than 30 projects, but in this article I’m focus- ing on the p5.ajax project.
Next, create a new ASP.NET Web site in Visual Studio. Make sure you create a Web Forms application. In Visual Studio for Mac, you can find this under File | New Solution | Other | .NET | ASP.NET Web Forms Project.
Create a reference inside your newly created Web site to the already built p5.ajax.dll assembly and modify the web.config to resemble the following code:
<?xml version="1.0"?> <configuration>
<system.web>
<pages clientIDMode="Static">
<controls>
<add assembly="p5.ajax" namespace="p5.ajax.widgets" tagPrefix="p5" />
</controls>
</pages>
<compilation debug="true" targetFramework="4.5" /> <httpRuntime targetFramework="4.5" />
</system.web> </configuration>
The important parts in this code are the “clientIDMode” and the “add assembly.” At this point you can use any of the p5.ajax controls from inside your .aspx markup by prefixing them with p5. Make sure you modify the Default.aspx page’s content to resemble the code in Figure 1.
Figure 1 Creating a Page with a Single Button that Changes Its Text When Clicked
<%@ Page Language="C#" Inherits="foobar.Default" %> <!DOCTYPE html>
<html>
<head runat="server">
<title>Default</title> </head>
<body>
<form id="form1" runat="server">
<p5:Literal
runat="server"
id="foo"
onclick="foo_onclick" Element="button">Click me!</p5:Literal>
</form> </body>
</html>
msdnmagazine.com
October 2017 45