We were talking specifically about JavaScript performance. It doesn't sound like you were talking specifically about that, so that's bringing in a whole other set of discussion topics.

I'm happy to benchmark performance issues, and usually the engine does have very good performance. If you're referring to performance problems, I'm not sure exactly what you're referring to - there could be all sorts of different things going on, ranging from GPU selection for dual-GPU systems (something I'm hoping to address in the next release cycle), graphics driver issues that are (surprisingly common) system problems rather than anything to do with Construct or browser engines, or actual issues with the Construct engine. It's helpful if you can be more specific, and file issues following the guidelines so we can properly investigate.

No software is perfect, and all software has its bugs and issues. The number of open issues isn't necessarily a perfect measurement, but given that we currently have 53 open issues, GameMaker have nearly 5000, and Godot has over 12000, then I wouldn't say it's necessarily the case that everything is going so much smoother for everyone else.

This is really going quite off-topic for this thread though, which is something we address in our Forum & Community guidelines - it's probably best to start new threads to branch off new discussion topics, rather than chucking everything in to one thread that was originally about the addon system, which tends to get pretty confusing and aimless.

I've explained how there are two paths: the industry-standard API approach, or things end in disaster. Here it sounds to me like you are arguing in favour of the way that ends in disaster. I'm afraid this type of thing is just very worrying to me: it represents a risk to our business, reputation, and customers. The fact you've already written code for your editor UI system using the unsupported approach - especially open source code that is beyond your control, allowing any other developer to pick it up and use it - indicates to me that you are still using the approach that ends in disaster. If you wish to propose a feature or prototype something, don't do it by using unsupported features - you can always write up a feature proposal, prototype things using supported features only if possible, or otherwise prototype them in a separate development project, or basically anything else at all except that. The very existence of code using unsupported features, particularly open source code, already poses a risk to us. This is a tough thing to say because addon developers do a great deal of good work for Construct and the ecosystem, and I believe the vast majority of addon developers are acting in good faith, but I'm afraid there is already a risk of a serious disaster from the work you've already done on the editor UI system. The prevalence of SDKv1 addons using unsupported features posed a similar risk, and we felt obliged to mitigate that, and I feel similarly obliged to mitigate the risk here. One of the ways I am trying to mitigate it is by as strongly as possible discouraging anyone from using the approach that ends in disaster.

Unfortunately having good intentions, or even accepting lower standards of reliability, does not change the situation: as I explained, it's us and our customers who suffer the disasters, and our reputation that is hit, while sometimes the addon developer responsible isn't even aware of what happened. Regular users expect stuff to just work, and it's our job to ensure that's the case. I would assert that it is also the job of addon developers to help ensure that's the case, and the way they do that is to stick to only the supported features. Encapsulation means that good practices are enforced rather than just hoped for. We know from SDKv1 merely hoping people do the right thing does not prevent disaster.

Using unsupported features may be fun, creative, helped some people to learn development, or whatever. I'm afraid that doesn't change things: it is not a professional way to develop software and the concept of encapsulation was invented to prevent it, because it inevitably ends in disaster. I care about software quality and ensuring paying customers have a good experience. If addons risk that for customers, I believe it's our job to fix that and do better for our customers. If other software sucks and constantly breaks things, then I aspire to do better with Construct. You can open Construct 2 projects that are well over a decade old and for the most part they should still open and run just fine in Construct 3. That's the kind of compatibility we aspire to (and was impossible to provide with SDKv1, but can now be provided with SDKv2). We don't have a perfect track record on that: there is a tension between making improvements that require breaking changes, or keeping backwards compatibility forever and the software ossifying and being surpassed by competitors. When we make breaking changes we carefully plan them and do what we can to mitigate the damage, including things like long phase-out periods with notifications. However where addons use unsupported features, it is impossible to plan for changes: breakage happens suddenly, unpredictably, and without any documentation or support, so the damage is much worse. Then lots of people blame us anyway, our reputation suffers, and a bunch of people go away thinking the staff at Scirra are both incompetent and irresponsible. If you are asking us to just put up with that so addon developers can have fun playing with internal unsupported parts of Construct, I'm afraid that's just too much to ask.

For what it's worth, if we did an SDKv3 with editor encapsulation, I believe we could do it preserving backwards compatibility for addons that only use the supported and documented APIs. We should not have to change the APIs themselves like we did with SDKv2. So - like any responsible addon developer should already do - stick to only the supported and documented features, and you'll probably be fine. If you ignore this advice and use unsupported features, most likely only those addons risk breakage with an SDKv3 - and that should not actually be surprising, as such addons risk breakage at any time anyway. So if you use unsupported features and accept it can break permanently at any time, presumably you can just consider new encapsulation features as just another possible cause of that. So perhaps that's fine then?

What we want to do is develop reliable software that doesn't constantly break. Hopefully we can all agree that is a reasonable goal.

When you allow third-party addons, that goal becomes a lot more difficult. If addons access internal code, it will sooner or later break, since software products are constantly evolving and sooner or later the internal code is changed. This means some future update to the product breaks things. The impact of this ranges from a mere inconvenience to a complete catastrophe with thousands of customers complaining and thousands of projects broken.

The way the industry solves this is with two key principles:

1. Provide a stable, public, documented API that developers can use. This allows substantial internal changes - even complete rewrites - while preserving compatibility so long as the public API still works the same.
2. Use encapsulation to enforce that only the public API can be used. This prevents developers succumbing to the temptation to access internal details anyway, and still cause all the problems that the API was meant to avoid.

This is all basic stuff in the software industry and it isn't remotely controversial. Go and use any other product with an addon system and you'll find it probably works the same, for the same reasons.

With SDKv1 we were failing in our goal to make reliable software that doesn't constantly break. Therefore we moved to SDKv2 which uses the above two key principles, like the rest of the industry uses. I fully understand this is a painful transition, and it is not something we did lightly, but it is absolutely necessary in order to achieve the goal of making reliable software that doesn't constantly break. This also benefits addons! If you also want your addon to be reliable and not constantly break, it needs to follow the above two principles as well.

I suspect perhaps some developers got interested in the ability to access internal details, and thought it was cool or useful. However that was only possible due to the historic weakness of JavaScript encapsulation, and if you do that, you will end up with unreliable software that constantly breaks. I am not sure everyone understands that point - some people seem to think they can just deal with it. That is misguided: it is a very real possibility that such addons permanently break at any time. Some people seem so convinced this is not true that they resort to being abusive to staff, which is unacceptable. People may disagree but they must abide by the Forum & Community guidelines. However I must point out that disagreeing is going against decades of industry-standard practice and consensus.

If you wish to develop quality software and build addons that are reliable and work in the long term, it is also in your interest to use these principles. I don't know why any responsible addon developer would want to make an addon that they cannot guarantee to users will keep working and risks permanently breaking at any time.

So far I've mostly just re-iterated the situation with SDKv1 to SDKv2, which mostly pertained to the runtime. This brings us to the editor and the prospect of SDKv3.

The editor is not designed to have UI extensions. The entire DOM - all HTML, CSS, event handlers and so on - are considered internal details. They could change at any time, and that could break any addons integrating them. This brings us back to pretty much the same situation as SDKv1. Not only could such addons break the editor at any time - with the prospect of editor crashes on startup being particularly worrying - but we could also break your addon at any time, quite possibly permanently, and we won't provide support in that situation. Exacerbating the problem, we cannot actually just wash our hands of it and leave the addon up to you, because when things break, everyone comes and blames us and tells us to put back whatever we broke. Some people simply refuse to accept the fact it's not our responsibility, and forcefully insist that we fix it. This is a nightmare scenario for us, and we've had it with SDKv1.

So I have to ask: do you intend to build reliable software that keeps working? If you do, you won't do this, because you can't guarantee to your users that it will keep working! In order to provide that guarantee, we need the above two principles: a stable, public, documented API, and encapsulation to enforce it. Neither exists for the editor DOM. We could in theory do this. However it is a great deal of work with its own maintenance complications, some of which I addressed in this post. So the next best thing is to at least use encapsulation to enforce that editor addons can only do supported things - hence the prospect of SDKv3.

I am well aware of all the criticism aimed at us over both the move to SDKv2 and the prospect of SDKv3. However our goal is and always has been to make reliable software that doesn't constantly break. If we are to achieve this goal, the above two principles are essential. It does not matter how much people criticize us or how much other developers disagree about these points: this is unequivocally what it takes to develop reliable software that doesn't constantly break. I think some people perceive this as being overly controlling, but let me remind you this is how the rest of the industry operates.

You might then ask: how are you meant to achieve this then? The answer I'm afraid is simply that you don't do that. It's not supported. Move on and invest your time and effort in something that is supported and will continue to work in the long term. Find some other way to solve the problem. For example instead of trying to integrate some tool directly in the editor, make it an external tool, and provide some way to import/export your work. I've seen some experiments with making a 3D editor that operate on that principle, and it is a good approach. You can do anything - absolutely anything at all - providing you stick to the public, documented, supported API features. There is plenty of scope to be creative and come up with cool and innovative features that abide by that. There is also scope to extend the supported editor APIs to better allow integrating with external tools, such as the existing Custom Importer API which was designed for importing work from external animation tools like Spriter. We can always do more in that direction, especially where they are thoughtfully designed relatively small but flexible features. Perhaps one less-bad option would be a supported option to open a popup window which can then show custom HTML and CSS content, and communicates with the editor via postMessage() - at least then the custom stuff is sandboxed within a separate window, it's still relatively flexible, and it's still a long way short of full editor DOM modification.

If you disregard this and make addons that break the editor, then I will again feel that we are failing in our goal of making reliable software that doesn't constantly break. Therefore I will feel obliged to act on behalf of us and our customers to improve the situation such that we have reliable software that doesn't constantly break. That is why I would consider SDKv3 to enforce encapsulation for editor scripts too, even though it may be another painful transition. It's simply what is necessary to achieve our goal.

I want to finish with an appeal for co-operation. Please consider everything I've written, and do what you can to work with us. If you ignore this and work against us, using unsupported features and ending up with things breaking, we will feel obliged to take steps to mitigate the problems caused, such as by enforcing encapsulation. If you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.