Hello community. You probably noticed
that we are already working on the improvement of our
client extensibility model, also we start thinking
about or server extensibility model too. One of the
interesting discussion around commiters we have is
how IDE should behave if the extension has been changed
during the development of this extension or number of extension has been changed.
In other words, you enable or disable it.
There are two schools.
Classic. All known to me browser-based(not browser probably too) IDEs: IDE reloaded.
Profits: Simple extension lifecycle. No need to know
how to restore the state of IDE in case of deactivating it.
Since it simple, less probability of to make a bug.
Cons: Depend on the number of plugins and architectural decision it can be slower than the second one.
Usage: In regular development, this cycle will happen only once at the start of IDE. So I would say this is the most used scenario. Like 99.999999% of extensions real life.
Alternative: in case of deactivation plugin restore what he changed in IDE,
in case of changing, it changes only affected part.
Profits: In some cases, it can be faster.
Cons: More complex API, no 100% guarantee that in all cases
a developer will make proper changes to restore a state of IDE and
this can cause that IDE became unusable and to restore it has to be reloaded.
Usage: only for heavy extension development. Or maybe then you experimenting this set of plugin. A very rare scenario on the real life of plugging. Honestly, with IntelliJ-like experience, I forget the last time I've installed a new plugin.
What do the most of developers think:
we should go in the class school path at the same time
we should follow best practices that provided by tools like npm and angular
when your changes in the source would be visible without any interaction. You just need to setup the toolset once.
Why:
1. Simpler API means easy and faster to start doing something.
2. Less error-prone.
3. Time spend on thinking what should be done more in the alternative path can spend on development experience and more reach api.
4. The first path doesn't mean that second path is not possible in future.
Thoughts.
