John Redford (garrow@kaze.fmr.com) wrote:

I am writing in response to your "Why LiveWire Sucks" article. I have
been using it quite a bit and I thought you might appreciate another
viewpoint.

First, I have to say that I don't think JS is a weak language, for
what it is intended to be. It lacks many features of other programming
lanaguges, but it is not supposed to be used that way.

I'll just respond to your bullet points:

   You have to compile the application, and manually tell the server to
   reload the new .web compiled file.

In my environment this is a real benefit. There are a number of people
who work on different parts of a system. It is important to be able to
check that everyone's contributions are in place before switching what
the server is doing. It is also easier to make a backup copy of a
single .web file than it is to backup a multitute of html and ASP
documents.

   The compiler and the .web file format it creates differs in each
   different release of Netscape Enterprise Server, ...

This is a little annoying. I am glad that Netscape improves their
format, but backwards compatability would be nice. Still, one does not
upgrade webservers that frequently.

   The LiveWire Application Manager /appmgr/ is itself a LiveWire
   application, and it uses Netscape's bogus "crossware" concept...

I dont use the appmgr, or any of Netscape's admin server GUIs. You are
right that they are not very good, but it is much easier and safer to
just modify the jsa.conf file.

   Problem: In ES 3.5.1, Netscape hacked it so that the .web file's
   parent directory is REALLY mapped to the destination URL...

This sounds pretty serious. I haven't investigated it yet. But I have
always made of the fact that files which are not compiled in are
visible. This is handy for placing client-size JavaScript .js files
in the same area.

   No thread support exists in the lanugage

I think you should make a case of how this could be useful. Database
calls are asynchronous; there is no clear reason to have threads.

   Object orientation is based on prototypes instead of inheritance.

I happen to have spent a lot of time studying issues like this. I'd
reccomend the book _A Theory of Object_ by Martin Abadi & Luca
Cardelli.  It is not really a question of prototypes vs inheritance,
but prototypes vs classes. JavaScript lacks a class declaration
syntax. The result is very simplistic code. This is a real benefit for
making objects easy to use -- at the expense of making them robust and
safe.

   String and numeric manipulation is clumsy.

JavaScript 1.1 is not worth anything, but 1.2 is very good. The object
oriented regexp style in JS 1.2 is basically the same as that which
the Perl5 developers are introducing into Perl itself. The real
benefit is that precompiled regexps can be passed as arguments to
functions and stored as data.

   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...

Objects are the namespaces, and you can reuse function names assigned
to methods.

function x () { return this + "<br>" }
String.prototype.br = x;
function x () { return this + "<hr>" }
String.prototype.hr = x;

This code works, and there are other ways to do it also. It isnt
pretty, but it is rather clever.

I think there are two important points you missed entriely. One is a
very good and the other very bad.

The ability to write glue code in C and execute it from SSJS is really
beneficial. I think that if someone wants to write something complex,
they are best off writing it some other language & then exporting
functions to JavaScript. This is very similar to the way that
languages like Perl simply provide front-end access to underlying C
and C++ code.

The main problem I have with JavaScript, both on a server and on a
client is the quoting.  Embedding JS code in a HTML document and then
trying to have that code write out HTML code with quoted tag
attributes is a real pain.  Eventually I found myself writing a slew
of JavaScript libraries to encapsulate this, but it still gets quite
ugly at times.

Anyway, I appreciated you article. Thanks for reading this, too.

--
John Redford
AKA GArrow