>>I compare using WC vs ASP to FoxPro vx dBaseiii.
>
>Maybe your just sucking up to Rick, but I wouldn't say that. IMO, there's not a whole lot wrong with ASP, except that its harder to keep compiling the VFP COM objects, but there's ways around that, just like in WWWC. I also think it has scaleing problems and a couple other things. Remember, WWWC is on version 3, I think ASP is still in the ones? I could be wrong.
Hmmm... if there is I sure don't know about it. You can't update live COM objects without shutting down the Web server. If you're talking about the MTS Unload option, that doesn't work because a busy site will constantly reload these objects before you can copy new files in. And if you're debugging that's not exactly transparent either (although the whole reload cycle is not that big of a deal really once you get used to it).
I've been demoing ASP COM development at developer conferences for two years now and it always gets a good laugh when it comes to rebuild the COM object. But it's not really funny - it's sad that MS in all these years of IIS has yet to provide a way to update objects loaded in the server.
>I think WWWC is a awesome, but I'm not going to throw ASP by the side. Maybe some of the future versions out perform WWWC? EIther way, I think I saw that WWWC3 is ASP compatible, why not learn ASP and use that syntax in whichever dev enviroment seems appropriate?
I agree with that completely. It's important to understand the technology in order to make the best choice. Otherwise you're just eating a marketing line. <s> Unlike most other Web vendors I try to be fair and always back up any claims of performance especially. Unfortunately, though, the ASP drawbacks are just to blatent to not capitalize on when the majority of developers work with ASP just because it comes from MS.
For many things WC is overkill and ASP is just the right fit especially for simple scripted pages. But if you start putting COM into the mix with ASP you're making things a lot more complex and at that point developers *have to* know what they're doing and how the tools and the Web work behind the scenes, because when the time comes that something doesn't go right (and it will) you won't get any help from IIS or your COM component. I can't tell you how many emails/calls I get from people with ASP questions - usually with me as the last resort contact... 90% of the time it's basic failure to understand how the architecture and COM works.
When it comes to performance and development time there's just no contest... If you can argue otherwise I'd guess you've never written a sizable Web app using COM objects in ASP - I have done several, and it's been a nightmare each time. The primary reason is that you simply cannot debug problems sensibly. If you use ASP to its fullest like passing ASP objects down to VFP you're giving up the ability to independently debug your Web components. If you don't do that then you're passing loads and loads of data back and forth over COM which is very inefficient and error prone. And debugging - it's back to the equivalent of Print statements (which now with IIS 5 won't even generate because error pages don't show output sent prior to an error).
Does ASP work? Is it easy? TO a degree yes. Yes, if you're very careful and pay tedious attention to detail. If you understand how COM objects work in IIS (security contexts, COM loading, threading issues etc). In short, the whole ASP scripting model is not as simple as some make it out when you look at it in a real running environment.
What if in the future ASP is faster? Well, sure it could happen. In fact, IIS 5 is much faster with ASP scripts due to better caching and 'pre-parsing' of scripts, but still no contest. The issue is the way the model works and how objects load in ASP, whcih is always a load/unload cycle. With VFP/VB type objects this is a big hit on the server especially under load.
