Javascript 1.5 Release CandidateSunday March 19th, 2000Robert Ginda wrote in to tell us that Javascript 1.5 is now in the Release Candidate stage. Click here to read the newsgroup announcement. If you are interested in the Javascript-in-C implementation (aka SpiderMonkey), you can click here to visit the SpiderMonkey page, or click here to download the tarball of the 1.5 RC SpiderMonkey code. Also be sure to check out the C Engine Embedder's Guide. If you are interested in the Java implementation of the Javascript interpreter (aka Rhino, after the O'Reilly book), click here to visit the Rhino page, and here to download the zipped Rhino 1.5 RC package. Javascript 1.5 is compliant with ECMA-262 revision 3. To read more, visit mozilla.org's Javascript 1.5 page. I have made several abortive attempts at writing some DHTML for Mozilla. The stumbling block is knowing which version of Javascript and/or ECMAscript the lizard adheres to. Any pointers? erm.. 1.5, or just plain "JavaScript" will work fine (and is what is used internally). You should be using the DOM for access to page elements, the version of JS is probably irrelevant Umm, maybe I interpreted the message differently, but I thought he was asking which DOM it was that Javascript adhered to. I'm guessing it's the DOM as released by W3C, which is similar to (but, of course, not the same as) IE4+. For further info, find the release notes. I don't actually know, just guessing. n/t You can click here to do this you can click here to do that Didn't that style of web page go out in about 95? No, riddley, this way of making links has never gone out of style, but it's worth mentioning again why it has never been considered the best way to do things: When a user encounters a non-descriptive link (f.e. 'you can -click here- to visit the Rhino page' instead of 'you can -visit the Rhino page-') they must look elsewhere to figure out the target of the link and then back to the link to go to that target. This takes a miniscule amount of extra time and causes a very small amount of frustration, but the time and frustration are not insignificant, and they make reading a web page more difficult and less enjoyable than it needs to be. The secondary problem is that a small link like '-here-' is more difficult to hit with the mouse, again necessitating extra time and frustrating precision. That's why in the example above I suggest making the words 'visit the Rhino page' a link instead of just 'Rhino page'.
It would be great to see a stand-alone JavaScript implementation, with a kind of module concept - similar to Perl. It would benefit from intrinsic Unicode support, more object oriented approach and much clearer syntax than Perl. Thinking of an XML parser and DOM module, it would be a great tool for automated web generation or as a replacement of Perl or PHP as a CGI script interpreter. Maybe Mozilla's JavaScript implementation is a good starting point for it. SpiderMonkey and Rhino are both stand-alone javascript engines, suitable for embedding in other projects such as Mozilla (alread done :-) ), web servers, etc. Both engines are already being used in non-Mozilla, non-Netscape projects, in fact. No, I don't meant a version that can be embedded into a browser, server or what ever (so far I understood this concept :-). I meant it as a stand-alone application, like the perl interpreter, e.g. that I can type in my shell: >js helloworld.js so that the file "helloworld.js" is loaded and executed, and after execution, the interpreter stops. This not only requires a simple wrapper around the embeddable engine, but also a (portable, system independant) library which gives access to system resources, e.g. file/directory/network access. Maybe this already exists, but I haven't seen anything like. If you know something like, please give me a pointer... The js shell is here: http://lxr.mozilla.org/seamonkey/source/js/src/js.c Alternatley, the xpcshell: http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/shell/xpcshell.cpp is a JavaScript shell with access to xpcom components, so you can create nsIFile objects, etc. xpcshell is built by default in debug mozilla builds, while the js shell is only built with stand-alone js. Directions for building stand-alone JavaScript can be found on the spidermonkey page. |