When should we make a JsExtension and when should we make an events based one?

[arthuro555]

With events functions extensions becoming more and more powerful, the line between them and the JsExtensions begin to blur. When should we make a JsExtension and when should we make an events based one? Some events based extensions sound so essential that it is weird they are not built in (like the clipboard one) and some seem not important enough to be built in (Firebase extension), and sometimes the sorting is inconsistent (p2p networking is built in, MQTT is events based, but both are essentially the same except they use a different protocol, and to be honest it seems the MQTT based one works better than the WebRTC based in most cases).
I think we should have some clear rules about when to do what, to avoid having a bloated engine or missing important features by default.

Ideally, we could make JsExtensions and events based ones be usable as built in and community extensions, but that would raise some problems (Users expect to be able to edit events of community extension, which isn't really possible for JsExtensions, risks associated with downloading and executing a JsExtension.js file from the internet in an electron environement with node integration...) and would make the code harder to edit as we would have to use different development environments (IDE or GDevelop) depending on what we work on.

[Bouh]

For me an extension in the engine is present in the engine because there is no choice.
All the others should be user extensions.

I had proposed the idea to include some extensions from the community as default extensions, but as long as the user extension is not cross-platform it's annoying to include it in the engine. We can't say that gdevelop is cross-platform but only on certain aspect or event.

I also wonder how interesting it is to inflate the software with extensions that could be made with events.
Because we keep in mind to have the minimum of things in the engine for a "possible" major migration of the software and simply have only what is necessary.

Nobody likes to rewrite existing code to do a migration. What I see is that the user extensions (with events) will always be used in any case because of their generic format that the engine already takes into account.

So I always ask myself what I need before I make a new extension.

[4ian]

Because we keep in mind to have the minimum of things in the engine for a "possible" major migration of the software and simply have only what is necessary.

Yup.

The general school of thoughts is: "If it can be done at a higher level, do it in this higher level.". Higher meaning events is higher level than code (and a bit of JS in an extension is higher level than an extension completely in JS).
This is because it brings portability for the future, ease of change and contributions.

There are a few exceptions:

• The extension is so generic and useful that it should be part of the "core".
• The extension can't be written properly with events and should be made entirely in JS.
• The extension is complex enough to need some testing capabilities that is offered (for now) only in JS extensions part of the codebase.
• Performance, if events are shown to add too much overhead and the extension is performance sensitive.