Ah, yes. Internet Explorer, they called it. Built right into the OS. A game changer. Funny how the meaning of something (goodness/badness/motives/...) can change as circumstances change.
Edit: This comment is wrong - looks like IE did fit this description before my time. :-)
It was a good browser at the time, and helped move the OS X platform forward. Perhaps even a vital part of the software support available at release.
But it wasn't IE6.
All that corporate ActiveX, DCOM software could not be deployed on it.
Microsoft grew multiple platforms to address this, for 20 years, but that's another story (that may also be relevant to the article).
If software like this is FOSS, relies on open standards, and is designed architect independent it can be run on virtually anything. Including something which is rising in popularity.
Google didn't exist or wasn't evil yet and finding things was quite difficult specially at dial-up "speed".
One of the main advantages of shipping your own browser like Electron or SciterJS is that it's a fixed, stable target where you can be a lot more confident about browser compatibility because you're only supporting a single browser + version.
Browsers are catching up of course but... Who would thought that the thing for reading pages will need access to your file system or make screenshots...
#3. UI engine must have natural and effective means to use native code - to be embeddable and extendable by hosting application.
In native app world you don't need WebAssembler for example - you can run native code you need natively.
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!
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.
What should you do if you need your app to run on W2000 for example (IE 6.0 anyone?) ?
Sometimes people do need that: https://sciter.com/necromancing-sciter-on-windows-2000/
Until, at least, all major modern OSes come with a built in scriptable headless browser engine, which would be a game-changer. Something-like-electron-or-sciter where you don't have to download the runtime for each individual application.
Also, of course, not a walled garden: the windows "modern apps" store can sort of do this I think, but there are lots of good reasons not to go down that path.