I’ve occasionally seen mentions of wanting to remove gui from Defold in favor of pure go. It would be helpful to see a list of reasons behind this change since it would be so impactful. Is this something that is planned to happen, for example, in the next year? Two years? Five?
My concern is that once gui is removed, all of the relevant extensions like Druid and many others will be rendered useless. This would of course also not be backwards compatible with current Defold projects.
Good question and valid concerns. We’re in the discussion and planning stage and pretty far from starting this work. @AGulev answered a similar question as yours in Russian for the Russian community a week ago. We’ll go through the discussion and his answers and share a translated version here soon.
Disclaimer: Everything I’m saying here has not been approved and is under discussion. There is no deadline, no design document, and no exact dates/plans for now. Take this as a view of the problem, which can be solved this way, that way, or maybe it doesn’t need to be solved because it’s not a problem. I hope that’s clear.
TLDR:
More on the subject:
We have a “sprite world” and a pretty optimized GUI system. If you think about the GUI - it’s another world in one separate component. It has much worse decomposition than GOs and components. You can see that each type of node is kind of like a GO with a bunch of pre-installed components, you can’t delete or add more. Under the hood, it’s about the same, a pretty big structure that represents a node.
It wasn’t always like this. In the beginning, it was all compact and logical. But then, as it happens, users asked for features. For example, adding particles in the GUI (for those who don’t remember or don’t know, particles weren’t in the GUI, and in Bring Me Cakes, I solved it with predicates). Also, there were other additions like Spine etc.
In short, everything came to the point where users want more features in the GUI: 3D objects, Rive, etc.
But the GUI was not designed for that, and all these additions make it a Frankenstein monster, which is hard to support. It’s important that under the hood, there is quite a lot of code duplication.
But it’s not the end of the story. The features from the GUI began to be requested in the “sprite world,” which is also logical. 9-slice on sprites, it would be nice to have masks, and so on.
But here’s the problem: we are a small team, which even with infinite resources (which we do not have) does not want to grow very much. Support and development of two parallel “worlds” takes a lot of effort and time from the organizational point of view, and from the technical point of view, it doesn’t look great either.
The decision is obvious: “only one must remain.” But logic suggests that the decomposition to components is a better approach than a Frankenstein monster, where everything is added to the pile.
Since we have decided on the solution, now we need action points. The most important things are:
gui.pick_node analog (could be a method for a camera or something else)I want to stress that points 2 and 3 are just preliminary ideas that came to mind. We still need to have more in-depth discussions on the matter. However, what we have already discussed is that we have received many feature requests that would make the “sprite world” function better. We will work to implement these requests thoughtfully.
No worries. It will not happen as a single-step action. It will take some time and we really far away from that goal.
We understand that a lot of our developers use GUI heavily (we also use it) so we will do our best to make the transition as smooth as possible.
But again it will happen in the yet-unplanned future. It’s not something you have to care about right now and decline using GUI because of it.
offtopic: now I’m eager to see your projects! =) I hope you’ll find time to share it here on the forum in the showcase section.
Me too! @idk it would be really nice to hear about both your own projects, and if your client also allows it, about the contracted project you are working on.
I want to repeat what Alexey has already written and also say that this is not a change that will happen over night. It will be a long process, one which we will take in steps, and hopefully also where we can have tools to automatically migrate projects.
I feel this transition was inevitable, and I’ll welcome it when it happens.
Of course the concerns are all extremely valid but considering the history of the engine I believe it will be handled with minimal disruption.
I particularly like the idea of having gui migrated to an extension so that older projects will have time to migrate when necessary.
Looking forward to this.
While I sympathize with you @idk, please keep the off topic to a minimum to respect the OP’s topic. You’re very welcome to chat in the discord channel 
one thing that is great about GUI is that you can disable automatic adjusting. as far as i’m aware, this is not an option for sprites and tilemaps. i much prefer being able to manually adjust things top better fit the aspect ratio of the screen than to stretch it all to fit.
that and dynamic texture loading is far easier in GUI than with sprites.
GUIs are also always drawn on top on the screen, which would be hard to implement with GOs, especially considering the engine is 3D capable, which further complicates the process of ensuring that the GO isn’t behind or Z-fighting something
another thing to consider about ridding of GUI is the perspective of a new developer trying to learn the engine. the big engines have gui tools, so the lack of that would be jarring and maybe even discouraging to someone trying out the engine for the first time
Users usedd to Defold, knowing a little bit the under the hood workings of GUI notice a lot of duplicates. I was thinking about it, when you added 9-slice support for sprites. And I understand now, that GUI is out of the rest of the components - has to have separate GUI script, separate API, while actual GUI can be done easily with just predicates drawn on simple orthographic projection on top of viewport and we could make buttons with 9-slice feature easily. (Silly enough, Gdevelop comes with different “object” for sprites with 9-patch, they call “Panel” Panel Sprite ("9 patch") object [GDevelop wiki])
But getting to this point demands rendering knowledge, which new users might not come with.
New users might be very frustrated, because with such change a lot of materials, tutorials, videos will be also outdated, not only assets.
On the contrary the whole Defold system would be simplified and easier to comprehend, because of less APIs and unchained possibilities.
So, when forcing people to use Sprites (mainly, but also all other things, like particles, 3D models) in GUI - every documentation, tutorials and manuals needs to be updated to convey this new system. Easy as it is - the default render script would not need much changes I think.
Removing GUI for me means new Defold major version.
EDIT: From here on, I touched too many strings 
If we are in the situation, when major version would be increased, it would be great, if it would come also with changes in rendering and eventually physics systems.
I believe it would be a great move to simplify “systems”, but it would be also a greater (and more important) move to simplify “user experience” and usage of those systems (which is on contrary a more effort being put on Editor)
// panic mode off
Imagine someone saying that in 20 years we’ll stop using oil for car fuel. All cars will stop working, etc. As with any existing technology the transition is not happening overnight.