I agree that Sciter is pretty exciting. It's tiny and very resource friendly, and the language extensions are quite nice. It also is much better at behaving like a desktop application than Electron. Oh, and did I mention there are Rust bindings?
The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.
> The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs
Even bigger drawback is that it ain't Free, honestly.
Sure, the licence allows you to use it if the users install the sciter runtime separately, but that ain't really am option beyond development imo.
Dynamic linking is allowed and you are allowed to ship those, so on Windows it's very painless. You just ship your Go/C#/Python/Rust binary with a sciter.dll that sits in the same folder. On Linux it's not quite as nice since you have to move the libsciter.so to the appropriate folder.
Of course static linking would be nicer, but I think it's fair to charge money for that (as well as for source code access). The project has to finance itself somehow.
> On Linux it's not quite as nice since you have to move the libsciter.so to the appropriate folder.
Incorrect. Linux doesn't care where you load a .so from. You could load it by using a path, or you could add a path to your LD_LIBRARY_PATH env var. You could even add it to your compiled binary's RPATH. All methods support relative paths. The latter requires a binary, but the first two work with nearly all scripting languages.
I don't think I agree. You don't need root and you don't need to "install" anything with these other options; it allows the user to extract and run rather than extract, elevate, install, run. It clearly shifts some of the pain from the user back to the developer. It's particularly clearly a win if you're distributing your app on your website instead of via distro package managers.
A shell script provided by the app author can automate setting LD_LIBRARY_PATH and running the binary. It's very convenient for the end user. Lots of programs are shipped to Linux this way.
They are easier for the end user in certain cases. Putting the library in the system library search path requires elevated privileges (usually). Having your application run from a self-contained directory does not.
I think there is an oversized focus on everything being free. It started with Google being free but it really isn't since you have to view adds and get distracted.
Also think about a software tool that costs say $100. It ain't free but that's your hourly salary Mr. Professional Developer. Using only free tools is penny-wise and pound foolish.
Agreed; don't pick the free-as-in-beer tool solely because of that. However, some of the free-as-in-beer tools are the best. And those you should donate to (if they accept it). :)
The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.