I have jabbered on about why I don't think LiveWire is any good for anybody trying to do anything that remotely resembles serious server-side programming. I have been accused of promoting Microsoft's "Active Server Pages" server-side scripting environment over LiveWire, which is hardly my intention. To even the score I originally wrote a length diatribe dissing ASP.
It got better. In typical MS style, the first release(s) were garbage, but they churned and came out with a better version. The same goes for the development tools; they're a lot better now.
I still think that a proprietary solution is bad, and ChiliASP doesn't change the fact that it's a proprietary 2-source product instead of an open-source product. So, JSP wins. And yes there are open-source implementations (too many to name them all here). JSP is a part of this complete breakfast.
Here is the original list of flaws, with updates marked where MS fixed their mistakes:
All of the scripting langauges available for ASP are weak. VBScript is the default scripting language, although there is this idea that zillions of other scripting languages can be "plugged in" if you don't like VBScript. In reality you have Microsoft's JScript (weak), plus a very watered-down version of Perl 5 called PerlScript (weak). Integration between the three languages is OK, but not great. It is nice to be able to hand strings from VBScript (which is the language everybody actually uses and which book authors write about) to Perl for Perl regular expression matching, but remember that all three languages are watered down scripting languages, so it's hard to get anything serious done. You can, of course, code up lots of database stuff, and lots of handy utility functions, but even if you're a procedural programming genius you'll end up with the same problems that procedural programming geniuses encountered with C - i.e. it's way too complex to maintain and you need OO languages and techniques to clean things up.
Microsoft's Visual InterDev is horrible, so you have to code stuff by hand or go with Wizard-ized solutions. Back when I didn't know how bad ASP was yet, I took an official Microsoft training course to see what Visual InterDev was all about - is it possible, a nice IDE that helps your low end HTML type worker to do web forms? Of course it's too good to be true. What you actually get is the standard Microsoft "Wizard" approach - cookie cutter form to database master-detail pages, which may actually make somebody happy in theory. However, I can't think of any projects I have ever done in the last few years of web development that the wizard would have been able to help with. It's just too limited. Now you may be saying, "but it could get you started, and then you can go in and write the hard stuff by hand, so it's still useful." No, unfortunately the code that Visual InterDev generates is extremely bloated with lots of UI code and generic procedural code. Since VBScript is not object oriented (it wants to look like it's object oriented but it doesn't meet any OO language criteria), you can't build up snazzy class libraries and then put little snippets of code in the ASP page that utilize them. Not even if you're Microsoft. So what you get is HUGE blocks of unreadable VBScript code, often the same functions pasted into every page. Try to maintain that! Forget it. It's better to just hand-code it yourself, espcially 9 months later.
When things break (and this happens a lot), all your site visitors get to see exactly what went wrong. If you've ever run a web site, you know that things break. All the multi-stage development process, QA, and other "best practices" help, but if you think you can keep your site from ever breaking, um, just take another toke on whatever it is that you're smoking. Worse, unless you're very lucky, a visitor stumbles across a broken area before you have noticed and fixed it. With CGI's, you see a "Server Error" which is a nice, general "sorry it's broken" message that tells the user that something broke, but they are not at fault and don't need to bother messing with their browser or bugging their own IS staff. It'd be nice if the server were to e-mail the webmaster to say "ouch", but at least it logs the problem and does a bit of damage control. Not with ASP. ASP is in perpetual debugging mode, and as a result, it foolishly reveals the error message to the end user. This can include things like "maximum number of database licenses (15) exceeded" as seen at http://www.warehouse.com/ one day, or it can show your source code. In general it gives away much too much information to the general public, from a security and PR point of view. If you've ever seen something like this message from http://www.acura.com:
... and you probably have seen that before (since ASP's are generally used by newbie web hackers, and NT breaks so often) then you know exactly what I'm talking about.
Update: apparently now ASP allows you to turn off / reduce error messages. Good work, MS.
Microsoft continues to push ActiveX, so you have to use it to get to a real programming language from an ASP page. Microsoft has done ASP hackers a big favor by creating the ADO, their database access object. If they hadn't done that ASP developers would never have been able to talk to databases without involving a C++/ODBC programmer to develop the VBScript/ODBC glue code. The problem is, what if you want to do simle things like keep a pool of persistent connections, cache query results, etc.? If you want to try and script this stuff in VBScript you run into scripting language limitations, such as lack of thread support, lack of complex data structure support, poor performance, poor third-party support, etc. So it's time to bring in C++ or preferrably Java. Uh oh, everything has to be ActiveX-ized, so that means all your Java classes have to be .dll files! So now you get to use Microsoft Visual J++, that not-Java-compatible decaf brand that Microsoft thinks will kill real Java by removing important functionality and breaking important syntactic and architectural rules. Wanna develop a distributed application that talks from an ASP page to an application server running on Sun's JDK on Unix, talking to Oracle? Whoops, they took out RMI, so you have to do it with ActiveX instead. Oh, by the way that means you have to run the application server on NT, which means it will crash a lot. What a wonderful architecture - everything runs on a bunch of creaky NT Servers. But it's where Microsoft wants you to go today, so if you use ASP suddenly you're running SQL Server on NT, because that was "easier" than using real Java, RMI, and Oracle.
Update: MS really cleaned this one up. Now you can return arbitrary Java objects from a COM object without DLL-izing them.