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 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.

@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.