Javascript was standardized as Ecmascript but retains it's own identity as the implementation in Firefox. Javascript is Ecmascript compliant but has extensions that may or may not be standardized in future Ecmascript versions. Firefox currently implements Javascript 1.8.1 which is compliant with Ecmascript 3 and E4X. Ecmascript For XML (E4X) implements XML as a built-in datatype making it easy to manipulate XML without using DOM, SAX, XPATH or other XML APIs.
Javascript is an embedded language. Unlike general purpose languages such as C++, Java, and Python, Javascript does not have libraries for common computing resources like file system, network or database access. It relies on the host environment to provide whatever is needed. Javascript does specify how an implementer can include built-in objects that are available at run time and host-provided objects that are unique to each embedding context.
In the browser, host objects include Window and DOM objects. Firefox, much of itself being written in Javascript, provides access to most of the Mozilla platform objects and general purpose objects for local (non-web) applications. These objects included file IO, network IO, password encryption, Sqlite and XUL UI elements. Firefox extensions have access to these objects. Java libraries are also available to Javascript in the browser via LiveConnect. The javascript implementation in Firefox is called Spidermonkey. There are several projects that use Spidermonkey on the server. One example is CouchDB.
In the late '90s, Netscape decided to rewrite the their browser, Navigator, in Java (Javagator). The only piece that was completed and remains today is the Rhino Javascript implementation. Rhino is an actively maintained open source project. Rhino is written in Java and interpreted or compiled to JVM Bytecode. Rhino has both an interpreter and a compiler. The host objects in Rhino include all available Java libraries. Rhino is currently Javascript 1.6 compliant. There are several projects that use Rhino on the server, including a Rails clone.
Javascript on a vritual machine is the same language but with access to all computing resources of the VM rather than the limited, though very useful for web browsing, resources of a security-sandboxed application like a browser.
The Javascript implementation in XPages, like Rhino, is written in Java and executes on the JVM. Host objects provided by XPages include the Notes Java API, and the JSF APIs. Expeditor supports the JEE stack up through JSF so XPJS running on the client would have access to the same libraries.
XPJS is Ecmascript 3 compliant with two exceptions that I know of: @Functions and optional type declarations.
@Functions in XPJS are built-in objects provided by the language implementation. Many of these functions are dependent on the Notes and Java host objects. In order to allow these function names to start with "@", the XPJS language definition was "altered" (hacked!) to allow any identifier to begin with the "@" character. You can write your own function names starting with "@". Please don't. Actually, you can start any identifier with "@" ( var @x = 1; ), but, again, use a namespace object or some other standard convention to keep your functions out of the global namespace.
The other language addition is optional type annotations. This was proposed by Mozilla for Ecmascript 4, so it makes sense that Lotus adopted it in the Workplace timeframe. Since then, events have significantly changed the Ecmascript roadmap and put many of the proposed Ecmascript 4 features, including optional type annotations, in flux. What does the optional type declaration do? It provides the developer with a visual indication of type and the interpreter/compiler can warn of certain type errors. What it doesn't do is include that type information in the generated bytecode. There is no run-time benefit as with statically typed languages. This is consistent with Javascript being a dynamically typed language; all types are resolved at run-time. I confirmed this with the XPages team at Lotusphere.
For several years, there had been two camps battling over the Ecmascript roadmap. One camp, led by Mozilla CTO, Brendan Eich who created Javascript, proposed a somewhat radical roadmap that would have added classes, packages, optional type declarations and many other features available in popular general purpose languages. This roadmap was known as Ecmascript 4. The other camp, led by Microsoft and Yahoo, proposed a much less aggressive incremental roadmap that didn't expand the scope of Javascript beyond the web. This roadmap was known as Javascipt 3.1.
Last year, a compromise called Ecmascript Harmony (Ecmascript ~6) was reached. The Ecmascript 4 camp had to concede some of the more radical changes to reach an agreement and get everyone moving forward. Packages are out. Classes will be implemented as syntax sugar for closures rather than a new construct. Optional type annotations may happen. What about Ecmascript 5? The 3.1 proposal became Ecmascript 5, which is the current draft proposal.
I hope that XPJS will maintain Ecmascript compatibility and perhaps even implement E4X. I know that they would like to do it, but other priorities, including performance, may delay things. I'd hate to see XPages developers using an outdated, non-standard scripting language a few years down the road. Please don't Lotusscript the Javascript. Speaking of performance, InvokeDynamic, the first new bytecode added to the JVM in 14 years is now in early draft review. Dynamic method invocation is about to get a whole lot easier and faster.
So was this just a transparent attempt to express my dislike of "SSJS" to describe XPages Javascript? Yes, it was. I may be too late ;-)
Update: @headius I just heard there's a good chance invokedynamic will get into a Sun Java 6 update, via a flag and separate rt.jar add-on. [@headius is Charles Nutter, JRuby implementor and Sun/Oracle employee]
