use web-components for flexibility

[hohwille]

As a user of mmm-ui-tvm, I want widgets to be implemented using web-components so that I can more easily customize their behaviour.

In mmm-ui-* every widget is implemented as its own class that is provided by its own factory. This already makes it flexible to customize things. However, the JPMS and ServiceLoader that is used for this is not as flexible: I can not easily override a single widget factory from a module that already ships it along with many other such factories. In the worst case I would have to copy/fork the entire module just for the sake of adding a small change to a single widget.

Even if the framework would change to allow adding a drop-in replacement for a single widget, I would still have to write my own widget implementation understanding the context of the framework and also have the need to additionally implement my widget factory and register it to the service loader. All this has to go through the TeaVM compiler.
With web-components, I would just copy and adopt a single web-component and then change the "include" in my index.html to my own variant. I do not need any compilation and have faster turn-around-times in dev-cycles.

After all the idea of mmm-ui is that the developers of dialoges only need Java know-how and can do their job very efficiently. However, the job to customize a widget is a job that can be done by a specialist and is much more rare. It is mainly done up-front when the style-guide is implemented. And that job and such speicalists will typically expect to use the bare browser technology (web components build as HTML, CSS, JS) rather than Java coding where they do this in a "fenced environment".

I do not really think the design of web-components is great. Actually it is more a consequent succession of the flawed web-technology (assuming you wanted to design a portable, cross-platform, generic front-end technology to build complex
clients from scratch... you would never end up with HTML and CSS if you had to design this properly). Also we have learned that DOM communication as rather slow but web-components force you to do it. Anyhow, browsers have become so much faster that it seems appropriate to go this way and follow their philosophy rather than tilting at windmills. Also there are still many limitations to overcome with web-components as you can read here:
https://web.dev/more-capable-form-controls/

However, if we can overcome all these issues, we open up for much more flexibility. We also have the option to ship these web-components as an individual repo and modules (e.g. mmm-ui-webcomponent-*) to build multiple competing ui-api implementations for the web (there is also https://github.com/i-net-software/JWebAssembly) while users could easily copy and customize these web-components without forking the entire ui-framework implementation.