RFC: Make load of GUI out of the proposal scope

[vitaliy-bobrov]

Currently, the proposal includes the load mechanism for GUI of a plugin built-in, however this might be not the best solution because:

• Restricts to use specific way of building GUI
• Restricts plugin GUI API
• Hard to involve custom build / packaging process
• Rely on "dead" standard of HTML imports (https://caniuse.com/#feat=imports)

I think if any WAP has a GUI it could be just described with the package link, so app the want to use plugin with GUI just loads web component bundle (just JS file, how WC are distributed right now) or include it during the app build process. The only thing that should be provided by SDK is an interface (HTMLElement extension) which get the ability to get WAP instance.

[micbuffa]

For the SDK V2 we will rely on ES modules for sure. HTML imports are dead, I had to include a polyfill for html imports in all examples. I did not have time recently to work on this, but it needs to be done one day or another. In our first version we had in mind to stay as simple as possible while having the possibility to use any plugin with or without its GUI. Using external libs/frameworks proved to be a very complicated problem when used in hosts that we do not control (i.e ampedstudio), we could not use a lib that the host is already using with another version of the lib/framework. We cannot compile with the host source code etc. This is why we decided to stay simple. How would you handle this. Bundling libs in a minified single js code will not solve the problem of dynamic loading in hosts + lib compatibility/conflicts/multiple loadings of the same lib/module...

[jariseon]

any info on the current state of https://chromestatus.com/features/4854408103854080 ?

[micbuffa]

No Jari, no news....