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 its day, nothing could match its dominant ease-of-use construct.
“Classic ASP” was in effect a mirror image of the current bandwagon of technologies without all the bells and whistles that have been added to them. It allowed one to create both mixed-code modules where HTML, markup script, and dynamic scripts could be implemented. For those that wanted code-only modules, this option was as much an option as the mixed-code one. In this type of code-base, HTML and markup script were simply made as constants to Request.Response statements while still being able to access and process dynamic script either implemented with VBScript or JavaScript.
VBScript, JavaScript, HTML, & CSS
For those that have never experienced using VBScript, it was for all intents and purposes a far superior implementation of such a web tool. Had it been opened up to the ECMA standard and refined, JavaScript never would have been able to compete with it. Unfortunately, Microsoft was quite closed minded back then.
VBScript had object oriented constructs when JavaScript was still being maligned by the development community for being too arcane and difficult to use. It also had much better documentation with the old Wrox book, “VBScript”, being the only one any web developer would require to learn and use this language.
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.
The Java Community and its own powerful language, Java, also contributed a lot of influence to the rise of JavaScript as the predominant web scripting language, though indirectly. And that it was also supported in browsers other than Internet Explorer gave it the leg up that VBScript never received.
Many developers actually believed that JavaScript was a subset of Java, which it wasn’t, and that gave it a lot of credibility. JavaScript however, was originally developed by Brendan Eich in 10 days while working for Netscape Corporation and it had nothing to do with Sun Systems Java language. JavaScript was actually an outgrowth of the C language while Java was developed from the ground up. This is why JavaScript has had historically a rather poor reputation as C had come under the pressures of the rising C++ language and community. C and C++ have always been two very difficult languages to gain high expertise and fluency with. Just ask any highly competent C/C++ developer how many poorly designed C/C++ applications he or she has seen in their careers. Unfortunately, JavaScript did not adopt the consistency of its predecessor.
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 its 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 its 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 a 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 its 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 its 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 its 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
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 its 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 a 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 its 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 its 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.
Server-side processing was denigrated as a thing of the past, while the front-end became the most important aspect of the web development process with subsequent new JavaScript frameworks being developed, all of which had to be loaded to the front-end to be able to process them. CSS was expanded with a plethora of new capabilities making it far more complex to learn and implement efficiently. And HTML was improved to host more flexible features that actually made it a more mature language.
All of this however, in the end, did not eliminate the supposed “bloat” of ASP.NET but merely changed who would implement it. And the emerging MVC standard did not eliminate the ability to develop sloppily designed applications but actually increased such a capacity with the myriad of ways that the front-end could now make a call to the middle-tier beyond the “single page to single code-behind module” orientation of ASP.NET WebForms. This is not to mention the additional coding complexities now required or willingly added in the middle-tier, the additional complexities of working with JavaScript frameworks let alone JavaScript itself, and the move to use CSS over markup defined attributes in such ways that it could completely change the appearance of how web pages interact with the devices they are displayed on as if WebForms could not do this (which it can since it is a function of markup and CSS and not the code-behind). In a sense, the maturing of HTML and CSS for handling multiple types of devices was a significant improvement to these software tools, though more complexity was added to them as a result. Not surprising, it also increased “bloat” and decreased the efficiency in which such displays were processed. “Responsive Design” in fact, a technique to apply all these new enhancements in CSS and HTML to a wide spectrum of device types has been seen as an encouraging achievement towards a generic presentation process while also being noted for it’s high rate of general inefficiency.
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 its 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.
The only logical choice for current web development then is which technology paradigm and toolset will produce the better end result. However, it is not the technology decisions that will produce a better result but how the tools are used. One can still build a terrific ASP.NET WebForms site as much as one can build a horrible ASP.NET MVC site or one using merely JavaScript, HTML, and CSS. Unfortunately, most developers go with what looks good on a resume and what everyone else is rushing to use, as do hiring managers forcing new choices to be made every few years as technologies come and go. Yet, not one of these technologies will produce results on their own that are any better than using any of the other technologies on offer today as they effectively all do the same thing.
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.
If you look quite closely at the field of these latest technologies, there are already indications that the pendulum may be getting ready to make another arc. Already, we are beginning to see more open complaints about JavaScript as a foundation language, server-like controls being developed by some for MVC applications, Agile failures and scalability issues being discussed increasingly, the confusion over DevOps, and other similar issues percolating to the forefront.
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…
