Because it was not JS, it was UnityScript which is what happens when someone read "JavaScript: The Good Parts", and thought the title was "... The Bad Parts" and threw all those away and kept only the actual bad parts.

It was just about fine if you were doing very small projects but quickly got very hairy, and their compiler was full of bugs.

And to contrast, Godot's GDScript has been great for me so far. I've been hacking at a personal project for a couple of days now and I feel right at home in the language, which feels right at home in the engine.

I've actually been writing an engine in JS (with the exception of physics in WASM) partly to understand the implications of doing it.

You do need to be disciplined, however, being able to simply start extending random instances of other types proves remarkably useful when developing.

I'm not sure such a thing would work well on a team.

Probably not very good on a team, yeah. I actually have a bit of a toy game engine for the browser/ThreeJS targeted at making games similar to the Windows 95 screensaver. Learned some good things like GLSL and shaders but working in JS was definitely a bit of a slowdown when I'd hit classes of bugs that wouldn't be possible in C#, even with annotations helping me. But other times it was convenient being able to pass stuff around without writing up classes or structs for them as you alluded to.

Has a brief overview in its README if anyone wants to check it out: https://github.com/ldyeax/MazeEngine

I have more expansive ideas for it but for now the main demo is this silly museum. https://jimm.horse/maremuseum

It's a fun experiment in seeing what JS can do, it's cool having it run natively on the web, and annotations get you a lot of the way there, but in a context like Unity I'd never pick it over C#. Typescript might be alright but at that point why bother? C# has anonymous types, tuples, and such today too.