That not only slows down and locks up both Unity and your entire computer and spins up the cooling fan like a 747 taking off while it's compiling for so long, but it also wastes orders of magnitude more time than what everyone is used to from interactively reloading and debugging JavaScript code, and it totally destroys the flow of getting into the "groove" and iterating extremely quickly and interactively like you can do with web development.
The whole point of UnityJS is to enable you to instantly reload your app and see your changes without recompiling, and use the modern high-quality off-the-shelf JavaScript debuggers built into every web browser to debug your WebGL apps live in a web browser, and your iOS and Android apps live while actually running on the device. And also to benefit from the gargantuan ecosystem of standard JavaScript libraries and the communities and companies that support them, instead of rolling your own half-assed bastard stepchild C# imitation libraries that require constant maintenance and quickly go out of date because nobody else uses them.
There are many application domains, especially AR and VR and accelerometers and cameras, that are impossible to simulate in the Unity editor, and developing them requires quick turn-around and interactive debugging. That's where UnityJS really shines!
Here's a demo of an earlier version of UnityJS integrated with ARKit on iOS for Pantomime:
WovenAR Tools with ARKit and Pantomime
You can't possibly be serious here. You are comparing an ecosystem where the package manager can be gamed to includes malware in your code, where a small project need includes 1000+ libraries some having just one function in them, where core projects used by GAFAM can become unmaintained because of lack of funding, where most modules are created by random developers and will break your code on update to an ecosystem with a two decade old battle-tested extensive base class library made entirely by professionals, maintained by one of the biggest tech corp with a safe package manager. Also breaking API change from third party library are easily detected thanks to the type system.
The existence of bad unmaintained npm modules doesn't detract from the quality and popularity of the many decent JavaScript modules that exist and are widely used and supported.
Take d3, for example. It's excellent, well maintained code, that splendidly solves many practical problems. There is nothing anywhere near as powerful and flexible and well documented and maintained (and free!) as d3 for Unity.
UnityJS lets you use that JavaScript d3 library directly.
Now tell me which C# SocketIO library you use for Unity, and how it compares to the latest greatest version of the standard JavaScript SocketIO library? How many people are actively maintaining it, and how up to date and actively maintained is it? A github link, please?
UnityJS lets you use that JavaScript SocketIO library directly.
A 2gig mobile game should take 20 minutes to build to device tops and that's all from asset compression anyway. Recompiling the code should take no more than a minute unless you're using a potato.
The part of the compilation that actually eats your machine because its the only multithreaded part is the shader compilation, again not C#.
I don't know what kind of toy games you're compiling that take no more than a minute to completely compile and deploy with Unity3D: "2gig" of what, code or just video?
I'm not talking about pressing "Play" in the editor or deploying on Windows or Mac with Mono, I'm talking running it in the browser with the WebGL back-end, or on an iPad with the iOS back-end, using il2cpp and Emscripten or XCode, which are enormously slow and complex.
It certainly does take a long time on my Mid 2014 MacBook Pro (which while not new, is certainly not a potato), and it makes it useless for doing anything else while it's compiling, and spins the fan up to its highest speed and pins the CPU all that time.
A large complex multi player networked AR/VR iOS app like Pantomime with a lot of content including code and libraries and resources and plugins and shaders regularly took me a good part of an hour to compile, build and deploy. Developing UnityJS was my response to that problem, so I could rapidly iterate by changing code and JSON data and other resources, without recompiling.
WebGL and iOS builds are especially slow, because they go through layer after layer of cross-compilers, from C# to CIL with the Mono compiler, and then from CIL to C++ with il2cpp, then the XCode/CLang/Assembler/Linker or Emscripten/WebAssembly chains do their own ridiculously complex things, and there's also a significant amount of time spent packaging and compressing resources and data in various formats and wrappers.
You have to wait not just for the C# code to compile, and for the shaders and the resources to be processed, but for the entire multi-level Rube-Goldbergesque translation and packaging process to finish, then that build must be deployed on your web server or mobile device.
I'm talking about the actual turn-around time between when you make a change to the code, and see the results. You know, the thing you have to do again, and again, and again, and again, and again. So it adds up quickly.
UnityJS drastically slashes that time, however long it takes (and I have a hard time believing it takes no more than a minute for you, unless your app is trivially simple), to just a few seconds of refreshing the web page or quitting and restarting the iOS app.
For fast debugging turn-around, you can tell it to load the JavaScript code, JSON configurations, and other resources from a web server, and edit the code and content live on the server, so the app downloads the fresh JavaScript code, in mere seconds, each time you run it, without any recompiling.
It's very experimental still, and iteration times for web are still not amazing, but we do think we have a way to get them to be actually good, while still letting you write and debug C# as you would expect.
You can like Javascript more but know that you're doing something wrong if its taking you an hour to build a mobile game in Unity.
Edit: You should look into Rider too. I much prefer it over MonoDevelop. A mid 2014 MBP could be poor if you're running a low RAM config. They only went up to 16GB and if you have 8 you could be hitting swap and it'll be dog slow.