Do you want to write code in JavaScript? That’s deprecated.
Do you want to target WebGL? It works but it’s less than ideal. If you want to make a WebGL app, Unity would not be my choice. The tooling used to fall into the “that works, but it’s cursed” category, because it would compile the C# to CIL with Mono, then compile CIL to C++ with il2cpp, and the C++ to JS with Emscripten. I think. If you think this pipeline is “extremely cursed”, well, you’re not alone.
If you want to make a browser game with tooling, there are some better options. Different options for 2D and 3D. You’re going to have to accept some kind of compromise and the ecosystem is a bit difficult to navigate.
Whoa, JavaScript support is deprecated? News to me! I always use C# anyway but still seems like a shame.
And yeah, agreed, it's probably pretty clunky compared to what some WebGL-specific frameworks might give you. I don't know if anything out there has quite the UI setup or polish as Unity though. Do you know of any?
Deprecating JavaScript (UnityScript) is a good thing. Language bindings are a nightmare, and the more languages you support, the worse it gets. Consider that you might want to write a class in C++, wrap it in a C# interface, and then use it from UnityScript. Consider that if you write something for the asset store, the consumers may be using C# or JS.
If you’re looking for something with good UI and polish, maybe GameMaker Studio fits the bill? I don’t keep tabs on this space. I use Unity when I’m collaborating with people, and use simpler frameworks when I’m working alone.
I totally agree that UnityScript and Boo were terrible ideas and executions that were cursed, and it's a great thing they're deprecated.
JavaScript itself though is great. But the standard ways of integrating Unity and JavaScript in the WebGL back-end are extremely inefficient, terribly designed, and leave a lot to be desired.
There are much more efficient ways of communicating by judicious use of P/Invoke and insight into how WebAssembly and the C# / Unity JavaScript runtime binding works, which I've studied and leveraged in UnityJS. See some of the links in the other message I posted about UnityJS that discuss the JavaScript/C# JSON messaging bridge I developed, which is based on P/Invoke instead of Unity's terrible "GameObject.SendMessage", and techniques for blitting images and raw arrays of typed numbers back and forth between Unity and JavaScript.
The great thing about Unity that makes it worth all the effort of making up for its other weaknesses is its editor, and the ability to extend the editor with custom user interfaces, by widgets and editors in the object property sheets and 3d gadgets and objects in the world itself. The editor and its customizable UI facility is a common ground for artists and programmers to meet, that enables programmers to give artists a huge amount of power and flexibility, and artists to see and totally control what they're creating immediately and interactively.
Here's a demo of Unity3D pie menus that shows and explains some custom editors, as well as in-world editing tools. (It's kind of old, so the demo requires the now-obsolete Unity browser plug-in, since it isn't compiled for WebGL.)
They have a full set of useful notifiers so you can tightly integrate them with your application to give rich feedback during tracking (for example, modifying the 3D menu items, or previewing the effect of the menu item and distance parameter in real time, making them more like "direct manipulation").
For example, to show how you can implement feedback like The Sims pie menus with the head in the center that looks at the selected item, I've made a 3d object in the pie menu center with the webcam texture on it, so YOUR head is in the center of the menu, looking at the selected item! (That's why the demo asks for permission to use the webcam.)
The pie menu and each item has a title as well as a description. One feature I've added is the ability not only to disable an item, but also to provide an explanation of why the item is disabled! (PacMan in the demo is disabled, for example.) I wish other menus and widgets would do that -- it's frustrating when you can find an item you want, but can't figure out why it's disabled!
Another nice thing about them is that you can either configure algorithmically with an API, or with JSON data (which makes it easy to make dynamic data driven menus downloaded from a server or database), or construct them in the Unity3D editor out of objects (which makes it easier for artists to design them)!
I've made a custom Unity3D editor that lets you edit the properties, drag and drop textures and objects, edit and rearrange the items, and has some convenience commands, so you can place the 3D item objects in a circle in the 3D world, and call a command that figures out which item is in which direction by their position, and tidies them up. (That is much easier than arranging their order in a linear list of items.)
I'm going to play around with more in-world editing features, to make them easier for artists to design them.
I totally agree that JavaScript sucks, but that's not a good enough reason to boycott it, because it's absolutely ubiquitous and so well and widely supported.
And no matter how bad it is as a language, it still beats compiled languages as a dynamic extension and scripting language.
Another non-technical advantage: Apple allows iOS apps on their app store to dynamically download and execute JavaScript code, as long as you run it in Apple's Safari browser component (which UnityJS does). But even though it's technically possible, you aren't allowed to do that with Lua, Python, TCL, Visual Basic, Pascal, C++, C#, or any other interpreted or compiled language.
So JavaScript occupies a special spot in the universe, the web ecosystem, and also the iOS ecosystem, that makes it not matter if it sucks.
Plus a lot of smart people and big projects are working hard to mitigate its suckyness, make it run faster, and integrate it with all kinds of different platforms and APIs, like TypeScript, WebAssembly, AssemblyScript, React Native, Chrome Embedding Framework, Electron, and all the apps like PhotoShop you can script in JavaScript.
Even Adobe finally figured out they should use the real thing instead of jerking you around with ActionScript or some other weird language like AppleScript.
UnityScript sucks much much more than JavaScript, and has none of its advantages of tooling, libraries, running in every browser, etc. It's a terrible idea to make or use yet another language that's almost but not quite entirely unlike JavaScript.
Who’s boycotting JavaScript? I’m still using it. I’m writing JavaScript libraries right now.
There’s not really a hard line between “compiled” and “interpreted” languages, and there is really nothing that makes JavaScript beat “compiled” languages for dynamic extensions and scripting. The only advantages that JS have here are in the work that we’ve put into e.g. V8 and SpiderMonkey, but those are a bit harder to drop into your project as a library than you might like. I don’t see how they’re radically better than, say, Mono, which accepts any language compiled to CIL (and has P/Invoke!).
I’ve done some pretty deep comparisons of extension languages and my conclusion is still the same—differences in language implementation dwarf differences in language. You need a sandboxed extension language? That’s an implementation issue. You need to avoid dynamic libraries or run-time code generation? Implementation issue.
There certainly is a hard practical line, the build time / runtime line. And the hard line of publishing an app on the app store. No reason to get all hand-wavy or invoke Turing completeness. I'm not talking in the abstract here. I'm talking specifically about Unity3D, the il2cpp tool chain, and also the Apple app store, and specifically comparing them with V8 or whatever runtime JavaScript engine your favorite browser uses, and its runtime debugging tools. All the work that's been put into JavaScript that we all benefit from is the whole point.
C# and UnityScript are compiled at build time, not at runtime. JavaScript is interpreted or compiled at runtime. That line is very hard and crisp and well defined and practical, not a matter of principle of computer science pontification. Unity apps can NOT interpret or compile C# or UnityScript code at runtime, period.
And for many hard reasons, technical and not: It's a violation of Unity's licensing agreement to ship the il2cpp compiler with Unity apps, even if it were technically feasible (which it's not). It's a violation of Apple's app store policy to ship any kind of interpreter or compiler with an iOS app, other than their own JavaScript engine. None of those rules are going to change. You can't cross that hard crisp line.
You don't need to drop a JavaScript engine into your Unity3D WebGL app, because your WebGL app is already dropped into the JavaScript engine of the web browser itself. UnityJS simply uses that one. And iOS and Android have very fine web browser components that have perfectly modern JavaScript engines which are quite easy to drop into your app, and work quite well, which is what UnityJS uses on those platforms.
Show me a Unity3D app that runs on WebGL or iOS or Android, that compiles code at runtime. If you can link to a github repo so I can so how the code actually works, that would be even better. And I'd love to hear from the developer first-hand how they convinced Apple to bend their stringent app store rules just for them, but nobody else.
Now tell me honestly, how do Unity's C# and UnityScript debugging tools compare to Chrome's and Safari's JavaScript debugger? Do you actually use them yourself? Have you been able to use MonoDevelop to debug an app compiled with il2cpp on iOS or WebGL? What's your magic trick? It doesn't work for me. It's simply not supported. Where to I click to make it work? Please link to a youtube video with a tutorial.
And even if you used the Mono runtime, which is deprecated and not supported on iOS or WebGL, it is extremely buggy and unreliable even on platforms where it works, and absolutely and objectively sucks compared to the JavaScript debugging tools. It doesn't even let you interactively evaluate C# expressions, redefine functions, or edit and continue code, which the Chrome Debugger does quite well, and even Microsoft Visual C++ has let you do for decades.
So let me try to rephrase it for you: The position JavaScript occupies is great. No other language occupies that position, or will in the foreseeable future. It's such a great position, that in spite of all your disdain for it, you (and millions of other people) are using and writing JavaScript libraries yourself, even though you hate it. That's what I mean. JavaScript may not be great at making you happy, but it's great for solving common real world problems, in a way that no other language can.
This conversation has taken a very disappointing turn, and it just feels adversarial now. When you say something like,
> And no matter how bad it [JavaScript] is as a language, it still beats compiled languages as a dynamic extension and scripting language.
In a normal conversation, I can disagree, and we can argue all we like about the reasons we like or dislike various languages for dynamic extensions / scripting. Maybe I might learn something! But no, I'm just reading a monologue that you wrote about why JavaScript is better, filled with arguments that I've already heard.
Especially when working in an environment where Quaternions[0] are a core concept and one which often must be manipulated. Never mind JavaScript's inability to encapsulate.
Eh, I don’t buy that reasoning. JavaScript is excellent at encapsulation, since you can just use closures. Never had a problem manipulating quaternions in JavaScript. I’ve written a few 3D games in JavaScript or TypeScript. Some using engines like Three.js, others using bare WebGL, and some using math libraries like glMatrix, others using math routines that I wrote.
It was a javascript-like language called UnityScript, that actually compiled to IL, and had a lot of C#/CLR features tacked on top. It was fairly unused, and kinda cursed to boot.
Unity also had another language called Boo, which was fake Python which also compiled to the CLR, and we're happy that's dead too.
There's some packages like MoonSharp which will let you write Lua for Unity (modulo some bindings), and a few visual scripting tools too. There's also going to be a native visual scripting tool coming out in the next year or so.
One important distinction is that C# and UnityScript and Boo are build-time compiled languages, not interpreted (or JITted) at runtime like JavaScript typically is.
You can't dynamically download and interpret UnityScript code at runtime, or include it in downloadable asset packages.
If you make any changes to your app, you have to release a new version of it, and convince users to upgrade, and you can't just push an update out over the web, like you can with JavaScript.
This comes into play on the Apple app store.
Even if you implemented, say, a Scheme interpreter in C# that could interpret s-expressions at runtime, Apple would not let you publish an iOS app on their app store that downloaded Scheme code and interpreted it. It's not impossible or hard to do, but it's simply against their rules.
On Apple's app store, the ONLY language you're allowed to do that with is JavaScript, running in Apple's own Safari web browser's JavaScript engine.
That is a hard non-technical constraint that there is no way of programming or negotiating your way out of, and it's not going to change any time soon.
The old version of the iOS Safari component, UIWebView, runs in-process, and allows you to call back and forth with native code (it has a nice native Objective C bridge), but it did not have a JIT so it was slow. (Sandboxed iOS apps developed outside of Apple aren't allowed to write to code memory, so JIT compilers are prohibited.)
But the new iOS Safari component, WKWebView, runs in a separate process that Apple trusts, and it has the JIT enabled, so its JavaScript engine is extremely fast and robust, and fully compatible with most modern JavaScript libraries.
But you can't call native code, because it's running in another process, and doesn't support an Objective C bridge.
But you can send messages back and forth (tell it to execute JavaScript code, receive JSON or text messages back from JavaScript, but no directly passing pointers or calling functions).
So instead of using a platform specific Objective C <=> JavaScript bridge like the one Apple deprecated, UnityJS has a cross platform C# <=> JavaScript bridge with a JSON protocol, so it works fine with WKWebKit, without breaking Apple's app store rules.
