defold
New Editor 3.0
Task (REQUIRED): Develop a new editor from the ground up based on a more approachable GUI toolkit.
Expected outcome (REQUIRED): New editor is available.
The current editor based on Clojure is often the main cause of discomfort using Defold. While the engine itself is lean and fast, the editor feels very slow and unresponsive. Newcomers often dislike the engine based solely on the editor experience.
The code editor is also far from specialized editors like VS Code or Sublime.
However the main reason to consider building a new editor in my opinion is to go away from Clojure. Clojure is very hard to get into. It's a huge barrier for others to contribute to the editor and to improve it by the community.
Since Defold 2.0 there has been a number of new cross platform GUI toolkits. One of the most promising being Avalonia - https://avaloniaui.net It's open-source, good looking, based on .NET and already has a great community.
Here is an example of an IDE built with Avalonia - https://github.com/VitalElement/AvalonStudio
A few other options: Flutter https://flutter.dev, Fyne https://fyne.io, Ultra App Kit https://www.ultraengine.com/appkit
IMO if a new editor is done it should be done as a community project with an open license, made parallel to the Editor 2. Use bob.jar directly for bundling / building and if it can't be bundled with Editor 3 have it be able to easily be downloaded by the user.
@subsoap that's a valid point. Becoming fully open source at least as far as the editor goes. There is a difference between bob.jar and Editor 2.0, editor can smartly cache stuff decreasing the build times, I wonder if it's possible to integrate it into bob as well.
There are several issues outlined here, I'll try to respond to each one
"The editor feels very slow and unresponsive"
As usual, step one is to pinpoint what the problem is. I.e. what makes the editor slow? I don't suspect Clojure/JavaFX to be the culprit here, but something else. Most likely something we do inside the editor. And, if we do something strange, we can perhaps fix it. Remember, it's more than likely that the issue would persist if we rewrote our code within a new editor.
Not easy to contribute to editor source code
Clojure
However the main reason to consider building a new editor in my opinion is to go away from Clojure. Clojure is very hard to get into. It's a huge barrier for others to contribute to the editor and to improve it by the community.
Most of us agree that the choice of Clojure as the editor wasn't the best choice in hindsight. Back then, we had "infinite" resources, and no prospect of receiving source contributions.
Smaller fixes
For smaller fixes, I'm sure you can look at the existing code and apply similar changes to get the desired result. But yes, we agree the unfamiliarity is a problem, and we lose a lot of smaller contributions due to this.
Complex features
E.g. what are the types of contributions you'd like to make? You haven't specified anything so it's hard to guess at.
I believe step one is to ask us: "I'd like to improve on this thing/system", and we could hopefully guide the person towards getting started on it. I too consider it a bit of a problem that people just turn away at the sight of Clojure.
For larger fixes, they're most likely going to be more complex, as there are a lot of things going on, that needs to be kept in mind. So I'd assume the contributor would need to approach us anyways with questions. Currently, we receive almost no questions/contributions regarding complex features (for either engine or editor).
Background/Example
The "editor" consists of 3 parts: the gui (JavaFX), the "graph" (Clojure) and the build pipline (Clojure/Java).
When diving into the editor code, you will need to understand Clojure for sure, but that's only part of it. You'll also need to understand our graph system and how it works. It is the backbone of the editor code. Also, it ties into the content pipeline, and you'll also need an understanding of the engine code and its philosophy.
For instance, I've been moving the Spine extension from the engine into an extension this past year, and in order to do that, I've had to write a lot of Clojure code. But, I think most of the time has been spent on understanding our graph system, that connects all properties together. I am a Clojure beginner, and if I can do it, so can other programmers.
Even if it was written in Java/C# or something else, I'd still think that the number of more "complex" pull requests would be very small. So, from our perspective, I don't think it would be time well spent.
What we can hopefully do in the future, is focus more on guides on how to do changes in the editor/pipeline.
Time estimate?
In short, I think writing an Editor 3.0 will take way too much time. We had 4 people writing the Editor 2 for 3 years (more?) (albeit also doing research and development of the graph system).
We simply don't have the team size, the time, the money to rewrite it. And, even if we did, I'm still not sure we'd want to. I've been part of too many rewrites, and they've always taken too long, and they always missed crucial features. (Maybe we were just unlucky those times, but I don't think so). And, it's not certain the end result will be better.
As suggested by @subsoap, I would see such an endeavourbeing taken by our community, and asking us for insight in how all the parts tie together.
Editor scripts
Personally, I'd much rather focus on moving the build the remaining pipeline out of the editor, in favor of the one in bob.jar. And also spending our time adding more features to Defold itself. And adding more guides on how to extend the editor. E.g. a major feature that we have barely started working on is the editor scripts. The plan (all along) was to allow users to customize the editor using Lua. That way you wouldn't need to touch a single line of Clojure.
Replace the GUI
Develop a new editor from the ground up based on a more approachable GUI toolkit.
I'm not sure what makes JavaFX unapprocachable? But perhaps you mean that we use it via Clojure?
Since Defold 2.0 there has been a number of new cross platform GUI toolkits
All gui frameworks have their quirks, and programmers often try to fix it, thus coming up with a new framework, with its own quirks. Although I would consider the GUI part of our application to be the smaller part, and perhaps someone could replace it if they really set their mind to it. It's not something we'll be looking into though.
Code editor is lacking features
The code editor is also far from specialized editors like VS Code or Sublime.
Please add suggestions/tickets for the code editor itself. I think it will be faster than rewriting the entire editor.
Bob + caching
...wonder if it's possible to integrate it into bob as well.
Bob caches content too. And, we also recently added support for a local/remote cache storage (user defined), for even more reuse.
I think writing an Editor 3.0 will take way too much time. We had 4 people writing the Editor 2 for 3 years (more?) (albeit also doing research and development of the graph system).
I agree. It's a huge undertaking. The AvalonStudio editor provided as an example by @Lerg was started in 2016 and is still in active development. I don't know anything about that editor and maybe a functional product was created quickly, but I doubt it.
The "editor" consists of 3 parts: the gui (JavaFX), the "graph" (Clojure) and the build pipline (Clojure/Java)
What we can possibly do in 2022 is to iteratively and gradually move non-graph related code to Java to make the UI and build pipeline related parts of the editor more approachable to new contributors.
Clojure is still cool and beautiful. I wonder if recruiting volunteer contributors from within the Clojure community could work out. Maybe instead of a game jam in the future do an editor jam targeted at Clojure coders.
Regarding the big & slow-ness:
- The editor is ~390 MB. To me that is pretty darn big for a program with the amount of features that the editor has (visible to me). VS Code is only ~80 MB. Tiled is only ~25 MB.
- The editor is slow to start. For me it takes 7-8 seconds to get to the open-project screen. The fact that there is time to show a splash screen at all seems like a problem. Blender takes about 2 seconds to fully start up (and that's less than ideal of course).
- The viewport is slow when there's a lot of objects/nodes. I recently made a level-editor with Defold. The main UI has quite a few buttons & things, with around 300-500 nodes total. When editing that GUI in Editor 2, the viewport is quite slow. Panning the view, box-selecting, dragging nodes, etc., all lag well behind the mouse. In contrast, the level editor that I made with Defold can handle a few thousand sprites plus all that GUI with no sign of effort.
- Opening a game.project file in the editor usually takes about 1 second. I believe this started when the "Jump to..." and "Filter" features were added (but I've been too lazy/forgetful to report it).
- Testing it now, I think there is generally quite a bit of mouse lag in the Defold editor. Just dragging a panel divider back and forth is slow, compared to the same thing in Atom or a GUI I made in Love2D. When you open a file (like game.project) it becomes even slower.
- Search the forum for "editor slow"...there's a lot of threads. Yes, they generally have quite old hardware, but this still points to the fact that the editor is not lightweight.
It's not anyone's responsibility to educate me, but I feel like I'm missing some perspective on what the editor does that is so large—in disk space, runtime CPU/GPU cost, and development time. Why did it take 12 man-years? How much of that was beaurocracy? I'm sure I'm a megalomaniac, but I feel like if you locked me in a room for 6 months I could have something pretty workable.
I've also often thought that the editor needed to be rewritten from scratch. Because of all the issues I listed, I've assumed there's something fundamental about it that is a problem. I mean, can you cut it down from ~400MB to, say, 50MB? Without a rewrite? Could you cut the update CPU time down from what feels like > 16.6ms to 5ms or so? Can you cut the startup time down to < 1 second?
I don't mean to bad-mouth anyone's efforts. As it is, the Defold editor is way better (including faster) than Unity's in a lot of ways. This is just my perspective on it.
- The editor is ~390 MB can you cut it down from ~400MB to, say, 50MB?
Remember that this includes a full set of build tools and precompiled engines for each supported platform (ie bob.jar). It does only account for a little less than half of the size though. There's also a stripped down version of OpenJDK 11 included. We could exclude both of these and require the user to download bob and install Java.
BUT I agree that the size of the download is a little bit of a problem and believe there are some things we can do to reduce the size. I'll make a note to investigate this.
Thanks for listing the issues @rgrams! I'll try to answer best I can.
Disc size
(Remember, .jar files are just zip files, so you can unpack them and look inside!)
As @britzl mentioned, we include a lot of prebuilt engines in the build. We can ofc streamline the prebuilt binaries into separate platform packages, but I think that also has other issues in terms of accessibility. We want it to be easy to use "as-is". I did notice that we bundle shared libraries (for the editor) for the other desktop platforms, inside the editor, and that is something that should be a bit more straightforward to look into. I'll create an issue for that. Perhaps the community can help.
As for the rest of the size, it's mostly java classes that take up the space. For sure, Java is a pretty verbose language, and writing it in another language would likely bring the size down quite a bit. However, when writing the Editor 2, we already had an Editor 1 and Bob written in Java, so it was a good fit to use something that could interop well with our existing Java source code.
We certainly don't want the download sizes to grow, we have the same philosophy there as in the engine, to keep things small. However, we have prioritized other issues in our engine.
I do wonder how many users turn away from choosing Defold because the download is ~ 390mb?
Slowness
I agree that opening the "game.project" is very slow, and I once got an explanation why, but I can't remember it. It's for sure not a good user experience, I'd like it to be fixed some day.
As for almost any "slow" issue, it's rarely due to the language of choice, but how we use it. The editor keeps a separate version of the game in memory, and it renders differently. (think more like one draw call per object, rather than the engine's batched draw call). The editor prioritizes other things than what the engine does, because we need to change the data a lot. In the engine, the data doesn't change at all.
As for the slowness of the rendering (or anything really) it needs to be looked at on a case by case basis. Sometimes, a thing might work really well from the start, since the developer remembered to think about it in the design/implementation process. Sometimes you didn't think of it, or didn't think it would become an issue. As always, we should list the biggest issues, and sort them by priority.
And I agree that the startup times are annoying, perhaps we can create a ticket for that as well? E..g does the github interaction (the tutorials/samples checks) play into that time?
Dev time
It's not anyone's responsibility to educate me, but I feel like I'm missing some perspective on what the editor does that is so large—in disk space, runtime CPU/GPU cost, and development time. Why did it take 12 man-years? How much of that was beaurocracy?
The time was spent on development. A lot of it was due to the development of the technology (the "graph") behind it. Some time was spent on implementing the content pipeline in the editor (it was going to be a replacement for bob.jar). The "graph" system is basically the data model, that keeps all the data and properties in sync at all times. Now that the development is done, one might look at the existing implementation, and use that as design to copy for a "next editor" and it should save you lots of time. Still, rewriting something this big is not something to be taken lightly, it will still take up a lot of time.
Summary
In the end I just want to emphasize that we have a product that is working, and I'd much rather try to fix the issues with it than try to rewrite everything.
It's notable that for issues (e.g. performance) in the engine, no one has suggested we rewrite the engine (and in "some language"). But instead, we create an ticket, and a discussion is had about it.
Hey, I've made a follow up video explaining and demonstrating some issues. Please watch https://www.youtube.com/watch?v=2lmJSXpAOu4
TLDR;
- Make it easier to contribute the editor by adding kotlin + javafx.
- Use an external editor (eg vs code) and consider support ts-defold (by expose lua debug signal or something like that to make it possible to debug ts-defold).
- Consider reducing the total RAM consumption.
- Is there a way to extend our editor (by support plugins)?
- Try to make the editor lean as Defold does.
Hello everybody! Firstly, Thanks to all Defold team and contributors for making a great game engine!
// I am a newbie in the Defold game engine and I come from kotlin (android) side.
@Lerg I think instead of re-write a new editor we can consider improving the current workflow to develop the editor.
As I read the docs from this repo, the editor is written in Closure and using JavaFX. So is it possible to add Kotlin for develop the editor? Since kotlin interop with java very well. I don't know if it is possible to make kotlin interop with Closure.
Also here is something that could improvement:
- I love static typing and I think many people love it too. So as a beginner, when using Lua for scripting, I often press "ctrl + space" for autosuggestion. But because Lua is dynamic, so nothing can suggest. Then I read some thread in the forum, I found that there are two options: one is HaxeDefold and another is ts-defold.
I tried ts-defold and it is works smoothly (for me). So I think for the code editor, we should consider using vs-code + typescript as another official way for scripting Defold. (Then our task is to make it debuggable in vs-code).
- For big memory consumption problem: My computer has 16GB of RAM. When I start using the Defold which will consume about 1 -2GB of ram. But after usage with some basic add sprite sheet for animation, the memory consume up to 5GB and keeps it until I close the Defold program. I see in the FAQ that Defold will use up to 75% of available RAM. Is that intentional?
Update I found that is good enough for autocomplete: https://github.com/astrochili/defold-vscode-guide
Then our task is to make it debuggable in vs-code
The TypeScript you mean? I believe this works already, right @thejustinwalsh ?
So is it possible to add Kotlin for develop the editor? Since kotlin interop with java very well. I don't know if it is possible to make kotlin interop with Closure.
I don't see us adding yet another language. I would much rather see some of the Clojure code move to Java, since Java does interop with Clojure really well, and it is already used for a small portion of the editor code.
Then our task is to make it debuggable in vs-code
The TypeScript you mean? I believe this works already, right @thejustinwalsh ?
I am having success debugging both lua and TypeScript with sourcemaps (TS-DEFOLD / TSTL) using the Local Lua Debuger vs code extension. The author has added support for Defold recently, and it should be in the setup guide on the extension page or GitHub. The only caveat is there is not remote debugging support though the author of the extension and I have been throwing around ideas to add that support soon.
Additionally you can use Defold Build Tools to build your project (does not require TS_DEFOLD, works with vanilla lua) and it played very nice with the Local Lua Debugger.
Shower thoughts on the whole matter is that you can progressively enhance the editor experience or supplement it with specialized tooling if needed. I am very much a VS Code first workflow enthusiast, and I often do not need the editor at all for large segments of my work with Defold. I spend a lot of time scripting, building, and running after my initial project setup.
Luckily the Defold team picked a data format ProtoBuff (Text) for their assets that are very easy to serialize, and they have released Bob to the community for packaging, so along the lines of what @subsoap has mentioned, we have the tools we need to build custom editors that more closely align with our individual projects.
I have been contemplating a collection editor for VS Code for instance, for my personal workflow, I would love to be able to pop open a new tab and edit some props and positions then build and run, without needing the editor at all. I can make this very custom and do the things it needs to specifically for my game, workflow, or style. This does not compete with the core editor, and is simply a workflow enhancement that maybe someone else in the community may find useful as well.
Tiled and TileSetter exist as tools that could be better options for tilemaps for instance and lots of folks use those options instead of the built in editor experience. So if you have a specific workflow that needs enhancing, maybe you only need a singular tool for that workflow vs an entire new Editor?
I have had the pleasure of being employed at several game studios that went through the we need a new Editor phase of any reputable studio, and the only thing I have learned from that experience, is everyone thinks the editor needs to work a special way specifically for their home grown workflow. It is impossible to have a perfect editor, and there is always someone at the studio that rolls their own tools to solve the problems your editor set out to solve in the first place.
@britzl @thejustinwalsh Thank you for the answer. I will check it more on the Defold Build Tools extension. Thanks!
Even tough I tend to agree with Sergey's analysis, I also don't think a full rewrite is a good idea. From experience these tend to go on for far too long and they steal resources and time while also generating frustration in the users.
A lot of things fall into either the performance or polishing area. The editor being a ~400mb with everything it has is not that bad. Godot claims to be light and fluffy, but that's only for the editor itself. The moment you need the export templates you're stuck downloading additional 500mb!
To me the major missing point is a more open and complete extension system. Editor scripts are a timid start in that direction. I want to able to use lua not just to call a few scripts or external processes, but to create new panels, modify the proto buffers, interact in the viewport and everything that is needed to complement the need of the game I'm building. That, like the engine extension, would really give the editor a push and room to breathe.
I regret mentioning mentioning the disk size. That is by far the least significant issue. It barely matters.
The real issue (to me) is the large amount of lag in the editor from many basic interactions. Watch Sergey's video.
hey Just a noob Defold user here. I got excited reading about the Editor 3 and stuff, however as a beginner I would rather prefer better project templates (possibly with preconfigured dependencies) and more beginner friendliness overall.
TL; DR I got stuck with something I expected to be a one line of code, but it turned out to be a jigsaw puzzle: google a lot, read docs, try and fail a lot, get an asset library for inputs, read docs, again fail a lot, get example projects, copy-paste some stuff, fail again, try another asset library, try a different renderer. Two days later a supposedly easy problem is still not solved and I would need to dig more and try other things. I still think that Defold is the best for mobile and web! I'm just not smart enough and not familiar with it enough to make it work for me.
I haven't even noticed that the editor takes 7-8 seconds to load, neither did notice any slowness. I have a decent 6 year old laptop though with 32 Gb of RAM.
I believe that with a bunch of small changes it could become much more enjoyable to use, at least, for me personally. In example, to drag and drop things around (drag a "go" into a collection), more keyboard shortcuts. As a software engineer I always notice tedious things that would be easy to automate for users, like, when you need to move a "go" object with their children into a separate file from a collection. I figured that it's enough to create a new .go file and then copy and paste each child there. Those kind of tedious "manual" things are not enjoyable.
I got stuck with something I expected to be a one line of code, but it turned out to be a jigsaw puzzle: google a lot, read docs, try and fail a lot, get an asset library for inputs, read docs, again fail a lot, get example projects, copy-paste some stuff, fail again, try another asset library, try a different renderer. Two days later a supposedly easy problem is still not solved and I would need to dig more and try other things. I still think that Defold is the best for mobile and web! I'm just not smart enough and not familiar with it enough to make it work for me.
I'm curious: what was the problem?
I wanted to register if a game object was clicked. I'm pretty sure with enough time put into it I could make it work, but none of the solutions I read about sounded easy and simple, definitely not KISS. Each one requires a few steps so a total beginner with a little coding experience might be turned off.
I tried a collider that follows the mouse using the input library that you wrote (:+1:). I think that I got it working, but because I had the projection renderer the collider was "falling behind" the further away from the center of the screen it was. I got it, so I moved on. Then I tried the orthographic camera/renderer, but for some reason my circle sprites became ovals, and the Defold logo got stretched too... I haven't looked into that more. Then I wanted to try ray-casting and found the mouse to world coordinates function, after reading about it I realized that it would become so complicated then. I figured I would need to do the following: 1) add the function into the renderer; 2) do msg.post to call it; 3) here i'm not sure, but I guess the renderer then would need to msg.post back the calculation results to my "go"; 4) using the world coordinates ray-cast and check the collision result.
I feel that there should be a simpler way to make such a common use case (mouse click world coordinates, mouse position world coordinates) work with little to no configuration and "manual" set up required. Perhaps, a 2D mobile template that uses the orthographic renderer out of the box that has it ready and working? I plan to write a feature request to discuss more.
I feel that there should be a simpler way to make such a common use case (mouse click world coordinates, mouse position world coordinates) work with little to no configuration and "manual" set up required. Perhaps, a 2D mobile template that uses the orthographic rendered out of the box that has it ready and working? I plan to write a feature request to discuss more.
Yes, providing an example/template would help, but I don't think it will ever work out of the box (what is the size and shape of a game object for instance?). Please create a ticket so that we can discuss this further without derailing this feature request!
As idea for Editor 3.0. Flutter has great plugin for Android Studio with open source. It can run apps on any emulator and web. It can hotreload it and support debuging. Also Android Studio itself has many great features as code editor. Also code suggestion with emmy lua works way better then in Defold Editor. So, probably instead of writing another editor it is better to use Android Studio as base. Any way defold editor does not support rendering custom shaders in editor and even gui looks differently in editor than in editor. So maybe there is no need for it at all for visual editor, only code editor:)
As an amateur gamedev I've recently decided to give defold a try again after using godot for over a year.
I don't by any means want to sound like a godot evangelist but there is one thing I think that they decided to do which has served them quite well and I think if there are ever consideration for a re-write would be worth considering for defold too.
The godot editor being effectively made from godot building blocks.
I've found this to be quite a nice feature of godot as it means that anything that the editor can accomplish is something that I could effectively also implement/use in my application/game.
I've read some of the release notes and changes/requests/bugs that I found and a lot of them seem to often revolve around:
- differences between editor/engine
- the ability to be able to use the editor features in various projects.
Following the philosophy of building the editor using the engine and its APIs/SDKs would mean that:
- any improvements that are done to the editor end up becoming features that are available for use in projects as well.
- the editor itself becomes something you can point to as a example for solving problem X or Y
I appreciate the general sentiment right now is that a re-write isn't planned or in the books but I figured I would add my 2-cents just in case the topic re-surfaces and that I think it would be a worthwhile strategy to consider if it does.
As a software developer my first reaction to seeing features missing from the built-in tilemap editor was to want to write a small project for myself in defold of my own. It was a shame when I realised I couldn't easily read/write the editor resource files in any way. I considered needing to bundle the input resources in and then coming up with a way to save the defold tilemap back but it just all was becoming a fair deal more convoluted than I hoped it would (got a bit spoiled with how easy it was to add custom tools for myself in the godot ecosystem).
I'm planning on trying defold for a small game and do appreciate it for what it is - just figured it was worth sharing my perspective as a consideration for any plans that might unfold.
I have been having a little break from Defold, replicating rendering and such in a framework of my own making, but using my original lua scripts to develop it (mostly pure lua libs without Defold calls - has made it easier). The application development Im doing this for is Flix (see Defold forums for more details), this is a 'kind' of editor with 3D scene editing, asset selection and a number of other features. Moving it to pure lua + a simple backend, has been much simpler than expected, and in a little over 3 weeks I have Flix running at nearly the same level I had it in Defold.
Why this is relevant? I think the tools to make a Defold editor are already there. As others have mentioned, the Defold engine is quite capable of rendering UI's and my initial tests with Flix in Defold shows this. Imho, the missing parts are what I found to be problematic - runtime asset modification and some of those style of features, these are solvable. Other issues I had, was modifying the editor with clojure to suit what I needed. This was a larger task than expected and added a serious dev burden to making something quickly and easily in the editor.
What my recent adventures have shown, is that you could use Lua to do the lot - I think the comment about godot being made from godot components is related to this. However, there is a second part to my story.
While working on expanding Flix to have more interesting features, I remembered I used tiny-ecs and hooked it into Defold using simple server, and I think this is kind of a golden egg right here, and additionally, would minimize impact, development costs and provide high levels of customization and flexibility.
"Stop rambling Dave, wtf are you on about!" - Well. A web based editor. Not web based as-in electron or similar nodejs styled editors. I mean using a non-graphical Defold backend (already available) and serve generated wasm components for use in a locally served (from the defold backend) browser based editor. It generates all the artefacts, it opens in whatever persons favorited browser is, on any platform, and it allows the use of quite modern webgl and JS gui systems that could result in a wide variety of editing tools and interfaces - easily allowing users to customize the editor out-right if they needed.
Ive made a simple one for my Flix app, and I think it is a very simple and capable way forward without all the hangups - you could make one right now without modifying Defold at all.
All this.. is just my thoughts on the matter... there are a bunch of other things that I think could really expand development, but little steps. Imho, an enterprising developer could knock up a basic 3D editor over a weekend, that interacts with Defold, like I described above. If you leverage some of the great free web based 3D editors .. it would even be simpler.
I really, really, really dislike web interfaces for my tools. I have yet to see one that's not clunky, slow, and limited. I love Clojure; it's a fantastic language, but I think the suggestion of adding Kotlin would make contributing easier because there are many Kotlin developers around, and sadly, Clojure is not conventional or known enough.
I really, really, really dislike web interfaces for my tools. I have yet to see one that's not clunky, slow, and limited. I love Clojure; it's a fantastic language, but I think the suggestion of adding Kotlin would make contributing easier because there are many Kotlin developers around, and sadly, Clojure is not conventional or known enough.
I hate to say it but the vast majority of applications for productive work are using some sort of browser based system, from google docs etc, to ms, to vscode (yes thats in an electron render) and so on. The main reason for this, is the platform portability. The odds are, you have and/or are using browser based tools already. Even some of the brilliant 3D editors using ThreeJS, Babylon and others are substantially better than Defolds editors (and more extensible too, of course).
I think Closure is an ok language but not suited to building UI's. Functional languages are good for fixed target modular toolkits. They are not good for extensible and flexible systems that need to cater to a wide variety of systems and toolsets. This is clear seen in the commits to the Defold editor repo. Ive been in game/sim/defense/fintec dev for some 30+ yrs now and I struggled to piece together simple solutions for what I needed in the editor - this should be a cause for concern. If someone with my depth of skills and exp, has problems, then you have a restricted development system - but its not just me btw, its most people who have worked on this.
Changing to Kotlin doesnt solve the core problem. The ability to make an easy to develop and flexible ui. I like to use VSCode as a good example of how to develop a broad base extensible editor. It was made as a research project within MS.. and now it is almost the defacto development tool for most coders, in almost any language - this is a clear sign it is doing alot of things right. And this is why people should understand its tech, its architecture and leverage their knowledge from it. "We all stand on the shoulders of giants" and I personally think Defold would be best served if they took some notes from these other systems that have proven to work well already.
I also, dont believe my opinion really matters all that much. I would like to contribute far more than I do, but I cant invest that sort of time in it (thats the main problem for me). So this is my own experience and opinion. The Defold team will obviously be looking at ways to attract and keep developers using Defold and Im sure they will weigh up how this can be done, and what method will ultimately be most effective - especially since they have the most depth of knowledge of the whole system.
As much as I hate to admit it, I have to say that there are now several web apps that are extremely solid. One of them is probably Rive, which is just a joy to use and scales really well for what it does. Construct 3 is also pretty good, and it's a game engine. The speed at which editor functionality is being pushed out is definitely good. I can't speak for Rive but I know that Construct 3 has very limited development resources, comparable to Defold.
As much as I hate to admit it, I have to say that there are now several web apps that are extremely solid. One of them is probably Rive, which is just a joy to use and scales really well for what it does. Construct 3 is also pretty good, and it's a game engine. The speed at which editor functionality is being pushed out is definitely good. I can't speak for Rive but I know that Construct 3 has very limited development resources, comparable to Defold.
That's the power of a madman on a holy mission. Ashley started Construct in the first place because he was so frustrated with the development of previous gamedev tools. Defold too was started by a madman he should come back to the project!