sciter-js-sdk

good callout wrt being slower than JIT. ofc for certain applications it's not a showstopper, ie, if you're not using javascript for your MVC but doing more of a progressive enhancement thing. CSS2 is closer to trivial, but CSS3 is practically a 3D game engine with all of its matrix transforms, transitions, animations, variables - not to mention all the different layout schemes (Sciter blogged about introducing display:flex and display:grid two months ago) The most interesting part of Sciter to me is that data persistence goes way beyond localStorage (string key: string value) or filesystem API, instead it's DyBase [0][1] behind the scenes, which looks to be a very intriguing style of storing trees of data in the host language's datatype (including whatever classes you define) without mucking about with the leaky abstractions of an ORM. [0

I’m not a JS developer, so take this with much salt, but one that caught my eye was SciterJS [1]. It is built using Fabrice Bellard’s QuickJS engine [2], and appears to be very efficient. Definitely has great potential I think. See previous discussion here: [3] [1] https://github.com/c-smile/sciter-js-sdk [2] https://bellard.org/quickjs/ [3] https://news.ycombinator.com/item?id=24797423

Having normal procedural language for build automation is of course useful. That's for those 10% of cases when "standard" build DSL (make,CMake,etc.) simply do not have facilities. But the rest of 90% tasks should have compact (easily readable) definitions. I personally found that Premake5 has quite good balance for these tasks. Premake files are plain .lua files and due to Lua syntax they are easily readable. And if needed you can call from them procedures defined in again Lua. So typical project (multiplatform) definition looks pretty readable, for example one project from Sciter SDK: https://github.com/c-smile/sciter-js-sdk/blob/main/premake5....

According to Tauri's documentation (https://github.com/tauri-apps/tauri) minimal app: Tauri Electron Memory Consumption Linux 180 MB 462 MB Note Tauri is full fledged Client/Server with WebView (client) running in separate process with RPC between UI process and Rust code (Server). For the comparison: Standalone Sciter (scapp.exe, https://github.com/c-smile/sciter-js-sdk/tree/main/bin) takes ~8 MB of RAM (with minimal Cairo and GDI backends). That's 20 times less than even Tauri. WebView based solutions are not suitable for applets - small portable desktop applications.

Sciter SDK (https://github.com/c-smile/sciter-js-sdk) is OpenSource/BSD But Sciter Engine itself (https://sciter.com) is not OS - its sources are available to customers only. I tried to make it Open Source ( https://www.kickstarter.com/projects/c-smile/open-source-sci... ) but not too much interest for that.

It does support <canvas>, with limited support but still. See: https://github.com/c-smile/sciter-js-sdk/tree/main/samples/c... Sciter also supports immediate mode painting on any element (like in DearIMGUI): element.paintBackground = function(gfx) { ... drawing operations here ... } See: https://github.com/c-smile/sciter-js-sdk/tree/main/samples.s...

"a faster engine like V8" It is actually not the fact that V8 in context of Sciter alike use cases will be faster. Consider this statement: document.body.patch(<body>Hello world</body>); In case of Sciter this expression runs with native speed. JSX is built-in and element.patch() method is native. While in browser, in case of ReactJS, you will run that patch() (reconciliation procedure ReactDOM.render) with JS VM speed as that algorithm is implemented on JS/TS. The whole point of Sciter is in its embeddability - you can add native objects of your app callable directly from script. Check this example of native object: https://github.com/c-smile/sciter-js-sdk/blob/main/demos/int... So you really don't need V8 JIT infrastructure to achieve max performance - just add native objects when needed.

"custom version of React he publishes..." It is not a a custom version of React but rather extension of DOM model by just these: 1. Native JSX support. In Sciter QuickJS was extended to support JSX literals out of the box: https://github.com/c-smile/quickjspp/blob/master/quickjs-jsx... 2. Native methods: - Element.patch(...JSX expression...) - native VDOM reconciliation implementation. - Element.append/prepend(...JSX expression...) - DOM population by JSX - Native support of lifecycle "events": componentDidMount/WillUnmount and componentUpdate. Surprisingly, these are enough to allow to use pretty much all ReactJS functionality, and with native speed. And without the need for any external libraries. Check: https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r...

- React works with some modifications: check https://github.com/c-smile/sciter-js-sdk/blob/main/samples/r... - VueJS works as it is. - PReact works as it is, also with built-in JSX support of Sciter: https://github.com/c-smile/sciter-js-sdk/blob/main/samples/p... - MithrilJS also works as it is. - Svetle also works: https://sciter.com/forums/topic/svelte-sciter-js/

> Imba's Memoized DOM approach is an order of magnitude faster than Virtual DOMs (Vue, React). Learn more here: https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me... Just in case... Sciter's native built-in Reactor https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r... is using that so called "Memoized DOM" approach, which, as far as I understand the wording, is "diffing with real DOM": you have real DOM tree on the left and virtual DOM tree on the right. Reconciliation in this case is just patching of the left tree by the right one. Essentially Sciter's Reactor is a unification of React with WebComponents ideas into single entity.

Leaflet works as it is in Sciter[1] too. SDK sample: https://github.com/c-smile/sciter-js-sdk/tree/main/samples/l... So it can be used in pretty much any native desktop application. Including desktop games that use DX11, DX12, Vulkan or Metal graphics. [1] https://sciter.com

"Better" here means that JSX and things like element.append(vDOM/JSX expr/) and Element.patch(vDOM/JSX expr/) are implemented natively - does not need any library at all. Consider these features as an idea for browser vendors / W3C to extend DOM that we all use. With these features (JSX & element.patch(vdom)) we don't need whole class of JS frameworks like React, PReact, Mithril. Vanilla JS (ES2020 spec) can be used instead. See: https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r...

Far not all applications need SQLite. And SQLite is a bit fatty. In most cases built-in Sciter's NoSQL DB is enough, see: https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/s... . Feature set is close to MongoDB but in 60 kb. 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.

"lower-level cross-platform abstraction" needs some clarfication. For example Sciter exposes Graphics API https://github.com/c-smile/sciter-js-sdk/blob/main/include/s..., is this close to what you mean? It allows to render stuff a la ImGUI - immediate mode painting. And what's in principle wrong with DOM? DOM is tree of lightweight nodes and elements. In Sciter each DOM element may have native controllers, known as behaviors. Examples of those: https://github.com/c-smile/sciter-js-sdk/tree/main/include/b... . So you can create single DOM node - document and attach your native behavior to it. It will receive all events and will do drawing if you want. Some applications are using mixed model: DOM where it makes sense, and custom native behavior where high performant handling is required. In fact DOM and ImGraphics have their strong points b

I recommend Sciter.JS as a lightweight alternative to Electron. It's less than 10mb. If you visit the repo here: https://github.com/c-smile/sciter-js-sdk There's a database demo in samples/sqlite.