I developed for a year and a half using Netscape's LiveWire server-side development environment. LiveWire uses JavaScript as its only programming language. LiveWire and JavaScript have some serious design and implementation problems that make it unacceptable for anything but the most trivial server-side applications.

The weakness of the JavaScript Language itself is the main problem, so other server-side scripting solutions with weak languages such as ASP and Cold Fusion aren't much better. ASP allows use of PerlScript instead of JavaScript or VBScript, so it has potential based on language support, but the implementation is really awful. I strongly recommend Java Server Pages for server-side page scripting (and the larger J2EE (of which JSP is a part) for web application development).

Update 3/18/99: John Redford disagrees with my harsh assessment. Here is the e-mail reply he sent me.

Update 11/23/00: I haven't heard of anyone using LiveWire lately, so maybe it's going away? I think ASP, JSP/Servlets, and PHP may be taking over the world.

You have to compile the application, and manually tell the server to reload the new .web compiled file. ASP doesn't have this problem - when you modify an ASP page and a request comes in for it, IIS notices, reloads the source page, and compiles it in memory. ASP has plenty of other problems though so don't be confused and think this is an endorsement of ASP. Most Java Servlet engines will notice that you have recompiled a servlet class and will reload it as needed, eliminating the need to tell the engine yourself "please reload everything and lose all my sessions, I updated a servlet class".

The compiler and the .web file format it creates differs in each different release of Netscape Enterprise Server, so you have to keep track of which server this LiveWire application is going to run under, and use the right compiler for that version. You can't just use an old .web file in a new version of ES.

The LiveWire Application Manager /appmgr/ is itself a LiveWire application, and it uses Netscape's bogus "crossware" concept: a hidden Java applet and a bunch of client-side JavaScript, using LiveConnect to talk to each other. The result is a yucky HTML-based client side application that is slow and only works in Navigator 4. I happen to use Navigator 4 anyway but that doesn't make it any more fun to use. Very often, when working with the /appmgr/ application, I have gotten "document contains no data" and "network error: socket is not connected" and reloaded to find that everything was OK. Not good.

In Enterprise Server 2.0 and 3.0x, the LiveWire .web file could be anywhere, and files compiled into it were served from an imaginary directory. For example /website/livewire/myjsapp/index.html would be compiled into /website/livewire/myjsapp/myjsapp.web with everything else in that application, and would be served at http://www.mysite.com/myjsapp/index.html. That's pretty cool; no one can see your source code. Problem: In ES 3.5.1, Netscape hacked it so that the .web file's parent directory is REALLY mapped to the destination URL, so anything in the /web/livewire/myjsapp directory that wasn't compiled into the app is now visible! For example, there may be Java classes used via LiveConnect with JDBC database connection strings, or comments, or old versions of the compiled-in pages, or the "filelist" file used by JSACremote (the remote LiveWire application compiler). All of these are things the user should never be permitted to see for security reasons. And Netscape didn't even mention this in the release notes. Hel-LO, security hole! Stuff outside the document root (the parent dir of the LiveWire .web file, and all subdirs) can now be browsed like anything else!

No thread support exists in the lanugage, even though in LiveWire you have to worry about concurrency issues when operating on global objects - the Server object and the Project object and their properties. Manual lock support exists for rudimentary thread safety but it is really crude.

Object orientation is based on prototypes instead of inheritance. Well, this isn't really a flaw, but it seems like a mistake to me to introduce a theoretically valid but little-known object-oriented technique in what is supposed to be an entry-level scripting language. I have not spent enough time thinking about prototypes vs. inheritance to decide which is better, if indeed there is a "better" alternative. But, I do understand inheritance well and I don't really care enough about JavaScript in general to learn something which is virtually unique to it even if it is better.

String and numeric manipulation is clumsy. It's crude, although not as crude as in C for example. Perl 5 just kicks JS's butt in this area hands down. Perl is the king of string manipulation, in terms of speed and language support for complex string operations. Going from Perl to JavaScript really hurt when I wanted to use clever regexps and such. Finally, Netscape decided to include Perl 5 regular expressions in JavaScript as of JS verison 1.2, but it is so bizarre in an object-oriented syntactical context that I still find it annoying.

There are naming issues that hinder efficient use of object-oriented methodology. There is no way to package a bunch of JS functions into a file and give the package a name so that the function names won't conflict with other functions in different files. So you have to name all your functions in a given application with globally unique names. This seems like a nitpick, until you realize that JS object methods are defined by naming the global function that implements them - the code for the method doesn't go inside a class definition. The constructor function (named with the same name as the object) has a list of "method_name = method_function_name;" statements, and then you define "function method_function_name() {}" elsewhere. Yuck! So if you wanted to use "connect" as a method name, watch out. You had better not have 2 objects that have connect methods; if you do you will need to manually rename one or both functions so there is not a name conflict. Meanwhile, your application isn't getting better; you're just resolving language problems by hand instead of being productive.