The thing that Unity dropped wasn't really JavaScript, and nobody in their right mind actually used it. It was called "UnityScript", and it was just a thin veneer over CLR that looked a bit like JavaScript, but exposed the CLR object model and C# APIs to arrays and dictionaries, etc, instead of supporting standard JavaScript APIs. The biggest problem was that most JavaScript libraries aren't compatible with UnityScript. Another big problem is that it wasn't as powerful, useful, and standard as C#. And yet another problem is that it wasn't an interactive language, so you couldn't load it at runtime, and had to run it through the compiler (which could take half an hour before you could see your changes).
>It is not uncommon for Unity developers and even members of Unity Technologies to refer to Unity's JavaScript like language as simply "JavaScript", as if it was equivalent or interchangeable with what most people know of as JavaScript on the web. However, the two are actually very different languages. Although they do resemble each other syntactically they have very different semantics. While "JavaScript" is merely a generic name and could refer to any one of many implementations of the ECMAScript specification, Unity's "JavaScript" language doesn't even come close to conforming to that specification — nor does it try to. It's a proprietary language and it doesn't actually follow any concrete specification of standard JavaScript and is modified at will by the engine developers.
>Because of this, the vast majority of JavaScript libraries you find will not work by default in Unity. Unity's "JavaScript" is most similar to Microsoft's JScript.NET, although it is not quite identical. Thus many developers prefer to call the language Unity uses "UnityScript" instead, to help differentiate it. Some people consider this to be "just semantics", but when people call both "JavaScript" it becomes a lot harder to search the internet for solutions and help related to Unity. It's also quite a lot of trouble to continuously specify whether one is referring to "real" JavaScript or Unity's version. So it's best to just stick with "JavaScript" for real JavaScript and "UnityScript" for Unity's language.
Unity also had a language called Boo that was to Python like UnityScript was to JavaScript, and nobody in their right mind used that either. UnityScript is actually a layer on top of Boo. Both UnityScript and Boo are obsolete and deprecated, fortunately, and nobody will miss them. Your time is MUCH better spend learning C# than UnityScript or Boo.
On the other hand, I've been developing UnityJS, which lets you program Unity3D in real honest-to-god JavaScript, download and debug code at runtime without recompiling your Unity app (which makes development astronomically faster), and use any standard JavaScript libraries and tools. And it works really well with the WebGL platform, for integrating Unity apps with web stuff, as well as on iOS and Android too.
As I am not a Unity developer, I thought the differences between US and JS were superficial and I wasn't aware they're incompatible in that degree. UnityJS seems interesting. What is its status? Is it a draft or usable already?
I recently refactored that monolithic repo into a bunch of smaller nested repos, to make it much more modular and layered, so that different projects for different platforms can pick and choose which modules to use.
I'm still in the process of documenting how to install it (now that you have to wrangle git submodules it's tricker), and how to use it (there are a lot of moving parts, and different platform specific pieces). But here is some high level stuff:
(Some of the paths in the above file have changed in the name of modularity.)
Since Unity insists that you put different kinds of files in certain fixed directories like StreamingAssets (for all the .js files and web content) and WebGLTemplates (for the WebGL wrapper that loads your JavaScript code), you can't make a module with one single github repo that has different sub-directories that would straddle the fixed Unity directories. (And symbolic links don't work on all platforms, so you can't fudge it.) So it is necessary to split some modules up into different repos, so the one with C# code can go into Libraries, and the one with JavaScript code can go into StreamingAssets, and the one with the html wrapper can go into WebGLTemplates.
Here's the repo with all the C# code and resources:
Send me email if you want to know more! I'm happy to answer questions and help you get it working, and to hear your feedback, which will help me write more and better documentation.
The thing that Unity dropped wasn't really JavaScript, and nobody in their right mind actually used it. It was called "UnityScript", and it was just a thin veneer over CLR that looked a bit like JavaScript, but exposed the CLR object model and C# APIs to arrays and dictionaries, etc, instead of supporting standard JavaScript APIs. The biggest problem was that most JavaScript libraries aren't compatible with UnityScript. Another big problem is that it wasn't as powerful, useful, and standard as C#. And yet another problem is that it wasn't an interactive language, so you couldn't load it at runtime, and had to run it through the compiler (which could take half an hour before you could see your changes).
https://wiki.unity3d.com/index.php/UnityScript_versus_JavaSc...
>It is not uncommon for Unity developers and even members of Unity Technologies to refer to Unity's JavaScript like language as simply "JavaScript", as if it was equivalent or interchangeable with what most people know of as JavaScript on the web. However, the two are actually very different languages. Although they do resemble each other syntactically they have very different semantics. While "JavaScript" is merely a generic name and could refer to any one of many implementations of the ECMAScript specification, Unity's "JavaScript" language doesn't even come close to conforming to that specification — nor does it try to. It's a proprietary language and it doesn't actually follow any concrete specification of standard JavaScript and is modified at will by the engine developers.
>Because of this, the vast majority of JavaScript libraries you find will not work by default in Unity. Unity's "JavaScript" is most similar to Microsoft's JScript.NET, although it is not quite identical. Thus many developers prefer to call the language Unity uses "UnityScript" instead, to help differentiate it. Some people consider this to be "just semantics", but when people call both "JavaScript" it becomes a lot harder to search the internet for solutions and help related to Unity. It's also quite a lot of trouble to continuously specify whether one is referring to "real" JavaScript or Unity's version. So it's best to just stick with "JavaScript" for real JavaScript and "UnityScript" for Unity's language.
Unity also had a language called Boo that was to Python like UnityScript was to JavaScript, and nobody in their right mind used that either. UnityScript is actually a layer on top of Boo. Both UnityScript and Boo are obsolete and deprecated, fortunately, and nobody will miss them. Your time is MUCH better spend learning C# than UnityScript or Boo.
UnityScript’s long ride off into the sunset
https://blogs.unity3d.com/2017/08/11/unityscripts-long-ride-...
On the other hand, I've been developing UnityJS, which lets you program Unity3D in real honest-to-god JavaScript, download and debug code at runtime without recompiling your Unity app (which makes development astronomically faster), and use any standard JavaScript libraries and tools. And it works really well with the WebGL platform, for integrating Unity apps with web stuff, as well as on iOS and Android too.
https://news.ycombinator.com/item?id=19804242
https://news.ycombinator.com/item?id=19748582
https://news.ycombinator.com/item?id=20744552
https://news.ycombinator.com/item?id=20745676
https://news.ycombinator.com/item?id=18171571
https://news.ycombinator.com/item?id=18860467