Mastodawn

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.

@GDCPresoReviews you could do it these days with wasm :)

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/

Free and open source 2D and 3D game engine

Use the Godot Engine editor directly in your web browser, without having to install anything.

Godot Engine Web Editor

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

@GDCPresoReviews heh, yeah i don't really agree with that one. writing complex tools with the dom or even things like qt is nightmare fuel compared to something like imgui.

to each their own :)

@GDCPresoReviews at any rate i agree you certainly wouldn't want to do it with standard web dom stuff the way insomniac did. there's just way too many compromises and it's practically impossible to hit performance and reliability goals.

Right. The presentation makes it very clear just how terrible of a decision it was.

@GDCPresoReviews @dotstdy i'm planning on ripping out python and replacing it with lua in my synthesizer project mollytime for the purpose of making wasm simpler. the singular benefit of being able to just give someone a url to put it in their hands is what makes it worth it to me. it's just going to use SDL though, don't care about the browser dom

@aeva @dotstdy

https://github.com/Aeva/mollytime 👀

GitHub - Aeva/mollytime: virtual synthesizer

virtual synthesizer. Contribute to Aeva/mollytime development by creating an account on GitHub.

GitHub

@GDCPresoReviews @dotstdy yup!

@GDCPresoReviews @dotstdy i've been tagging stuff i've made with it with the "mollytime" hash tag if you're curious. there's a mix of recordings of experiments and videos of the tool

@aeva @dotstdy

👀

@GDCPresoReviews @dotstdy i'm particularly pleased with how this one turned out https://mastodon.gamedev.place/@aeva/116446807281441055

@GDCPresoReviews what I am reading is JS framework bad :3

Having their own in house framework or set of widget could for exemple solve the color picker issue (at the cost of ~3 month of dev I would say)

The us vs them issue is bad. It's good to know it's a big risk and would probably require hiring like an internal community manager. Which would probbaly erase all the benefit from JS dev cheaper

@gkrnours Creating an in-house framework easily removes any cost benefit of hiring JS developers instead of C++ ones. It isn’t an easy task (as proved by the vast amount of already existing frameworks) and it would rapidly take the majority of the development time, which is then removed from what it’s important: the actual tools.

It is easy enough to reimplement a single component like the colour picker, but if you then multiply those 3 months for every similar component you easily get years spent in non-productive development. And creating a performant web-framework is probably not something the average JS web developer would be able to accomplish easily (BTW this is not bashing against JS devs, I think the same would be true for a C++ developers trying to create a Qt clone). So, at that point, you also probably need to hire experienced developers, probably coming from much higher paying jobs.

@antopatriarca an ad-hoc framework would be a by-product of sticking to a set of best-practices decided by a team. That's also kind of required to make all widgets made by the team reusable.
I would stay away from modern framework because most are made for single page application and IMO that's an anti-pattern. Each feature should be its own page, providing an UI that can be normalized as a form to be handled by a backend. SPA are MVC with two controller or expose the data which I don't like

@gkrnours I certainly agree you should organically grow the framework instead of designing it as a separate project and probably take different design decisions, but it still seems a substantial amount of effort for a limited gain. You still need to create a lot of UI components, find a way to reuse the game engine renderer, write strong design guidelines and enforce them, … just to be able to use JS in a browser. You are still going to fight against the browser updates and plugins, fight against the dev tools lagging behind browser support, fight against the browser caching libraries you want to update, have teams with very different background and priorities… Not all the problems listed were caused by Node.js. In fact, not using a framework also removes some of the advantages of web tools as you now have a much more limited amount of libraries and components already available, the developers are not going to be familiar with your codebase and guidelines, …

@antopatriarca I do agree with some of theses points, that's why I didn't talk about theses. No need to put them into my face like you are trying to smurf me with a pillow.

The many framework was specifically called out as an issue as it prevent code reuse.
Writing and enforcing guidelines is called working with other devs. Creating UI components it's like half of what frontend devs do.

anyway, I won't barge into anyone desk and ask them to do tooling in web tech.

@gkrnours I’m sorry if I appeared that rude, English is not my native language. My only point was that the frameworks were only part of the issue they discovered and by removing them they would have increased the development cost and time, basically losing many of their perceived advantages on using web tools in the first place.

But I think we sort of misunderstood each other a bit. I do agree with you in general for web development. I was mostly speaking about the specific case described in the video (which was IMHO mostly caused by wrong expectations/lack of good development practices and less by actual limitations of the web tools themselves).

@antopatriarca And I disagree. IMO, current framework like vue.js, react or angular are anti-pattern costing time for little benefit.

@gkrnours You probably have more experience than me on this as I mostly developed in C++.
The main reason I am convinced it would have been a waste in this specific case is that, particularly at the beginning, they admitted they have very little experience on web development, wrong expectations and little care about following good practices (which ended up with them using three different frameworks in the same application and completely unreusable components). I have also seen colleagues trying to write their own framework producing something similar but worse than react, angular..

Said that, I personally hated working with React and argued in the past it was the worst UI system I ever used.