Last time I played with Sciter it was based on a proprietary JS engine that wasn't fully exchangeable with common JS. Is that not the case any more, and Sciter will now understand ECMA standard JS?
Last time I played with Sciter it was based on a proprietary JS engine that wasn't fully exchangeable with common JS. Is that not the case any more, and Sciter will now understand ECMA standard JS?
Mainstream Sciter now uses QuickJS of Fabrice the Magnificent (https://bellard.org/quickjs/).
QuickJS complies to ES2020 specification. And Sciter exposes most popular and modern DOM API so MithrilJS, PReactJS and other libraries work as they are.
Sciter implements far not whole set of DOM API - just essential ones. In fact DOM API and so browsers are full of garbage - old historical layers of stuff from initial Netscape JS API, IE6, etc. For example there is no XMLHttpRequest but there is Fetch API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Sciter goal is not to support browser API as it is - with all its bells and whistles, after all desktop use cases require features that are not available in browsers anyway.
But all non-UI libraries from NPM collection should work as they are in Sciter. Most of pure Vanilla JS UI components should also work as they are, for example LeafletJS (maps) https://sciter.com/sciter-js-runs-leafletjs-as-it-is/
Also Sciter provides rich set of built-in components like JSX, Reactor, Virtual List (https://sciter.com/behaviorvirtual-list-for-sciter-and-scite...) and others.
But anyway Sciter provides an option for host application to link SQLite statically and expose it to JS: https://github.com/c-smile/sciter-js-sdk/blob/main/demos/usc... as set of native objects.
usciter from SDK is an example of application that has SQLite on board.