Hacker News Reader

> 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

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.

Having a gargantuan JavaScript ecosystem with many libraries of varying quality to choose from is a much better position to be in that Unity's position of only being able to compile and run a much smaller subset of the gargantuan Microsoft C# ecosystem, and in many cases needing to port or roll your own libraries and maintain them yourself.

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.

If your builds take a long time, it's definetly asset pipeline and not code. At this point, you should migrate your project to asset bundles to avoid rebuilding assets on every build - it should save you a lot of time.

>But debugging C#, especially on mobile and WebGL platforms, is a horrible primitive retrograde nightmare. And it takes a long long time to recompile, with some projects taking a good slice of an hour to build.

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#.

Do you mean it "should" or "does" take no more than a minute? And do you honestly find debugging Unity3D iOS apps running on mobile devices and WebAssembly/WebGL apps running in the browser a pleasant experience? Do you think MonoDevelop (when it works and doesn't crash) is better than the Chrome or Safari debugger?

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.

https://vimeo.com/154755183

https://vimeo.com/240612327

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.

We're working on those things, but we agree the debugging, performance, and iteration time are not in a great place for web today. We have plans for how to fix them, though, and are working on several of them currently. These are mostly under the umbrella of Project Tiny (the team I'm on), whose forum you can find here: https://forum.unity.com/forums/project-tiny.151/

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.

I do mobile Unity dev professionally on a team of 50+. A large game will be mostly textures or other art assets. You should profile your builds. The majority is probably texture asset compression, packaging, that sort of thing. Your build should not be dominated by compilation time. Running the Cacheserver can also help with this to some degree.

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.