Why isn't ThreeJS considered a serious game development option? Main shortcomings?

I am new to ThreeJS having only started playing with it for 4 days now. But so far it is an absolute blast. I have previously spent a lot of time with Unity. I have also played with other game development platforms briefly over time like Godot, Stride, Evergine, Urho3D. I code in C# and C++ usually, so Javascript is a bit new but pretty similar in general.

The biggest things I enjoy so far about ThreeJS compared to the alternatives are:

  • How incredibly simple it is to work with.
  • The lack of a bloated Editor that you are tied to.
  • Totally free (Unity screwed a lot of people with their license changes in the past year).
  • Simplest code only way to build a project with broad platform targeting - browsers, mobile, downloadable desktop game, etc.

The lack of an Editor I can imagine for many people might be a negative. But I hated all the bloated Editor systems of other game development systems. Bugs, glitches, massive sizes, updates, getting “locked in.” I prefer to work programmatically as much as possible.

I have not been here long enough perhaps to see the negatives, but I have searched and thought about it. I am curious what they might be.

The main negatives I imagine:

  • Javascript is “slower” than C++/C#, but I don’t know how significant this is unless you are building a AAA game like Cyberpunk 2077 that costs $300 million to make. Just how much “slower” is it really?
  • No manual garbage collection in Javascript. I could see this being problematic as unpredictable GC spikes can mess up gameplay. Again, not sure how bad this is if you’re not building something AAA.
  • No Playstation/Wii targeting pathway (correct?) though you can build for XBox.
  • Lack of built in easy tools like Shader Nodes in Unity, advanced extra features (though personally I find those things more “bloat” then benefit).

I find it interesting that there is nothing else really like ThreeJS (or I suppose BabylonJS?) in other languages.

If you want to build a code only game or app quickly that can target quite broad platforms using a free technology in C#/C++ there really isn’t anything that works out of the box.

Given that, I just find it surprising more people don’t go for this on serious-ish projects. I get it probably couldn’t handle AAA game projects where every frame counts. But for mobile games and Indie Steam type games (where eventual Nintendo release is not a goal ie. most cases), it seems like a great option.

Any thoughts?

1 Like

Godot / Unity / UE5 are superior in pretty much all aspects to WebGL (jncl. three.js) in terms of cross-platform games. WebGL is good primarily for web, as soon as you try releasing for native / mobile you’ll start to see major short-comings. Three.js is fun, but game engines ship games.

There’s a bunch - here and here - but once again, three works fast and well for web, for other platforms it becomes a bit of a pain.

3 Likes

:thinking:
https://threejs.org/editor/

I guess to add to your list of negatives, which is not really a negative but just an architectural difference is that three js is not a game engine as such ootb, although it can of course be used as a render engine for one…

2 Likes

I am reading about WebGL vs. OpenGL based on your reply. It is interesting.

WebGL requires that not only do we cross the FFI barrier to access those native OpenGL API calls (which still incur the same overhead), but we also have the cost of security checks to prevent the GPU being hijacked for computation.

If you are looking at something like glDraw* calls, which are called per frame, this means we are talking about perhaps (an) order(s) of magnitude fewer calls. All the more reason to opt for something like instancing, where the number of calls is drastically reduced.

From here.

WebGL is based upon OpenGL ES, which has some pros but also runs a bit slower and it has more abstraction levels for code handling than pure OpenGL has, and that is reason for lowering performance - more code needs to be evaluated.

If your project doesn’t require web-based solution, and doesn’t care which devices are supported, then OpenGL would be a better and smarter choice.

I suppose if there was a C# style system like ThreeJS that was similarly code only and would make it easy to add objects/meshes to screen or animate characters, etc. with easy cross platform support this would be nice. But currently there isn’t.

Probably most people to some extent also like all the vendor-lock big bloated Editor and Cadillac package of extra features in other systems so there is no interest to have something like ThreeJS in C#. Stride might get there one day but not yet. And no profit for companies like Unity/Unreal that make their money off of promoting vendor-lock.

The closest I know of is Silk.NET but this is much lower level than ThreeJS. The amount of work you’d have to do to get something useful on the screen just starting from that would be painful I imagine. Whereas with ThreeJS it is very easy to get something useful on screen which is so nice.

Perhaps nothing is perfect I suppose.

Thanks for your thoughts.

The true answer should be supported by experiments and research based on data, not an outcome from opinions of industry “experts”. Do your own research. Plan what you want to really know. Build POCs, collect data, and you will quickly realize that most of the things you know are not exactly as they are projected.

As all mentioned are frameworks for gaming consoles, where most of these consoles do not really support web, saying that something is superior is inaccurate.
I would rather compare what Godot / Unity / UE5 can output to the web in the form of WebGL / WASM / JS runtime in relation to a pure ThreeJS approach using a minimalistic setup: code editor + browser. ThreeJS is just a WebGL library.

I agree. I think people become biased from ideas and conjecture and things are not always what people assume. I could make up some simple torture tests or instantiating increasing numbers of rotating cubes for example and see what I can get on each. Doesn’t have to be anything fancy.

Can also take Unity and compare the natural Unity project against a WebGL build (since they support that) and quantify loss of function precisely.

I still suspect this is a better option than many people realize.

For example from here:

Actually javascript is rather fast with math and close to a compiled C code. I have a 3D engine built both in WebGL/OpenGL and i’m yet to find a noticable difference. I’ve tested a colossal terrain grid of about 256x256 (hfz terrain) in both loading/rendering performance and between desktop OpenGL/ES and there wasn’t really a difference.

Or counter this:

The problem with javascript is the Function Call overhead and moving the data into the buffers ( faster with typed/native arrays but that is not used often enough in js) is MUCH higher in C so the number of draw calls have to be minimized .A single mesh is great , 1000 objects are fine in C but not so js.

Or here:

Slow compared to what? Unity and Unreal both export to WebGL and are getting reasonable speed. I get 6000+ draw calls at 60fps on this demo on my early 2015 MBP in Chrome running in integrated graphics mode (ATM too lazy to switch to discrete which would be faster). I set it to 4000 fish, then pasted this in the JavaScript console g_fishTable[0].num[8] = 6000. Even taking it to 16000 draw calls I’m still getting 43fps.

On my media computer I use for browsing net and watching movies I can render 15000 fish using that demo at 60 fps. I don’t know what that represents in any meaningful sense, but again, I am really doubtful this is a major bottleneck for the average moderate or small game developer.

I also read about WebGPU and I suspect the gap will keep closing over time or become theoretical more than practically relevant.

I suppose I will see as time goes on. Thanks for your thoughts.

1 Like

skill issue.

2 Likes