Programming Microsoft ASP.NET 4 - Dino Esposito [10]
It was tried again in the early 2000s, and this time it really stuck.
Like physics in the early twentieth century, ASP.NET Web Forms was a stable and mature platform when AJAX experiments started. In the beginning, it was simply a matter of spicing up some pages with a piece of JavaScript code and downloading raw data from an HTTP endpoint. However, it is one thing to download a number or a string and refresh the small portion of the user interface that contains it, but it’s quite another to download a collection of data objects to repopulate a grid. And what if you intend to post the content of a form and then update a large section of the current view?
The underlying machinery and tools remain the same, but the way in which they are organized, exposed to developers, and consumed requires a lot of thinking and perhaps a brand new application model.
In particular, the advent of AJAX raised the need for developers to embed more JavaScript code in HTML pages. The JavaScript code, however, has to deal with HTML DOM elements, each of which is commonly identified with a unique ID. In an ASP.NET Web Forms application, it’s the set of server controls defined in a page that ultimately determines the structure of the HTML DOM and the ID of the constituent elements.
To support AJAX deeply and effectively, Web Forms developers have to dig out some of the internal details of the server control black boxes. In doing so, developers attack one of the pillars of the Web Forms model. The more AJAX you want, the more control you need over HTML; the more control over HTML you want, the more you are mining the foundation of ASP.NET Web Forms.
But there’s more than just this.
The Data-for-Data Model
For years, the Web worked around a Pages-for-Forms model. It was just fine in the beginning of the Web age when pages contained little more than formatted text, hyperlinks, and maybe some images. The success of the Web has prompted users to ask for increasingly more powerful features, and it has led developers and designers to create more sophisticated services and graphics. As a result, today’s pages are heavy and cumbersome. (See Figure 1-5.)
Figure 1-5. A page sends out the content of an HTML form and receives an HTML page.
Given the current architecture of Web applications, each user action requires a complete redraw of the page. Subsequently, heavier pages render out slowly and produce a good deal of flickering. Projected to the whole set of pages in a large, portal-like application, this mechanism is perfect for causing great frustration to the poor end user.
AJAX just broke this model up. A request might or might not post a form and request an entire page. More often, an HTTP request might just pass raw data and request raw data—an overall simplification of the interaction model. (See Figure 1-6.)
Figure 1-6. HTML elements fire out-of-band calls passing raw data and getting raw data, not necessarily HTML pages.
ASP.NET Web Forms was created to receive forms and return pages. It is difficult to turn it into a model that fully supports the Data-for-Data model of AJAX. Web Forms hides a lot of its machinery and offers a higher level view of the Web operation than many demand today.
This fact can’t be ignored when making architectural decisions about which platform to use for a given Web project.
It’s not relevant whether Web Forms was designed in the wrong or right way. It was right for the time it was designed. The advent of AJAX created different business conditions; in these conditions, Web Forms is not necessarily the ideal framework.
But is there any ideal ASP.NET framework out there?
What Web Do We Want for Developers?
A decade ago, we just wanted applications deployed through the Web. And Web