quickjs VS sciter-js-sdk

This is a fantastic approach.

BTW, it looks like the js engine is "QuickJS" [0]. (I'm not familiar with it myself.)

I like it because sqlite by itself lacks a host language. (e.g., Oracle's plsql, Postgreses pgplsql, Sqlserver's t-sql, etc). That is: code that runs on compute that is local to your storage.

That's a nice flexible design -- you can choose whatever language you want. But quite typically you have to bring one, and there are various complications to that.

It's quite powerful, BTW, to have the app-level code that acts on the app data live with the data. You can present cohesive app-level abstraction to the client (some examples people will hopefully recognize: applyResetCode(theCode) or authenticateSessionToken(), or whatever), which can be refined/changed without affecting clients. (Of course you still have to full power and flexibility of SQL and relational data for the parts of your app that need it.)

[0] https://bellard.org/quickjs/

Considering the extremes of prolific developers gives interesting contrast to dogmas such as "functions/files should never be above x lines", where `quickjs.c` is 50k lines and has functions that are hundreds of lines long:

https://github.com/bellard/quickjs/blob/master/quickjs.c

(Obviously different approaches suites different circumstances.)

And some lightweight alternatives like Bellard's QuickJS (https://bellard.org/quickjs/) in C and Kiesel (https://kiesel.dev/) in Zig.

Built on a highly optimized JavaScript runtime powered by QuickJS, Query offers fast startup times and efficient execution. Its built-in caching mechanism further enhances performance by storing function responses, reducing database load and latency. This focus on speed makes Query a standout choice for server-side rendering, especially in applications with many components.

Where the previous SDK was built on top of the QuickJS JavaScript engine and the Javy runtime, the new SDK is built on top of the Firefox browser’s SpiderMonkey engine, and the Bytecode Alliance’s StarlingMonkey runtime and ComponentizeJS WIT bindings generator.

I'm currently using Bellard's QuickJS engine on a new TypeScript project.

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] https://github.com/c-smile/sciter-js-sdk/blob/main/docs/md/s...

[1] http://www.garret.ru/dybase.html

How tiny is the output? What is the API? (I couldn't find any documentation. I thought maybe it's in the Help menu in the app itself but all I found was this https://i.imgur.com/6puOMIe.png - On that note, what level of JS is supported? As far as I can tell it uses this https://github.com/c-smile/sciter-js-sdk which is based on Fabrice Bellard's QuickJS ) Is there sound?

JavaScript & Electron Sciter!

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....

More details.

That's why in Sciter I've extended JSX with translation meta instruction @:

Note Tauri is full fledged Client/Server with WebView (client) is 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.

scapp.exe ( Standalone sciter engine ) takes 45 Mb showing its default "about" document.