[madeofpalk]

> #3. UI engine must have natural and effective means to use native code - to be embeddable and extendable by hosting application.

It does! Most browsers are written in "native code" and use it to do layout. When you use an <input /> field on a website, you get a natively rendered UI widget with native OS behaviour!

[c-smile]

"It does!" at some extent that is far from being adequate for native UI needs.

Consider that you need add <word>...</word> element that will implement natively MS Word editing area. This will allow you to define MS Word editing chrome in HTML/CSS but keep core editing functionality native and effective.

Consider implementation of <tabs> native element/behavior: https://github.com/c-smile/sciter-sdk/blob/master/include/be...

This is a demo of how native code can extend DOM - adding native "drivers" of app specific DOM elements. Yet there are other examples of native behaviors: https://github.com/c-smile/sciter-sdk/tree/master/include/be...

Essentially native behavior can do anything that built-in elements can do, even drawing on the same surface that the rest of DOM is using.

Good luck with achieving anything like that in browsers, or in Electron, or with WebAsm or whatever.