|
|
|
|
|
by ojosilva
2024 days ago
|
|
No. JavaScript was a web language for web developers to be able to automate forms, etc, client-side. AFAIK, originally it was never intended to run on the JVM server-side like Groovy does. Netscape did try to position server-side JavaScript as part of its Enterprise Server package though, but it was not JVM-based. But the environment was proprietary and not compelling enough for a myriad of reasons. It ran server JavaScript in CGI mode. JavaScript took a long time to actually make it server-side. First with standalone interpreters (ie. Spidermonkey) and later with a full-fledged runtime and development environment (NodeJS). |
|
Sure, but that's not an argument against JavaScript having potentially been a planned part of the JVM ecosystem (or, at least, a language playing a role in the JVM ecosystem, without itself being hosted on the JVM, instead maybe interacting with the JVM through some kind of IPC or FFI bridge.)
Remember, Sun used to be trying to squeeze the JVM into web browsers as well, in the form of Java applets. But we never saw any real ability to script against these applets. "Java applet 'engines' under JavaScript control", could have been the portable equivalent to "ActiveX components under JavaScript control."
You know how modern games involve 1. a self-contained game engine written in C++ or C#, plus 2. the game itself being mostly Lua scripting? If Sun had pushed harder, we could have seen something like that in 1995, with web browsers running JavaScript-scripted games calling into Java game engines; long before we got equivalent HTML5 APIs like Canvas.
Probably, if the world had gone down that path, we would have seen JavaScript gradually moving "into" the JVM; and the JVM gradually coming to take the position that the JavaScript engine takes in modern web browsers.