Today we are witnessing and contributing to an interesting and unique phenomenon. The Web is undergoing a revolutionary change right before our eyes as a result of our actions. Ten years ago, the Web was in its infancy and based on an infrastructure that was simple, ubiquitous, and effective. A decade of Web evolution has resulted in the building of a thick layer of abstraction on the server side, but it hasn’t changed the basic infrastructure – HTTP protocol and pages. The original infrastructure which was the chief factor in the rapid success of the Web model of applications is still there.
Nobody can reasonably risk changing the pillars of the Web today. Nobody who is savvy enough can even consider replacing HTTP with something else or HTML with a richer format. Why? To avoid disturbing the conditions that make it possible for more than 90% of the browsers available to support the same set of features. So the next generation of Web applications will still be based on the HTTP protocol and HTML pages. However, the contents of HTML pages and the capabilities of the server-side and client-side machinery will need to change to provide a significantly richer user experience and more reliable and extensible architectures.
This article offers an architectural perspective on Silverlight and ASP.NET AJAX, aimed at emphasising the challenges and opportunities that are waiting to be taken and seized. But to understand the future, a look at the past is in order.
A very brief history of the Web
In the summer of 1991, Tim Berners-Lee went live with the very first Web site of the history of computing at the nuclear physics laboratory of CERN in Geneva, Switzerland. It was only two years later – in the spring of 1993 – that CERN opened the underlying technology to the public, waiving any copyright on it. The age of the Web could officially begin.Tim Berners-Lee and Robert Cailliau defined a network protocol and document format to build and share documents regardless of their physical location on the network. The transportation protocol was HyperText Transfer Protocol (HTTP) and the document format was HyperText Markup Language (HTML). It is not a mere coincidence that both acronyms include the word hypertext. In the very early days of the Web the primary goal was to achieve a smarter, more dynamic organisation of information through logical hyper-textual links. The syntax used to formalise the existence of a logical link between the current document and an external document that contained related information was called the hyperlink. In fact, HTML was designed about twenty years ago to represent some content and references to external documents in the same format. HTTP was created as a standard transportation protocol to move requests and responses over the network. In the next few years, the first browsers appeared and the rush began to make HTML more and more powerful and customised.
One of the first enhancements made to the syntax of HTML was the support for a programming language – JavaScript. The first browser to deploy a JavaScript engine was Netscape 2.0 in the December of 1995. JavaScript was introduced to give authors of Web-deployed documents the ability to incorporate some logic and action in HTML pages. In the following ten years, we witnessed the progressive enhancement of HTML and JavaScript that culminated in the definition of worldwide standards. Then, at the beginning of 2005 Jesse James Garrett coined a new acronym – Asynchronous JavaScript and XML, or AJAX for short. The introduction of AJAX opened up a new world of opportunities for Web professionals. It also made the Web mark a turning point and, perhaps, come of age.
A paradigm shift
Today Web pages work by submitting forms to the Web server and receiving updated markup. The browser captures any requests for a submission, collects any input data in the current form, prepares an HTTP request, and finally sends it. When the response arrives, the browser gets and parses the contents, and manages to render it according to the declared type of the content. If the content is HTML markup, the old page is replaced with that obtained from the freshly downloaded markup.This paradigm is effectively described by the expression stop-and-go. Just like when stuck in traffic, users work a bit with the page, then submit it and wait for some response. When the response is ready, users work for some time and then submit again. And so it goes on. Only one request per session can be served at a time by the browser. So there’s a wait – potentially a long wait – between two successive calls. Also there’s no state that can be maintained on the client. And there’s no server-side action that can be taken from the client without fully refreshing the user interface.
For the growing complexity of modern Web pages, this paradigm is more outdated every day, and AJAX is the emerging new paradigm for Web applications. From a developer perspective, AJAX collectively refers to a set of development components, tools, and techniques for creating Web pages that give users an overall better experience. According to the AJAX paradigm, Web applications work by exchanging data rather than pages with the Web server. An AJAX page sends a request with some input arguments and receives a response with some return values. The code in the client browser orchestrates the operation and updates the user interface. From a user perspective, this means that faster roundtrips occur and, more importantly, page loading is quicker and the need to refresh the entire page is significantly reduced. As a result, a Web application tends to look like a classic desktop Microsoft Windows application. It is allowed to invoke server code from the client, run and control server-side asynchronous tasks, and feature a strongly responsive and non-flickering user interface.
Desktop-like applications
An AJAX application can have a number of features that minimise user frustration, provide timely feedback about what’s going on, and deliver great mashed-up content. Hold on, though! This doesn’t mean that AJAX Web applications are the same as desktop applications; they simply allow for a few more desktop-like features. For building truly AJAX applications, you have to implement the new Web paradigm using completely new architectural schemes and patterns. And ASP.NET with its postback mechanism and viewstate is arguably the right tool.On the other hand, the Microsoft Web platform is slowly but steadily evolving to catch the essence of the AJAX paradigm and sync up with developers’ expectations. Microsoft is doing this by adding new toolkits and products at a very speedy pace. Silverlight is one of these, but I suggest you keep an eye on the technologies coming out with the next version of ASP.NET (3.5) – extensions such as REST data services and the MVC Framework.
But why is classic ASP.NET arguably the right tool? Quite simply, ASP.NET fully incarnates the old model of the Web that is centered around JavaScript and HTML. But there are strong reasons today to reckon these two pillars represent the bottleneck to AJAX evolution.
Why JavaScript is now obsolete
Initially the Web, compared to desktop applications, was a whole step backwards in terms of interactivity and responsiveness. And if you think back to the reasons that led CERN researchers to create the Web, you can hardly blame it. The chief factor in the success of the Web was its inherent simplicity, well balanced by deployment ease and ubiquity. But the problem of having programming power on the client was ignored for many years. Both Java applets and ActiveX objects have been considered by some to be the killer technology about to open up a new era for client development over the Web. But both these hopes were disappointed. Today, JavaScript is still the main tool available for doing some development on the client in a cross-browser way and without using plug-ins of any kind (e.g. Flash).JavaScript is an interpreted, dynamic binding, and weakly-typed language with first-class functions. It was influenced by many languages and was initially designed to look like a simpler Java for the ease of non-expert page authors. Worse yet, JavaScript is subject to the browser’s implementation of the engine. The result is that the same language feature provides different performance on different browsers and may be flawed on one browser while working efficiently on others. This makes it hard to write good, cross-browser JavaScript code and justifies the love/hate relationship (well, mostly hate) that many developers have with the language.
In spite of all of this, JavaScript works well for the majority of Web applications. And nothing better has been invented as yet. All things considered, JavaScript has two main drawbacks: it is an interpreted language (significantly slower than a compiled language) and is not fully object-oriented. Extending JavaScript is not as easy and affordable as it may seem. Being so popular, any radical change will risk breaking a number of applications. But, on the other hand, radical changes are required to face the incoming challenges of AJAX. A proposed standard for JavaScript 2.0 is discussed in this paper. You can also read Brendan Eich’s comments on the feature set in JavaScript 2.0. It is important to note that the proposed standard is intended, among other things, to achieve better support for programs assembled from components and packaged. Time will tell, however, if and how JavaScript will undergo a facelift.
Why HTML is now obsolete
Today’s Web pages use HTML to express their contents. But what’s HTML, exactly? Is it a document format? Or is it rather an application delivery format? Or is it neither of these? If you look at the origins of the Web, you should conclude that HTML is a document format designed to contain information, some images and, more importantly, links to other documents. Today, we use HTML pages with tons of tables, CSS styles, and zillions of images used not only for the pictures they contain, but also to add compelling separators with rounded and shadowed borders to otherwise ugly, rectangular blocks of markup. The original idea of what an HTML document had to be seems to be irretrievably lost.Whichever way you look at it, HTML seems to be the wrong tool. If you’re looking for a document format, HTML is outdated because it lacks the formatting and layout capabilities that you find, for example, in the Office Open XML formats. In addition to formatting, the Office Open XML format contains building blocks and relationships to package, distribute, and render documents. If you’re looking for an application delivery format, then HTML lacks a richer layout model, built-in graphics and media capabilities.
Just as with JavaScript, though, getting rid of HTML is not a decision to make lightly because HTML is popular and broadly diffused. Embedding richer contents in a thin HTML wrapper might be a good compromise.
The role of ASP.NET partial rendering
There are two opposing forces that apply to the Web. One is the force of evolution heralded by AJAX and geared towards the adoption of new technologies and patterns. The other is the force of continuity that tends to make things evolve, but without neatly breaking with the past and present. Translated to AJAX, the force of continuity is heralded by ASP.NET partial rendering.With ASP.NET partial rendering, there’s nothing really new architecturally speaking. It’s just the same ASP.NET model revamped with a set of tricky solutions that make page rendering smarter and, more important, limited to the fragments of the page that really need a refresh. Partial rendering is an approach that works “partially” in the context of an evolving Web application. It has inherent limitations and should be considered a short-term solution for adding AJAX capabilities to legacy applications. This said, a significant share of today’s Web applications just need a bit of facelift to look better and run faster and partial rendering is the perfect remedy.
The ASP.NET AJAX emerging model
If ASP.NET fully incarnates the old model of the Web that is centered around JavaScript and HTML, should we conclude that ASP.NET is dead? And if so, what has the future got in store for us? The ASP.NET application model based on postback and viewstate is, technologically speaking, probably a thing of the past. Of course, this doesn’t mean that thousands of pages will be wiped out tomorrow and that hundreds of applications must be rewritten. It only means that a superior model is coming out that is more powerful both technologically and architecturally. This model is based on two layers – a client front-end and a server back-end. The front-end sends requests to the back-end and the back-end sends back responses. Back-end endpoints are identified through URLs and expose data feeds (mostly JSON data streams) to the client. The back-end is only a façade that receives calls and forwards them to the business layer of the application. Figure 1 depicts the whole model.
Figure 1: The AJAX-based emerging model for ASP.NET applications
The back-end is easy to devise. It is made of services and on the Microsoft platform this can only mean ASP.NET Web services or Windows Communication Foundation (WCF) services, both adapted to work with JSON serialisation. Note, though, that WCF services require the .NET Framework 3.5 to support JSON serialisation. The front-end manages the user interface and incorporates the presentation logic. How would you code the presentation logic? Using which language or engine? And using which delivery format?
To really be cross-browser, you should use JavaScript and HTML, but both JavaScript and HTML have a number of limitations as we’ve seen earlier. These limitations can be partially worked out and mitigated using a number of libraries and widgets and still can bring you to deploy effective applications. But the real turning point is Silverlight.
The idea of Silverlight – the concept
Microsoft Silverlight is a cross-browser, cross-platform plug-in for building rich Internet applications that works on Windows and Mac platforms and is coming to Linux. Silverlight is designed to make Web applications (and, in particular, ASP.NET applications) become desktop-like applications but deployed over the Web. It is intended to bring the Windows Presentation Foundation (WPF) application delivery format (XAML) to the Web.With Silverlight on board, your Web applications will take advantage of a shrink-wrapped version of the .NET Common Language Runtime (CLR) which means support for managed languages and a lightweight version of the .NET Framework that includes features such as isolated storage, LINQ, sockets, exceptions, and an XML reader/writer API. In addition, Silverlight supports the full WPF set of features. Before I investigate further why Silverlight is a breakthrough for Web applications, let me shed some light on which version of Silverlight I’m talking about.
Speaking in terms of specific binaries, Silverlight 1.0 was released last September, and Silverlight 2.0 is slated to ship in the summer of 2008. Version 1.1, the alpha version that is currently available (November 2007), won’t ever appear as a final version but will instead be launched as version 2.0. The version of Silverlight that marks a turning point is definitely version 2.0, and is therefore the one that I’m focusing on.
The way in which Silverlight enhances Web applications, though, doesn’t change between version 1.0 and 2.0. The underlying mechanism by means of which you incorporate Silverlight in Web applications is always the same. Silverlight is a plug-in module that hosts a WPF application and can communicate with the surrounding Web page using JavaScript, see Figure 2.
Figure 2: Communication between Silverlight and Web pages
In addition, in Silverlight 2.0 communication between WPF objects will occur through managed languages such as C#, Visual Basic .NET, and even dynamic languages such as IronPython and Managed JScript. Meanwhile, Silverlight 1.0 supports a smaller set of WPF objects and interpreted JavaScript is the only way for WPF objects to communicate between them and with the host page.
Why Silverlight 2.0 is a breakthrough
The big change is that with Silverlight 2.0 you can use the full power of WPF to build the user interface of Web pages. Will Silverlight replace ASP.NET altogether? Not necessarily. Silverlight is embedded as an external object in a Web page and you can have multiple Silverlight engines in the same page. The Silverlight object can be as large as the client area of the browser or take just a small fraction of it. When the Silverlight object is the only content of the Web page, you get a final result that looks a lot like a Flash applet. To host a Silverlight WPF application, you always need a classic Web page – be it a plain HTML page or an ASP.NET page with some dynamic content. Once Silverlight 2.0 is available, the presentation layer of WPF and Web applications can be the same, or largely the same, with a managed language and a subset of the .NET Framework to power it up. This is definitely a big change for architects and developers.Hosting Silverlight in an ASP.NET page requires some glue script code to create the engine and inject it in the host page. In an ASP.NET AJAX page, you can do as follows:
<script type="text/javascript">
function pageLoad()
{
var parent = $get("host");
createSilverlightHost(parent);
}
</script>
In the example, the element named host is the HTML placeholder element that will contain the Silverlight object. It is usually a <span> or a <div> tag.
<span id="host" />The createSilverlightHost JavaScript function is a user-defined function that basically creates and configures the Silverlight object. It usually takes the following form:
function createSilverlightHost(
parentElement)
{
Silverlight.createObject(
"xaml/customerview.xaml",
parentElement,
"SilverlightControl1",
{
width:'350',
height:'120',
background:'#111111',
version:'1.0'
},
{
onError:null,
onLoad:null
},
null);
}
The script creates a Silverlight block of the specified size that will incorporate a Silverlight object named SilverlightControl1 that hosts the WPF application represented by the given XAML file. In ASP.NET AJAX, you can incorporate the script using the ScriptManager control:
<asp:ScriptManager ID="ScriptManager1" runat="server"> <Scripts> <asp:ScriptReference Path="Silverlight.js" /> <asp:ScriptReference Path="CustomerView.aspx.js" /> </Scripts> </asp:ScriptManager>The silverlight.js file is part of the Silverlight SDK and must be installed on the Web server. The other script file is the one that contains the code for creating the Silverlight host. Here’s a very simple XAML file processed by the engine:
<Canvas xmlns="http://schemas.microsoft.com/ client/2007" xmlns:x="http://schemas.microsoft.com/ winfx/2006/xaml"> <TextBlock x:Name="Customer-Data" Foreground="lime" FontFamily="Courier New" FontSize="18"> <Run x:Name="Customer-ID"> [Customer ID] </Run> <LineBreak/> <Run x:Name="Customer-Name"> [Customer Name] </Run> <LineBreak/> <Run x:Name="Customer-Contact"> [Customer Contact] </Run> </TextBlock> </Canvas>In Silverlight 1.0, only a subset of the whole XAML syntax is supported and important pieces of functionality aren’t recognised. The list includes data binding, styles, layout, and input capabilities. As mentioned, in Silverlight 2.0 the whole spectrum of XAML tags is going to be supported.
The Silverlight engine is referenced through the object named SilverlightControl1. It represents the gateway to access all of the XAML contents. In other words, using JavaScript code you can access all elements in the XAML document that have a x:Name attribute. Here’s how to do it:
var host = $get("SilverlightControl1");
var textBlock = host.content.findName(
"Customer-Data");
textBlock.text = ...;
Whatever pieces of information the page may gather can be passed on to the Silverlight engine to use the superior capabilities of WPF for rendering. With Silverlight 2.0, the same WPF objects can connect to remote endpoints, grab data (serialised JSON) and refresh the user interface.
Summary
What users want is a better experience. For this reason, the world of the Web is moving towards AJAX. And AJAX is all about the user’s experience in the broadest sense – continuous feel, flicker-free updates, interface facilities, mash-ups, live data, and so on. The adoption of AJAX requires a significant refactoring of the application’s design. The typical AJAX pattern for user interface tasks entails that the client invokes a set of remote services, receives JSON or XML data, and then rearranges the page to show changes. For Web applications, the client is the browser and there’s currently only one tool to implement any logic in the browser – the JavaScript language.There are essentially three user interface features that each realistic application depends on: layout, data binding, and styling. The JavaScript environment has no support for any of them, except for some styling support through CSS. In the end, more powerful tools are needed on the client in order to make creating realistic user interfaces effective from both the performance and development perspective. Good and thorough libraries of widgets are essential to any developer; but even the most optimised libraries can’t do much to counter the inherent limitation of an interpreted language.
Replacing JavaScript or HTML as the delivery format is not an option; and not due to technical reasons, but for pure convenience. The future of the Web user interface seems to depend on cross-platform plug-ins. In this regard, Silverlight 2.0 is a key product with its strong and WPF-based engine and its support for managed and dynamic languages. With Silverlight 2.0, WPF content is wrapped in HTML and acted on using managed languages. Required improvements are delivered, but the outermost envelope (mostly, HTML) remains intact.
Dino Esposito is an instructor for Solid Quality Learning, and a trainer and consultant based in Rome. He is the author of various books, including Windows Shell Programming, Instant DHTML Scriptlets and Windows Script Host Programmer’s Reference. He is also a regular speaker at Bearpark’s annual DevWeek conference.
Comments