ASP.NET WebForms… Redux
March 24, 2016 Leave a comment
ASP.NET & “Classic ASP”
ASP.NET WebForms was introduced commercially by Microsoft as a part of the .NET development environment in 2001. Up until around 2010 it was the dominant web development environment in the Information Technology industry.
It was designed to replace what is now called “Classic ASP” in order to make web development easier to accomplish and learn. And that it did do very successfully. Since 2010 however, a movement spurred on by the Open Source Community has primarily turned the clock back to the days of “Classic ASP”, which was unfairly maligned by ASP.NET promoters both from Microsoft and the development community. The same has happened to ASP.NET WebForms by similar promoters from the Open Source Community and the younger professionals, many who have never learned the capabilities of ASP.NET WebForms but have instead concentrated on the newer web technologies, which in reality are not all that new.
“Classic ASP” was at one time the best web development environment available to professional developers. The emerging Java web development standards of the day, due to their inherent complexity could never compete with the development efficiency which a “Classic ASP” application could be built.
No doubt, “Classic ASP” had its disadvantages that were eventually promoted to allow it to be replaced by ASP.NET WebForms but in it’s day nothing could match it’s dominant ease-of-use construct.
It is surprising that Microsoft never made an easy to install browser plugin that could host VBScript outside of Internet Explorer. It wouldn’t have had to then open the language up for international use as it would have provided an avenue for it.
Of all the software tools that are used for web development it is probably HTML that has evolved the best to become the mature markup language that it is today. CSS was also refined quite extensively along the way and it’s refinement has been relatively good. However, CSS has been made so complex in terms of details that one could specialize in this type of development alone.
“Classic ASP” nonetheless, in it’s day, had access to all these technologies, though to a somewhat more limited degree. And though it was easy to learn comparatively speaking, people vehemently complained that it allowed for the development of “spaghetti code” applications; in other words very sloppily written applications. It did. However, that was never the fault of “Classic ASP” but that of the developers using it.
Java & the Web
With the emergence of Suns System’s Java language as a credible threat to the growing Microsoft Empire at the time as well as the complaints from people using “Classic ASP” (though, the business threat carried far more weight than that of the community complaints), Microsoft created .NET, which ran in similar fashion to that of Java, with a virtual machine. However, instead of it being a JVM (Java Virtual Machine) it was now the CLR (Common Language Runtime).
On the web, Java and it’s corresponding development software was nothing short of a “beast” to work with. It was complex and highly detailed due to the majority of the support coming from scientists, academics, and technically adept students who were either studying the computer sciences, computer engineering, or a mixture of both.
Due to it’s free availability, the Open Source Community provided Java a major push to the forefront as a dominant development environment. Many innovative products were created by this community in these years but the documentation for the use of such products was so poor that unless you were a scientist yourself, you would probably not have much success.
“Enhydra” was one of the first Java-based web application servers to be produced in this fashion. It offered a lot of capability in terms of development and implementation. However, for such a complex product the documentation for it’s use was hardly more than a few pages long. It was not long before it moved towards the background of the excitement in the Open Source Community itself.
ASP.NET WebForms was designed to be as easy-to-use and simplistic to learn as “Classic ASP” had been but on a far more powerful scale. In essence, it succeeded beyond it’s wildest expectations and flourished in the general business environments who still viewed Java as overly complex and thus costly to implement while sneering at the young Open Source Community’s attempts to define a new product paradigm.
ASP.NET WebForms came and still does come with a lot of advantages compared to the complexities of Java, which it still has to some extent. It eliminated the concept of the mixed-code module by emphasizing an HTML front-end (that supported dynamic script) with a language-based middle-tier popularly known as the “code-behind” module. This construct was promoted as a way to eliminate the sloppiness of “spaghetti code” web applications. The promotion of this construct was highly successful but not very realistic since a development paradigm can never eliminate the sloppy development styles of many developers.
ASP.NET WebForms introduced the idea of a server-control that contained direct links to processes in the middle-tier’s code-behind modules, thus eliminating the need for front-end code to do this job. This construct also was promoted as way to discipline developers to improve their development habits by providing a more structured approach to the interaction between the front-end and the middle-tier. This construct did not quite succeed as well since code-behind modules, for many, simply became the dumping grounds for all the sloppy coding that was in the front-end of “Classic ASP” applications. These developers never quite grasped the idea that all the code-behind module was supposed to process were requests and responses for the front-end, making it more or less a dispatcher module to the rest of the application.
Though ASP.NET WebForms supported front-end scripting, the support for it in the earlier versions of the .NET environment was rather limited and somewhat confusing to implement. This of course led to complaints concerning this level of support for front-end programming, which Microsoft in time has corrected quite well in Web Forms.
Front-end state management had always been a problem for developers where most often home-grown solutions were developed such as with the use of hidden HTML fields on a web page. To solve this, Microsoft introduced the idea of “view state” for the server-controls used on web pages as well as the web page itself.
The constructs of initial limited support for front-end scripting and view-state were also outgrowths of the technical orientation at the time whereby servers were to do the heavy processing of web applications and web pages were merely to present entry and viewing capabilities. This server-side emphasis made quite a lot of sense at the time, as it still does, as servers have grown more powerful over the years.
ASP.NET WebForms & the Fantasy of 21st Century Business Requirements
As the years went by and ASP.NET WebForms demonstrated itself to be a very capable environment in of itself, the development community complainers as well as a newer generation of programmers appeared to provide a convergence of thinking that began to describe ASP.NET WebForms as an old style of development that was just not up to the “new” business requirements of the 21st century. Of course, no one anywhere has ever elaborated as to what these “new” business requirements were or are except for the fact that everything was beginning to go “mobile”.
Going “mobile” is not a business requirement; it is a hardware platform of some convenience, which many businesses really do not need to continue functioning as they do. Whether one accesses corporate resources from outside a firm via a laptop, desktop, or a mobile device makes little difference as to the end result. The fostering of the current business oriented mobile craze is to get people to work more and continuously, which has nothing to do with “new” business requirements but instead the wish by corporations to make their staffs become on-demand workers.
Some companies do require “mobile” applications for their requirements but these are rather specific requirements and not the “new” requirements of the 21st century. For example, doctors and nursing staff in hospitals may find it far more convenient to access patient information on a tablet than having to return to a central workstation to do so or carry around folders and clipboards of such information. However, this does not alter the most critical aspect of this work that a doctor and\or a nurse still has to be able to read.
The current mad rush towards the “mobile” environment began with the introduction of Apple’s “smart phone”. Technology vendors eventually came to believe that they had uncovered a brand new path for more profits and saw these new devices as a way to capitalize on it. This new trend also meant that the landscape for web development would be changing or at least it was perceived to be.
One question that has to be asked about the mobile craze is if it is such a basis for 21st century business requirements, why then are the majority of applications on these devices (over 85% according to the metrics that Microsoft provided) nothing more than junk entertainment?
ASP.NET WebForms and the Disruption by MVC
Whatever it was in 2010 the ground began to shift under the venerable ASP.NET WebForms development environment with the introduction of ASP.NET MVC, which at the time many developers saw as merely a throw-back to “Classic ASP”. In point of fact it was. It was just marketed in a way to get around that very real perception. Further, MVC had been around for quite a while since it is hardly a new paradigm. The Java Community had been using it for years. The .NET Community had it as well in the guise of the “Castle Project” where it was known as “MonoRail”. It was simply never regarded by anyone as anything substantial until Microsoft began promoting it with their own version of MVC, which appeared to be an exact copy of what the “Castle Project” people had already developed.
Slowly ASP.NET WebForms began to receive the same treatment by Microsoft as “Classic ASP” had received earlier. And the complaints against ASP.NET WebForms began receiving more prominence from a number of quarters outside of Microsoft. “View State” was one of the more predominant complaints leveled against ASP.NET WebForms due to it’s additional “bloat”, which was carried back and forth between the servers. This was nothing more than a “red herring” since one could easily simply turn “view state” off if they did not require it. However, if you needed front-end state persistence one had do something to preserve it. “View State” simply took it a step further by encrypting such data making it more difficult to hack by web sniffers. One would believe this would be an added convenience to critical applications.
“Spaghetti Coding” was another of the original complaints against “Classic ASP” that was now reformulated to now attack ASP.NET WebForms, though, this too had very little to do with ASP.NET.
But ASP.NET WebForms was now also claimed to be too bloated in general for efficient web application development; an odd claim since it had done quite well up to that point.
Nonetheless, the MVC bandwagon got it’s momentum underway, which allowed for more highly complex coding with a host of new tools that allowed web developers to mix and match whatever they wanted to implement into their applications.
So, exactly how all this can eliminate the ability to create poorly defined applications has not been really answered sufficiently. It seems instead, all these software enhancements have provided more ways for doing so.
There is no doubt that ASP.NET WebForms has it’s drawbacks and some of the complaints levied against it are not without foundation. However, what development environment doesn’t have such issues? Name one that doesn’t… Yet, ASP.NET WebForms has been improved upon over the years but not to the extent that the newer technologies have simply for the reason that ASP.NET WebForms is a fairly mature environment.
Have Developers Gone Nuts!?
The question is why would anyone in their right mind want to work with a far more complex environment than that which ASP.NET WebForms provides? Any competent web development environment offers the same exact capabilities as the next; to process requests from a client and responses in return. What else is there?
Most developers using these newer technologies respond to this by elaborating on a host of irrelevant traits of these new web tools. For example, one of the most oft used responses is the “proper separation of concerns” when asked about the advantages of using the MVC paradigm. Though it refers to the structure of a web application in of itself it is a rather ambiguous construct considering that there is no such thing as a “concern” when developing code for an application. The construct is more appropriately stated as a “separation of processes”. And as such, who came up with the idea that this could not be efficiently applied to an ASP.NET WebForms application?
As previously mentioned, the “code-behind” module was designed to be a process dispatcher and not the behemoth code source that it is has been made out to be. It was designed to send requests to other parts of the application or to external services. The fact that many developers have misused this paradigm is not the fault of the software. And the fact that developers can send such a request to any module with MVC makes little difference to the end result.
Technologies Come and Go But the Good Ones Stick Around for Some Time
The choice of what tools or paradigms to use has really not become that of individual developers but what choices the vendors want their development communities to make; and most often this is for strategic, profit making reasons. The path towards MVC for Microsoft was to say the least a rather odd one since, as previously mentioned, it didn’t develop the foundations for ASP.NET MVC. The fact that it was offered from the beginning as freeware may have been a result of a concern that the people at the “Castle Project” would object if it were to be offered commercially since their tools were both freely available and open source.
In the end, the latest tool crazes will be worn thin as they evolve into their own levels of maturity. Of course, we will then begin to hear all the same style of complaints that were used against “Classic ASP”, and ASP.NET WebForms. And the pendulum of history will begin to swing back as some evidence demonstrates that it is already beginning to.
The unfortunate aspect about the entire process is that until the actual foundations of web development change, which are the protocols and the underlying hardware of the Internet, no new technology will actually be able to benefit anyone in the sense that it is some type of global panacea for such development. It simply can’t as any technology applied to the web as it is will all produce the same end result with comparative performance metrics.
ASP.NET WebForms Still Lives!
Yet, history will most likely repeat itself as Microsoft finds a way to re-release ASP.NET WebForms in some new form as the “new” way to develop web applications in a few years when many developers tire of the complexities of the current set of tools. This can already be seen with the slow intermixing of MVC with WebForms projects, which on the surface makes little or no sense. Nonetheless, ASP.NET WebForms was and still is a relatively mature web development tool that is well adapted to developing complex, database applications since that is what it was originally intended for. And none of that is going anywhere any time soon…