4 ms·

> Until, at least, all major modern OSes come with a built in scriptable headless browser engine One of the main advantages of shipping your own browser like E

> Until, at least, all major modern OSes come with a built in scriptable headless browser engine 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.

tambourine_man 6y ago
Exactly, but we can check for feature support and adapt accordingly. We did it for the seen for years.
- vikramkr 6y ago
  Right, but I'm getting the sense that people may have done it for years, but all that did was engender a desire to never have to worry about compatibility again
  - whoisthemachine 6y ago
    It really is the age old debate between static and dynamic libraries.
- c-smile 6y ago
  What if you have no browser for the platform at all? 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/ https://sciter.com/necromancing-sciter-on-windows-2000/
c-smile 6y ago
#2. Browsers are for browsing - desktop and mobile application UI requires far more than that. 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.
- madeofpalk 6y ago
  > #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 6y ago
    "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/behaviors/behavior_tabs.cpp 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/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.

tambourine_man 6y ago

Exactly, but we can check for feature support and adapt accordingly. We did it for the seen for years.

vikramkr 6y ago
Right, but I'm getting the sense that people may have done it for years, but all that did was engender a desire to never have to worry about compatibility again
- whoisthemachine 6y ago
  It really is the age old debate between static and dynamic libraries.
c-smile 6y ago
What if you have no browser for the platform at all? 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/ https://sciter.com/necromancing-sciter-on-windows-2000/

c-smile 6y ago

#2. Browsers are for browsing - desktop and mobile application UI requires far more than that. 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.

madeofpalk 6y ago
> #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 6y ago
  "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/behaviors/behavior_tabs.cpp 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/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.