[rubber_duck]

That's because big engines are filled with stuff that 90% of the games won't use (ie. they wouldn't care if it wasn't there) but because it's a general purpose engine it needs to implement all that and be flexible in the implementation, and the dead code elimination can't do the magic because most of it is runtime driven.

You can still use something smaller/purpose built and compile to ASM.JS and it runs just fine - I rolled my own scenegraph for a visualization app in C++ - it compiled down to ~120kb of gzipped ASM.JS if I compiled out logging, and it ran on both browsers and mobile, it was even loading and rendering fast enough (~30 FPS) on mobile browsers on low end phones (eg. Mali 450GPU, some old quad core mediatek chip) with shadow mapping.

[socialist_coder]

You're definitely right about the feature bloat in Unity. We are probably only using 10% of the features, but like you said, we're still stuck with all that code. It must be a hard enough problem to solve that they didn't want to try and go down that route. Unity isn't dumb, I feel like they would go down that path if they felt it would be successful and was worth it.

> You can still use something smaller/purpose built

One of the advantages of using Unity though is that you don't have to write your game multiple times. Large studios can afford to do that, and they do. But for small studios, the ROI on porting your game to the web is not even close to positive, so hardly anyone does it.

[rubber_duck]

>One of the advantages of using Unity though is that you don't have to write your game multiple times. Large studios can afford to do that, and they do. But for small studios, the ROI on porting your game to the web is not even close to positive, so hardly anyone does it.

But once you have C++ code base with OpenGL ES 2 you're basically "web ready" - porting is pretty straightforward with emscripten. The only porting is what you would have to do with an engine anyway (input/gameplay changes for web)