They chose web tech for a few reasons:
- Lots of existing libraries out there to use
- Hiring JS devs is easier than hiring C++ devs
- The web is where UI innovation is happening
- Zero-click installation

After 7 years, what they ended up with is actually a spaghetti of different systems: they had lots of JavaScript but also had a local server that communicated with it via WebSockets, but also a central server that had its own API entry points, a native browser plugin, a Flash plugin etc.

2/5

A high level summary of their observations are:
- The UI of their tools didn't feel native. User tests indicated it _felt weird_
- Having a strong barrier between tool data and game-ready data is very valuable
- Being able to use any JS framework for anything resulted in nothing being reusable between different tools
- Dynamic languages make refactoring impossible
- Off-the-shelf web frameworks are not fast enough for tens of thousands of objects

3/5

- Developer tools support of new JS features often lagged behind main browser support
- Browser auto-updates break everything all the time
- People have Chrome plugins which will mess with the guts of the tool
- Off the shelf components, even if fast enough, don't have the professional-user feature sets they need
- It's impossible to stop browsers from caching random JS files, leading to random parts of your app being out of date all the time
- Node.js is dependency hell

4/5

Overall, they made the point that, if you're building on a browser, you're not in charge of a core piece of your product. And, it ended up creating an "us vs them" mentality between the (JavaScript) tools team and the (C++) engine team. No one was happy. So, going forward, they switched their stack to Qt, and started rewriting tools.

Review: 8/10 It was very good, but I can't rate it higher, because I can't imagine anyone seriously considering writing AAA gamedev tools this way nowadays.

@dotstdy

I don't actually think that's better than JS, for a number of reasons:

- The debugging / profiling story is worse, not better
- There isn't a proliferation of WASM web frameworks, like there is for JS
- The rendering still has to be done via the DOM, which is harder (impossible?) to use from WASM than from JS

If you're going to write C++ anyway, what's the point of running the result in a browser?

@GDCPresoReviews You don't need to do rendering with the DOM, I'd avoid that totally, likewise you don't need a framework. The advantage of running in the browser is just that it's a decent delivery platform, cross-platform and available on all devices.

more along the lines of https://editor.godotengine.org/releases/latest/

@dotstdy

If you don't want to use the DOM, then you're rendering directly with WebGL/WebGPU, which means now you have two problems instead of just one...

It is my strong belief that every single UI framework built for 3D graphics APIs (this includes Imgui!) is complete shit