FAQ: Classic ASP vs. ASP.NET
Web programmer-analyst since 2000; ASP, PHP, ASP.NET (vb & c#). Simple, effective and modular solutions with focus on expandability. Order.
Published:
Browse All Articles > FAQ: Classic ASP vs. ASP.NET
I was asked about the differences between classic ASP and ASP.NET, so let me put them down here, for reference:
Let's make the introductions...
Classic ASP was launched by Microsoft in 1998 and dynamically generate web pages upon user interaction and server-side processing; this model is complementary to serving static web pages like well-known ".htm" files which mainly have fixed content, and opens a whole new world of possibilities in the web area. The ASP page have a mixed content of HTML and server-side VBScript (all in a single file).
Microsoft included ASP technology in every Windows version, from Windows 2000 to the latest. However, on newer versions of server operating systems, classic ASP is blocked by default (but this can be changed by server administrator).
By default, ASP pages have ".asp" extension and are using VBScript (which is a restricted and "light" version of Visual Basic programming language).
ASP.NET is the successor of classic ASP and implements a completely new model. Released in January 2002, this technology is actively supported by Microsoft in every Windows version starting with Windows XP and server-editions.
The new ASP.NET web pages have an ".aspx" extension. The dynamic program code is stored separately (using the code-behind model) in another file with an extension of .vb (Visual Basic) or .cs (C sharp), depending of the programming language used.
Comparing OLD and NEW
Classic ASP is similar to PHP in how it works and how it is written, where ASP.NET is more similar to the J2EE Servlet / Java Server Pages architecture.
Classic ASP is much more simpler than ASP.NET and very easy to learn, compared to ASP.NET (I personally learned classic ASP in just 5 days from a very good and short tutorial).
You can edit classic ASP even with Notepad.
ASP.Net is a a compiled application (resulting in DLL-type file), while Classic ASP is a script-based language. You don't have to compile anything in classic ASP, just upload the file to the server.
ASP.Net is also an event-based model implemented via a set of so-called server controls. In classic ASP, there are no server controls, you have to write everything manually (which I love, because it leaves me the freedom I need).
ASP.NET uses the "code behind" technique in order to keep business logic away from the presentation, while classic ASP does not force you to to that (but you can do it, with your own technique - e.g. you must write additional code - if you want).
In classic ASP, the client-server model is obvious: if you need to obtain an action on the client-side, you have to write JavaScript, CSS and HTML; if you want to process information on the server, you have to write VBScript (ASP). In ASP.NET these things are not so clearly separated, which may result in poor understanding and bad code.
The most important thing about ASP.NET: it is NOT fully ASP compatible, even if you might think otherwise.
If you are an ASP programmer and you love it, you may find very difficult to learn ASP.NET...
Real-life opinion
Tim Walton (Evesham Solutions) says: "The move to a .NET development environment was expensive and a far bigger change than many expected. The uptake was, and still is, much slower than Microsoft ever expected."
Also, he says: "ASP.NET for small to medium-sized websites is a huge overhead in many ways, and so for the foreseeable future I will be sticking with regular ASP for anything but the most complex of websites."
This is one good reason he mention: "Regular ASP has the most lightweight development environment I have ever used - Notepad. Yep, that's all you need! Installation time? - It's already installed. Start up time? - It's running in an instant. Configuration? - Not needed. Availability? - Any PC ever".
Friend or foe?
ASP.NET has a tendency to auto-generate code. Is this a powerful and useful feature? You decide...
Just figures
Google says there are just 0.36 billion search results of ASP.NET while ASP gets 3.29 billion results.
The future
The proof that classic ASP is here to stay: there are many implementations of frameworks for classic ASP (Simplicity, CLASP) and even AJAX for classic ASP (called AJAXED).
A quick glance at the Google Insights for Search for keywords like 'ASP.NET' shows a markedly declining trend since 2004. I believe this is conclusive...
Final word
My opinion: despite appearances, classic ASP seems to be much more HUMAN than his younger brother (ASP.NET).
PS: If you find this article helpful, vote YES for it.
Web programmer-analyst since 2000; ASP, PHP, ASP.NET (vb & c#). Simple, effective and modular solutions with focus on expandability. Order.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (12)
Commented:
Let me say that I've been using Classic ASP extensively for the past 8 years or so (and I still do) and I do like the simplicity it brings, but I totally loathe the lack of modern development structures (inheritance? good luck, JSON objects? sure thing, server side includes can't have arguments), of course some things can be done entirely from scratch but the classes are a joke.
If Classic ASP had evolved a bit like php, it would probably reign, despite the fact that .NET is completely object oriented, and designed for MVC.
So... no, you can't really compare them, sure they share the name "ASP" and they were both developed by Microsoft but they do totally different things. Classic ASP was pretty much abandoned when Microsoft decided to build .NET, but for small projects it's still pretty good. If you need to build a robust system however, Classic ASP is not the one for the job.
-V
Commented:
asp.net code is much more complicated then classic asp. It requires much more lines of code to get things done, and after a few years of doing asp.net, I haven't figured out how to do some things that are really simple in classic asp.
* Starting from a connectionstring, find out which DBMS this connects to.
In Classic ASP it's easy:
-
sDSN = "someconnectionstring"
Set oConn = Server.CreateObject("ADODB
oConn.Open sDSN
sDBMSName = oConn.Properties("DBMS Name")
-
Of course it must be possible in Asp.Net too, but I haven't tried very hard, and the times I tried I got quickly lost in low level classes.
* What about doing a simple GET or POST to another url?
Classic ASP gives the responseText in 6 lines of code while using a single object.
ASP.Net requires at least 10 lines of code, and needs 5 different objects.
* Oh, and can somebody help me with a fast method to incorporate the XML from a "FOR XML" query into an existing XMLDocument. I can do it, but it involves transferring the query result along a couple of instances of different classes, on the way the result has to be validated (which should not be necessary because it is the result from a FOR XML query). The XML-objects are hopeless in ASP.Net anyway. There are so many of them and there is usually no easy way to get the xml from one object to another.
I know, classic asp has its errors and limitations. I learned to work around them. For most websites, asp.net is a huge overkill. Most asp.net "programmers" turn to webforms, which is a point-and-click interface, producing horrible html-source code and resulting in posting back the complete HTML of the page (encrypted) back to the server on every click. And once things are a little bit out of the ordinary, very complicated solutions need to be found. Helpsites are for that reason very much focussed on providing self-programmed controls which each solve a specific issue. Such as support for the <optgroup> tag, which curiously is missing in asp.net.
Commented:
I have been using Classic ASP since Alta Vista was the search engine of choice... (Yes I feel old!)
As with most things in life, one size does not fit all. And as mentioned above, this is a little "apples vs. oranges".
The following also comes with an health warning: To compare code properly, you must compare good-code with good-code.
There is a certain simplicity to Classic ASP (in VBScript in my case). It is very easy to understand, and follow, probably because of it's "basic" roots. This, along with code-in-code (which I rarely use now) makes it very easy to read. It also cuts a very clear line between server- and client-side.
Personally I have developed code over the years which I still use today. There are functions in my collection which just plain work. Everyday. Why on earth would I want to give these up, just so I can use a language which is a few years newer..?
There are very few things I have not been able to achieve in Classic ASP. I did need to turn to PHP for re-sizing images, but that is about all I can think of...
Successes include: Uploadify in ASP, Full EMail control panel front-end for Mailenable, Endless MySQL Connections, JavaScript Menus written on-the-fly, Hardcore AJAX, yarda yarda yarda...
I think there is a place for ASP.NET in this world, but how often do you take the code from your website, and port it to an application..? If one in a hundred actually do this without major modifications, I would be amazed...
GH
Commented:
"Linux is not a securable platform for public consumption" -NSA
If your presentation requires controls that need to be valid against data changing outside the scope of the client. you have to use some form of server-side controls. []NET does this very well.
Scripting Language sites will out-scale managed code every time, because resources are only consumed as needed.
I have had 1500+ concurrent users against a 4 core server on classic asp including the SQL Server instance and never reached 30% CPU.
Lamp solutions just don't have the toolsets for monitoring and performance metrics to bother with comparing them.
Commented:
View More