Why not Classic (Legacy) ASP?
Yesterday I got the following email, which I thought raised some good points that I thought were worth addressing here in my blog in addition to the reply I sent directly.
Hi Steve,
I've been following your blog (as well as Rob C. and Scott H.) as I look into dipping my toes into MVC. I just read you "How I Got Started in Software Development" and your description of the joys of lightweight ASP development really hit home. So I have a perfect question for you.
I've been in the MIS/IS/IT/ICT field for, well, as long as it's taken me to collect all those acronyms. I've been doing lightweight webapp development since the late 90s, starting first in CDML, then ColdFusion, then classic ASP.
For the past few years, I've been developing some first-rate classic ASP webapps using a heavy does of AJAX (jQuery) for the UI interactivity. The problem is, nobody takes these webapps seriously, and I'm constantly taking flack for not moving to a "real" framework. And yet as I look at many of these frameworks, they seem like overkill in all the wrong ways. ASP.NET WebForms, in particular, makes me want to run out of the building screaming.
And yet, many clearly smart and experienced people like yourself are rallying behind these frameworks. What's up? What am I missing? What's the draw? And please don't spin that old "spaghetti code" yarn; as Rob writes, "Spaghetti is as spaghetti does".
Here's my thinking: HTTP is stateless. All you need the framework to do is talk to your database and render clean HTML. That's it. All UI interactivity should be handled on the browser in JavaScript, and all design should be handled in CSS. Classic ASP (with the help of jQuery) makes all this SO EASY. And there is nothing to prevent a good developer from writing clean spaghetti-free code with proper abstraction and separation of concerns.
I don't want to pretend that I'm a VS programmer working on a stateful desktop app. I want clean and efficient HTML, CSS, and JavaScript rendered to the browser. All these frameworks seem to get in the way of that while providing minimal benefit. So in five bullet points: WHAT AM I MISSING?
Thanks for taking the time to read this, and hopefully even to answer.
Sincerely,
another confused old-school ASP guy,
Here’s my emailed response:
Hi XXX,
Read these three books when you get a chance:
1) Working Effectively with Legacy Code by Michael Feathers
2) Agile Principles, Patterns, and Practices of Software Development in C# by Robert Martin and Micah Martin
3) Clean Code by Robert Martin
Now, to properly answer your question. The big reason why I won’t wish to return to ASP is the lack of ability to reuse and properly test code. As applications grow in size and complexity these two things are critical to retaining the ability to make major changes to the site’s design. Include files are a poor substitute for OO patterns of reuse. Also ASP uses COM which is a PITA in its own right, lacking xcopy deployment and forcing you into DLL hell that I don’t wish to return to (for instance, you can’t have two versions of a given component on the same machine, requiring separate instances of the OS just to run side-by-side versions of an app). Plus, talking to databases is something that should be done via an ORM tool if at all possible, and certainly not with lots of hand-written ADO plumbing code. Perhaps the ORM landscape has changed since I last did ASP 9 years ago but and there are numerous effective options, but if not, that alone will ham-string your productivity.
If you liked the clean separation that ASP afforded, you should like MVC views which will let you do your jQuery + Services approach easily but will also let your services run in .NET where they can take advantage of ORM tools, better performance, unit testing, and inheritance/polymorphism as well as new language features like LINQ and built-in platform features like caching that ASP lacked. Give it 3 months’ time on a real project and email me back and let me know what you think.
Thanks,
Steve
I’d also recommend some of the other books listed on my Favorite Developer Books post, which I’ll need to update soon to include the two Martin books I referenced in my response. Yes, you can write well-structured web applications in ASP. Yes, writing them with jQuery and a clean separation between UI and data and business logic is a good way to avoid spaghetti code. However, as the reader has found, support for this technology stack is all but gone, and there are many benefits to be had from moving to a modern stack like .NET (which itself is getting somewhat long in tooth, nearing 10 years of age). If he’s very enamored with the dynamic nature of ASP, Ruby is likely a good choice for him to check out as an alternative. But if he likes the Microsoft toolset and stack, then I’ll stick with my recommendation that he go to ASP.NET MVC, and avoid the VB6-like ASP.NET Web Forms model.
Another benefit I neglected to mention in using .NET over ASP is the ability to debug the code. Honestly I don’t use the debugger that often (tests > debugger usually) but when I do need it it’s extremely valuable. And I can say that on the rare occasions when I’ve had to work with ASP code in the last 9 years or so, both my own and clients, it’s been universally unpleasant compared to ASP.NET MVC, which has been a joy across the board. However, I wouldn’t say that any of the ASP apps were written as well as the author of the email writes his.
How many other readers are still using ASP for new applications today? Are you trying to incorporate modern advances like ORM tools, jQuery, web services, etc. or do you build them the same way people built them 10 years ago? What are the biggest pain points you face?
Comments
Josh said on 08 Oct 2009 at 11:12 AM
I'm stuck with some Classic ASP for a website I maintain. Any new work is almost always done in Classic ASP. The porting effort though is going on for the site, but at 4,000 ASP files, its taking a while to move them all. One technique I've started using (doesn't have a fancy name I don't think), is I strip the ASP code down to output xml, injest that into the ASP.NET portion. That allows me to use the features of ASP.NET while not waiting a year to port the whole site over.
From my experience with this site, I've found these difference with Classic ASP vs ASP.Net
1. There is no Right-Click "Find all References" in Classic ASP
2. No chance to Refactor.
3. No compile errors, only when you run the app and hit that line of code do you get an error.
4. Unit test, or lack of.
5. No expression trees, those are starting to come in very hand in the .Net world.
6. Ever added a control to a page in .Net, then tried to do that in Classic ASP only to realize you've already outputted that section to the page and have to change your entire code flow?
7. Much more possibilities of what the page can do. Sure you have COM objects, but to find those can be a chore. .Net gives you managed classes and the intellesense with those. Much easier to send a TCP Packet in .Net then in Classic ASP.
8. Your classes can be carried around in .Net. In Classic ASP your stuck with just the ASP world. In .Net a class made for WinForms, can be used in WCF, WinForms for .net Compact Framework, Silverlight, etc.
One thing I wished I could do for the longest time in Classic ASP was link a class's property to a "rule", then link that property to a control on a page and have the "rule" find its way to tell the user next to that control to say "Hey Something is Wrong!". All without using a single copy and pasted string. .Net can do that, no way can Classic ASP even get close.
With all that said, the jump should be made to .Net. Just my 2 cents.
Neil said on 08 Oct 2009 at 12:58 PM
Thanks Steve for the comprehensive response and for opening up the topic. There are still a few things that I'm getting caught on.
1) I don't see how OO models make sense in a stateless world. When a web page finishes loading, all custom classes and methods - both the structure and the data in any instances - are gone. Poof. That's the way the web works, and you can try to simulate around this with things like viewstate but it's what Rob & Co. call "the Tiny Lie". Any important data that a user sends or that is generated needs to be stored in a database, NOT in a memory-resident object. The database is where my hierarchy and data structure exist; Views and Stored Procedures replace custom methods. All I need my code to do, if I've done my work correctly, is some relatively simple processing logic. I have done some sites with some VERY complicated processing logic but that's the exception, not the norm.
2) I come from web developer roots (HTML, CSS, JS) and not a Win32 developer background. I've never compiled a DLL in my life, so I'm really not sure what you mean my DLL-hell in a webapp context. I HAVE written a lot of custom, reusable VBScript functions that get dropped into my custom function library and loaded on all pages via a server-side include. It works beautifully, without all of the headache that seems to come with compiling .NET user controls.
3) ORM tools serve as an abstraction layer between your database and your memory-resident objects and classes. But since the web is stateless (#1 above), why are you spending the time and resources to build all those custom objects in the first place if they won't survive the page load? More importantly, any good webapp developer needs to be able to live and breathe SQL. Develop an intimate relationship with your database. Using the ADO objects to query and update SQL data sources is really quite simple, and only requires a couple lines of very easy-to-read code.
4) Classic ASP does, contrary to common misperception, cache pages on first access. When you compile .NET, you're compiling for MSIL - much like compiling for JAVA. Both are platform-independent emulators. That adds a lot of overhead. So at best you're "compiling to stand still". Classic ASP is very, very fast.
5) You can do a lot by calling in Windows COM components using META tags in ASP. But you're right - it is a royal PITA and can't compare to the ease of use of the baked-in .NET libraries. And the documentation is horrible for those older libraries.
6) Unit testing is something that I really need to learn, got it.
Maybe I just haven't developed anything complex enough, or that required custom Win32 coding. But my view is that webapps are best when lightweight, fast, and designed for any client platform. They read data, display it in a browser, allow the user to manipulate that data, and then post it back to the database. And I can do all that with Classic ASP.
I am in the process of learning both ASP.NET MVC and Ruby on Rails (variety == good), so I'll let you know if I've changed my tune in six months. :-)
Best,
Neil
ssmith said on 08 Oct 2009 at 2:21 PM
Hi Neil,
It's definitely a good topic, and I'm sure others will add their opinions here as well. Let me refer to the numbered points in your comment:
1) OO works for short-lived objects just as well as long-lived ones. The usefulness of objects isn't that they persist for long periods of time, it's that they provide abstractions that make working with an application easier. If you decided tomorrow that you needed to change how you fetch data everywhere in your ASP application, how many places would you need to make that change? With proper abstraction, it should be 1.
2) No argument, but this is a very procedural approach. It works, and works well when done by someone experienced. Using ASP.NET controls, especially 3rd party controls, can let you get huge amounts of functionality without having to write it yourself. It's probably fair to say that you're not finding many 3rd party (open source or otherwise) libraries full of useful stuff today for ASP. Reusing compiled components tends to be easier than utilities that were written with one case in mind and then start getting scope creep and extra flag parameters to make them work for other cases. OO design helps here again as well in many cases.
3) Databases should be abstractions. You shouldn't be writing your application so that it knows intricate details about your database. Why? Because it makes it hard to change either one. If you use an ORM with any kind of mapping functionality (which pretty much all of them have), you can rename tables and reorganize your SQL schema without having to change any of your UI or business code. You can move from SQL to Oracle or Azure Table Storage or store everything in files and your abstracted persistence layer is the only thing you need to swap out. SQL is an implementation detail of your persistence - it shouldn't be something your UI layer knows about. Also, if you're writing stored procedures to do all of your CRUD (create/read/update/delete) work on your tables, you're wasting time (and thus money).
4) That's not the caching I'm talking about. I'm talking about caching results of page execution and/or the results of database queries. That's where you can get 10000% increases in performance in ASP.NET apps (that's 100x, and no I'm not exaggerating). Take a page that makes 4 calls to a database on every request, each taking 25ms, and add output caching so the web server can return the cached result in 1ms. This requires one line of code in ASP.NET. It's not easy to achieve in ASP.
5) Agreed, the .NET Framework is a hugely useful tool and is ginormous. Its value to developers should not be underestimated.
6) Yes. Today.
Certainly many web applications are concerned simply with fetching some data from persistence in response to some variables in the request (querystring, POST, cookies, etc.). Even in these simple cases, ASP.NET MVC provides a far more maintainable way of accomplishing this task than classic ASP does. And don't forget the flexibility you have of being able to add functionality to every page via HttpModules, to reorganize the application via Routing, to unit test everything so you know it works, and much much more.
Danijel Stulic said on 08 Oct 2009 at 4:35 PM
Steve, you are my hero of the day for explaining the obvious with the highest possible respect! Congrats! :)
I worked with ASP in 1999 (InterDev) with COM components. Later, I've struggled with ASP in Visual Studio 2003 - used VS 2003 as a debugger and intellisense tool for some old ASP projects.
It was a royal pain always. I must say that for any middle-size project ASP is just a mess and not useful at all. There is some possibility to code some sort of very weak "VB6-like" OO in ASP 3.0 (VB Script 5.1 if I remember correctly). ASP shouldn't be even compared to PHP, and yes, there are performance problems because it is a scripting language.
ASP.NET WinForms and ASP.NET MVC are just options. You don't have to use it. In my opinion there were no excuses for using ASP in any new project after 2002 - even if it is a one web page site.
I am sorry Neil that you've been coding in ASP all these years when there were so many better alternatives. Your statement about "reusable functions" isn't even funny... blah... blah...
This blog-post must be just a provocation and I've just hooked on?
Li Chen said on 09 Oct 2009 at 11:13 AM
Hi Steve, I am one of the authors for your http://aspalliance.com. I am actually working on a VBScript.net and ASP Classic Compiler that will bridge the ASP Classic and the .net world. You can find the information at http://www.codeplex.com/aspclassiccompiler.
Fabio Zendhi Nagao (nagaozen) said on 11 Oct 2009 at 2:58 AM
Hi Steve,
I'm currently doing a lot (really lot) of Classic Development today, and I've to say to you that it still a very interesting platform to work with... I've nothing against new languages or frameworks, but I see no reason to tell someone to leave Classic ASP. In fact I started a serie trying to explain why Classic ASP still rocks. You can find it here: zend.lojcomm.com.br/.../asp-a-misinterp
Hope it helps you to understand a little the Classic ASP platform from a perspective of a real ASPer.
Best regards,
nagaozen
Patrick said on 11 Oct 2009 at 3:03 PM
@ssmith
Would you please explain why we should not use stored procedures?
ssmith said on 12 Oct 2009 at 9:32 AM
@Patrick,
There's nothing *wrong* with using stored procedures, especially if they're already written or generated by a tool. What's wasteful, today, is hand-writing CRUD code, whether it's in stored procedures or not. There are numerous object-relational mappers (ORMs) available that do this work reliably and effectively, many of which are free. Thus, doing this by hand is a waste of time, no different than writing your code directly in IL when there are higher level languages that, when compiled, generate the IL for you.
Patrick said on 12 Oct 2009 at 11:44 PM
Thank you for your answer. Looking back at my question I realize that it may appear to be a bit argumentative, but that was not my intention.
I am always trying to learn more and be a better developer. Your post gave me the impression that you may have been stating that using stored procedures is a waste of time, and if this was true, I wanted to understand the reasoning for that opinion.
ssmith said on 13 Oct 2009 at 9:34 AM
@Patrick,
No worries, it was a good question that I'm sure others were thinking but not voicing, so thanks for commenting!
Torben Poder said on 26 Oct 2009 at 7:40 AM
Well, "legacy" is not necessaily the same as "bad"
ASP is a framework, just like .NET is. It is not a language, even though most people seems to infer that when speaking of ASP people are speaking of VBScript. There's a score of different languages that will plug in to ASP, most noteworthy, (IMO), is javascript, which will work out of the box, and has had dynamic typing, OO, and lambda expressions for years.
You can build a layered architecture in ASP. Countless CMS systems have been done like that, with a dispatcher and a dynamically generated view. There's no saying that you have to slab your business logic into your pages, you can easily abstract it out into classes that can, if needed, be re-factored without changing any pages. MVC is a state of mind, not something tied to a particular development tool or platform.
Similarly, unit testing, and TDD as a whole, is a concept. There's nothing hindering writing unit tests for ASP, just make a page that calls your logic, and compares expected results with actual results. There's just no nice tool to assist you with it, but TDD is certainly not tied to the existance of [TestMethod] attributes. It's just code, after all.
Interestingly, ASP.NET MVC actually brings back the intermingling of code and markup, with the justification that having small blocks of code to control only the view is OK. Well, you can do the exact same thing in ASP, except you use #include.. instead of 'inherits' to import model data.
With a huge framework, like .NET, you get a whole lot of functionality for free, but it also incurs that you have to "sink into it". That means you must either change your solution to fit the framework, or go through the, often non-trivial, process of bending the framework to your will. Granted that ASP.NET MVC makes this a lot easier. With a small framework, you have to implement so much more, but you're not bound by constraints like the calendar control not showing weekdays. In my almost ten years of ASP.NET, I have lost count of the times I've been thinking "it's almost what I want, but not exactly what I want".
There's a lot of components for ASP out there, you often have little control over which are available on a host, and that certainly is a big setback. On the other hand, besides from server controls, you pretty much has access to all of .NET from ASP, if running on a Windows server with both installed. Off course, instantiating the .NET runtime via COM gives some overhead.
It's been years since my last from-scratch ASP project, so I can't really compare performance. However, the ASP framework is small, and it was decent fast ten years ago, I think it's safe to assume that on todays hardware, it'll be really, really fast, even without caching.
To sum it up; layered architecture, TDD, ORM, OOP.. it's ways to design your application, concepts, not a particular platform or technology. You can do it in ASP as well as in .NET or Java for that matter. The difference is in the tools. I tend to think that it's not .NET that is so fantastic in itself, it's Visual Studio that makes it easy to create working sites with drag/drop. Try downloading TextPad or N++ and do a trivial site in ASP.NET (MVC), it will certainly not seem easy and user-friendly. But why would anyone do that, when the tools exist? Well, what are tools anyway? If you, like the OP, has a lot of scripts that you can copy/paste, then you have tools as well, in a sense.
The standardization, wide-spread usage and great IDE-tools of .NET can't be underestimated, and this is not a voice for ASP being superior to ASP.NET, only to support the OP in the notion that ASP is certainly not a bad platform, nor is it in any way flawed, even though it could use a facelift, like a cache for example, (I wish). If a person is good with ASP, and doesn't have the need to go find a new job, then why switch at all? I don't see it.
The DMXReady Team said on 27 Oct 2009 at 4:06 PM
We're more in line with the letter writer's thoughts on this one, especially when it comes to small business owner sites.
ASP works, and it offers a lot of pros for DIY and web designers who aren't programmers. With our apps, for example, we include a built-in database so that you don't have to fiddle with setting up database through the server. Not difficult for programmers perhaps, but one less step (and headache) for the average DIY website owner to worry about.
That's not to say that you are wrong, Steve. In fact you raise some good points. But I think it needs to be said that ASP still holds many advantages for key segments of the market (i.e. SOHO, SME website owners) that need only simple applications, and not enterprise-sized solutions. As programmers, looking for the next "best language of all time" sometimes gets in the way of what is really important: providing our clients/customers with viable solutions that best meet <i>their</i> needs...
FYI, we've riffed on the ideas here in one of our own blog posts, which you can find at: blog.dmxready.com/.../index.asp
Sincerely,
The DMXReady Team
Torben Poder said on 28 Oct 2009 at 10:58 AM
A couple of extra thoughts..
In my post above, I meant to say ".. calendar control not showing weeknumbers.."
Good programming practices, testing, patterns etc. really aren't reasons to choose one language/framework over another. Pretty much all frameworks will let you follow best practices, although some tools makes it easier than others.
So what are the reasons for not doing ASP? In my point of view;
1. It's not dead, but it's stagnant. Even Sun discontinued development of their version, and while it probably will exist on servers for a while yet, sooner or later it will go away. When it does, so does the market-value of your skillset.
2. .NET is where it's at. No, I don't buy all the marketing hype, but Microsoft killed their other frameworks with powerfull will when .NET shipped. Had they done ASP 4.0 and VB 7, (not .NET), uptake of the .NET framework would surely have staggered. Like it or not, Microsoft wants us to develop to a unified framework, that covers all of their technologies, and that is where the future is.
3. .NET is built on a fundamentally different philosophy than many of us was taught in school; it's all about shipping software. What that means to you and I, is that no matter how good you are with your other language, a mediocre .NET programmer will most likely outperform you anyway. It might not be pretty, it might cut a lot of "pure OOP"-corners, but it'll run and ship to the customer.
Productivity, that is ultimately what it all comes down to. I don't remember which of the .NET team guys coind the "pit of succes" phrase, but basically it's to say that doing the most obvious thing in .NET will make it work right. This is in fact the very reason you might not like it; As a programmer, you like to solve problems, overcome, be clever and make nice hacks. All those things are void in .NET, it's simple to do right, and thus gives us no feeling of challenge. It's not a problem-solving platform, it's a combination-platform, which cater to people that are good at glueing pre-built pieces together, not people good at solving puzzles.
Why not to switch, in my point of view;
1. If you have a portfolio of ASP products, and you're confident they will last you throughout your career, then by all means stick with it. The best programming language/platform is, and has always been, the one you can do the most with in the shortest time.
2. The one factor that might be the most important after all; the feel. Completely subjective, and with complete disregard to market-powers and utility, you have to enjoy what you do!
The customers best interest is software that works and ships with as little cost as possible. There's no things you can do in ASP that you can't also do in ASP.NET, or the other way around with som COM-aid, so it's basically about which platform makes you do it the fastest.
X said on 29 Oct 2009 at 1:26 AM
Hi All,
I had a question that was somewhat off topic but first I’d like to chime in on ASP.
I’ve been maintaining classic ASP applications for many years now, mid-size. I along with Neil come from web developer roots and have never compiled a dll for use with ASP. The only dll I ever remember using was the PayPal com object which is no longer supported. “DLL hell” can now be avoided now by consuming web services.
Debugging – hmm…. It really depends on the application and the developer(s) that created it. I’ve debugged tens of ASP applications and it all depends on how the developer coded. If the developer was able to separate their code into the correct layers (data access layer and presentation layer, at least) then there was never a problem debugging their code. However, then you get those applications where (issshh….) you have dig through 4-6 include files to find just the function being called then its pretty time consuming.
I’ll still be creating ASP applications until Microsoft stops supporting it. I find very simple .net applications sluggish which I really hate.
For my slightly off topic question, we’re porting some classic ASP websites to .Net. :) We use a lot of stored procedures for performance tuning and to do some complex logic (multiple tables from multiple databases, temp tables, etc.). I want to start off on the right foot and do it correctly the first time. Could someone recommend a good book/website to get caught up on the most secure and efficient way to call these stored procedures, ado.net, LINQ to SQL, DAAB, etc? I know there is no clear choice but I will be glad to hear some opinions.
Thank You
Dave said on 17 Nov 2009 at 10:21 PM
I am still using classic ASP and, to answer your question, the biggest pain I am facing is the pain of guilt - from wondering if it is unethical to build in ASP instead of recommending that a customer go find someone more .Net savvy. I got off to an early start with .NET before it was out of Beta. By the time .NET was seeing any significant implementation, I was employed doing VB6/ASP and MSSQL programming stuff. Now I am contracting for projects on my own. I don't want to get up to speed with .net at the expense of some clients project, and I can't really afford to send jobs away while I catch up. I'm not even sure if I can afford the MS studio/platforms needed to learn and produce professional grade .Net apps. So I sit here at the moment, about to begin development on a new medium sized web app. using classic. This project does not require enterprise scale and I know that the required functionality can be achieved without .net; never-the-less, I am very worried, fearing that I might be doing a disservice to my client.
Thanks for this great topic,
Dave
Chelo said on 18 Nov 2009 at 9:45 AM
Hi Steve,
I'm in the same situation as Dave, I have been developing in classic ASP sincerely six years I have to jump once and for all. Net, but their learning time and take me back to being a beginner.
What would be the recommendation for this case?
Thanks
Brian Smith said on 25 Nov 2009 at 12:04 AM
Wow, a lot of very interesting and enlightening comments on this subject. One that I and my co-workers deal with every day.
In my shop, we started off in '99 with Classic ASP. We were just "getting it done" and not paying too much attention to what we needed to: security, non-spagetti code, etc.
Then .NET came along and we jumped in with both feet. Now we have a hybrid Intranet, 60% classic ASP / 40% .NET 1.1. When we have significant changes to ASP apps, we have to weight the cost of bringing that ASP app to .NET vs. implementing the changes to the apps and keeping them in Classic ASP.
It ususally comes down (at least in our case) to the business saying "uh, this was supposed to be done yesterday, we don't have time to wait" and we end up just implementing the change in the classic ASP app.
Now, on new web apps, we go .NET all the way. And guess what? We've got some 2.0 and a couple 3.5 apps now. Can you say "Big pile of Mud?"
I think that if you work in classic ASP, and you have access to hardware and the "stack" to put your web app on, stick with it. But as was mentioned earlier, support for that platform is going away. So it really makes sense from a business perspective to keep current if at all possible.
In my shop we have control of all our hardware so we can keep running on that platform indefinitely.
But, for the developers at our shop, it's just something we will have to live with untill the business decides to free us up to bring everything up to the current .NET version.
I will tell you we hired a guy skilled in OO who hadn't done any Classic ASP and put him on a project to make some major changes to an existing ASP app. He tried to do it the OO way, psuedo-classes, arrays of objects, etc... I was doing the same type of work on a different classic ASP app. He kept butting his head against a wall and ended up doing it the "just get it done" way. He was not happy! Now, some of that probably stems from just throwing him into the fire and his ignorance of how VBScript treats array variables and such but still. He kept asking me why we didn't just conver it. "We don't have time."
So, bottom line, my opinion: Learn .NET, Ruby, whatever new stuff is out there so your skills transfer well. I've taken the initiative to get involved more in architecting .NET apps and really learing more on OOA/OOD/patterns, etc. and now I'm moving to a shop that has NO classic ASP.
I'm getting outside my comfort zone but I'll be a better programmer all around for it.
Thanks
--Brian Smith
anuj kumar said on 01 Dec 2009 at 6:25 AM
What's easy step to learn ASP?
anuj kumar said on 01 Dec 2009 at 6:27 AM
Actually i m looking my carrier in Database in I.T.,so can you explain what i have to do & what will be better for me.
Linda said on 13 Jan 2010 at 6:55 PM
Has anyone tried Li Chang's Classic ASP compiler?
www.codeplex.com/.../aspclassiccompi
My site is old Classic ASP. I would be very interested to see of this works. The thought redoing my site is a huge undertaking for me to map out. All I want to do is add a few features and keep what I have.
This compiler seems it might be right for me. Otherwise, I don't see why I would stay with a Microsoft platform if I must totally rewrite my
site - a niche job posting website. It just seems to be too expensive for me to stay with a Microsoft platform.
I mean no disrespect to Microsoft developers.
I welcome your perspective.
Asrar said on 15 Jan 2010 at 4:11 PM
I've been using classic ASP for 10 years. I've tried twice to move to ASP.NET but the learning curve is too high and I don't have that much time. I like classic ASP because I can get things done quickly, and my clients are happy.
I wrote on this subject previously: asrar.ca/.../asp-doesnt-suck
Halotron said on 21 Jan 2010 at 10:39 AM
Really the biggest problems with Classic ASP come from the webserver and Visual Studio.
webserver problems:
- DLL Hell. We have one website that uses six different COM components. Major PITA.
- No session state sharing. There are some solutions out there, but none very good.
Visual Studio problems:
- Intellisense is weak. They actually removed it at one point stating "we didn't think anybody was using Classic ASP anymore"
- No debugging. I was able to get Classic ASP debugging working in the past, but it's just not worth the effort.
Really Classic ASP as a language is fine. It's very similar to PHP and Perl. (Yes, I've written plenty of both) You can actually create OO classes in Classic ASP, and if you abstract your data to stored procedures you may have to write extra CRUD but you can live without an ORM. VBScript isn't exactly a cutting edge language, but it gets the job done.
As for unit testing, it depends on how you develop. I have lots of include pages across applications, but they are basically just function libraries or classes so you can functionally test each one separately.
For me, reasons to upgrade would include the problems above, along with just the typical developers drive to always try and use the latest cool new things. Microsoft and Friends (TM) come out with tons of new cool tools all the time and if you're stuck on Classic ASP you can't come to the party.
Reasons not to upgrade would be cost versus benefit. If you have a website that is running fine in all Classic ASP, don't upgrade just to upgrade. If you are making massive changes to the site, it's probably time to make the change, but there is a significant amount of time involved in upgrading an entire site.
For all new development I've moved on to asp.net webforms and some mvc, but where I work we have tens of thousands (not kidding) of Classic ASP pages. So we're talking years before it will all get rewritten, if ever.
Leave a Comment
Please join the discussion and share your thoughts.