The issue is that this isn't actually an Electron alternative; the author is upfront about this not actually being a browser-compatible rendering engine. It's just a rendering engine that happens to use some subset / superset of HTML, JS and CSS, but it is not compatible with web libraries and components.
As a basic example, SciterJS crashes loading the "hello world" ReactJS project (at least it did last time I tried it - the author recommended I used a custom version of React he publishes). It's perfectly fine to come up with a lightweight cross-platform UI rendering engine (we know we need more of those), but having it web-adjancent while not really web-compatible is a recipe for frustration.
- 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.
That doesn't sound like an "issue", that sounds like a perk. Even the "crashing running ReactJS" part. If my semi truck crashes when I tilt it over on 2 wheels like a motorcycle, I don't call it an "issue".
> having it web-adjancent while not really web-compatible is a recipe for frustration
Exactly. What's the point of using HTML/CSS/JS for a desktop UI, when you can't make use of the incredible amount of effort that has been spent on frameworks, toolkits, and libraries to make building a HTML UI bearable?
I see, in this thread, talks about what Sciter does and does not offer.
It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.
I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)
On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.
The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.
It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)
However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.
it's not embeddable and not portable, therefor doesn't qualify as a proper GUI toolkit, at best it is a plugin toolkit for windows's integrated web browser
Since there is presumably no commercial advantage to keeping TIScript proprietary, it would be nice to open source it. It was a shame when Opera announced that they were moving to Chromium but didn't throw the Presto sources over the wall at the same time. I think we have to treat it like that code is never going to see the light of day, which is unfortunate, since even under restrictive copyright regimes, eventually books and movies become public domain.
DO:
- Use LGPL or GPL for TIScript, if you want; customers who need something further away from copyleft on the spectrum of open source can continue paying
DON'T:
- Equate open sourcing the code with running an open source project and all the overhead that comes along with it and then decide not to do it for that reason; throw it over the wall with a license slapped on it and don't ignore the "NO WARRANTY" section (this is the thing that 99% of GitHub projects with burned out maintainers get wrong)
- Get bashful about code quality and say "I need to polish it up first"; nobody cares (since Sciter has already been shared source for a while, I don't expect this to be a problem, but just trying to cover all the bases here)
> It was a shame when Opera announced that they were moving to Chromium but didn't throw the Presto sources over the wall at the same time. I think we have to treat it like that code is never going to see the light of day...
The Presto source was leaked years ago. You can't use it for anything you're going to release, of course -- but it's out there.
I'd really like to see Sciter take off to mainstream. If I was asked to do an application with specific custom designed UI, I'd use Sciter.
I have given it a go some months ago, alongside with Delphi and it's really really easy to get started.
It's not open source yet, but... hey! it doesn't have to be to be to be successful.
Of course, Terra Informatica doesn't have the same level of marketing budget than Microsoft/GitHub to promote it as Electron, but a project can rise to relevance by its own merits I believe. I usually err on the side of naïvety for these cases.
sciter is pretty successful already - https://sciter.com/ lists a number of recognisable commercial users and estimates 340 million installs over its lifetime. i very much doubt it will go mainstream without being open sourced though; closed source is simply a mindshare killer for this kind of developer-focused project.
Functional superset but unfortunately not a strict superset. I regret a bit that I did not follow ECMA spec closely with initial TIScript (I am an author of Sciter).
It was damned too easy to fix those birth defects of JS so I could not resist to do that right from the beginning ...
So weird - I just found this out naturally when visiting the Sciter homepage last week and I didn't recall it ever being said that this would ever be done. I do remember the author's brief moment where he was considering open-sourcing it with QuickJS as the engine.
On the Rust side, I've been looking at Tauri, but would much prefer it be usable with something other than the host webview, like Sciter. Tauri offers a bit more of a complete API for desktop apps and it would be nice to have my cake and eat it too.
I keep wondering how feasible it would be to have something like Tauri ship with a simplified webview, so it could still be consistent across platforms but still without the bloat of Electron. Although really, the problem isn't using the host's view so much as IE's webview being the default on Windows.
Even better, a lot of the necessary complexity involved in getting the web stack to look and act like native could be done away with by redesigning a version of that stack optimized for displaying applications rather than documents.
It would no longer be the web stack but it could take the advantages of it without the shortcomings.
Just a bit of empathy, I can relate to your loss, c-smile. No matter how good your idea is, the crude force of “web standards best practices top frameworks wow salary” inertia can crush every noble endeavor and almost nobody will even notice it’s status quo, not the only way.
I'm interested in exploring the state of memory management in between pure ownership trees and all-out GC, including stack-allocated structs, refcounting, cycle collection, and per-thread-enabled GCs. I found https://bellard.org/quickjs/quickjs.html and https://news.ycombinator.com/item?id=20413561 when looking for more information on QuickJS's cycle removal, which mentions the "Bacon cycle collector".
Ref-counting GC and in particular implementation that is used in QuickJS is more deterministic I would say.
In QuickJS:
function Foo() {
let file = new File(...);
file.write("Happy New Year");
}
The file variable (object in it) will be destroyed immediately at the exit from the function.
Which is more suitable in case of Sciter that is embeddable [in native applications] engine.
Contrary my TIScript that I was using before had real moving/compacting GC. Objects were freed at GC cycles (in galaxy far far away from invocation).
Related tangent: Is anyone aware of any CSS frameworks that are "native-like" and not generic web-based things?
E.g. if I want OS-style UI components + styles like a browser tab-strip or pane splitters or toolbars etc?
There are loads of things out there with UI elements, but they seem to be focused on webpage use-cases and design patterns, and so are not really suitable for desktop apps running in sciter/electron/tauri/neutralino/wails/others
Reading thru the spec for the language brought back PTSD flashbacks from doing InDesign scripting with ExtendScript https://extendscript.docsforadobe.dev/
I have a little progressive Web app I'm currently rewriting in Vue 3. Was hoping to toss it in electron for cross platform desktop use. Now I think I'll give this a go first. Great work!
Electron is large because it is a pack that combines full fledged web browser (WebKit) and server (NodeJS).
Web browser engine is designed with these priorities:
1. to provide safe browsing experience;
2. to present web pages in standard manner;
Note the order. Safe browsing means the following:
1. You must run user facing UI (tab) in separate process. This involves RPC with the rest of application.
2. You cannot allow any executable code other than managed JS. And so you MUST provide JIT or something like that as JS is the only option to run anything.
The order requires and leads to a lot of code to support those priorities.
And why would you doubt that? You used to be able to run a whole Linux distribution from a floppy.
It's not a complete alternative, so a lot of APIs and features that Chromium has are missing. The Chromium dev team isn't focused on size, but speed and features. While an alternative that does less can focus on size.
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.
My guess is probably the QuickJS has less resource usage compared to the more performant V8.
UPDATE:
Now I have read the linked article, here is the reasons (copied from the article):
API and integration principles are close to what TIScript uses – it took me just 1 month to add QuickJS to Sciter core. And 4 months more to expose HTML/CSS runtime to JS.
Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself;
Liberal MIT license. Sciter cannot use GPL/LGPL code – many customers expressed this requirement;
There is a section with the key reasons it was picked, in particular:
"Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself"
I wonder what are the global scale environmental consequences will be, long term. Could it make a difference between couple nuclear reactors urgently needed and no longer needed?
“golden 40 seconds” rule: for the user, to buy a product, it should not take more than 40 seconds from the click on “download” button to the UI to appear on screen.
[+] [-] gigel82|4 years ago|reply
The issue is that this isn't actually an Electron alternative; the author is upfront about this not actually being a browser-compatible rendering engine. It's just a rendering engine that happens to use some subset / superset of HTML, JS and CSS, but it is not compatible with web libraries and components.
As a basic example, SciterJS crashes loading the "hello world" ReactJS project (at least it did last time I tried it - the author recommended I used a custom version of React he publishes). It's perfectly fine to come up with a lightweight cross-platform UI rendering engine (we know we need more of those), but having it web-adjancent while not really web-compatible is a recipe for frustration.
[+] [-] c-smile|4 years ago|reply
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:
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...[+] [-] phendrenad2|4 years ago|reply
[+] [-] acemarke|4 years ago|reply
Any pointers to discussion on what JS/DOM features it's missing that React needs?
[+] [-] adwn|4 years ago|reply
Exactly. What's the point of using HTML/CSS/JS for a desktop UI, when you can't make use of the incredible amount of effort that has been spent on frameworks, toolkits, and libraries to make building a HTML UI bearable?
[+] [-] cyansmoker|4 years ago|reply
It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.
I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)
On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.
The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.
I cross-compile the apps using xgo (https://github.com/karalabe/xgo)
It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)
However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.
[+] [-] Shadonototra|4 years ago|reply
it's not embeddable and not portable, therefor doesn't qualify as a proper GUI toolkit, at best it is a plugin toolkit for windows's integrated web browser
[+] [-] leetrout|4 years ago|reply
[+] [-] shp0ngle|4 years ago|reply
Oh. That's the QEMU/FFMPEG Fabrice Bellard? That sounds definitely interesting. (Perhaps more than the actual article, haha.)
https://bellard.org/quickjs/
[+] [-] hn_throwaway_99|4 years ago|reply
In my opinion, there are 10x developers, there are 100x developers, then there is Fabrice Bellard.
[+] [-] jffry|4 years ago|reply
[+] [-] neurostimulant|4 years ago|reply
[+] [-] pwdisswordfish9|4 years ago|reply
DO:
- Use LGPL or GPL for TIScript, if you want; customers who need something further away from copyleft on the spectrum of open source can continue paying
DON'T:
- Equate open sourcing the code with running an open source project and all the overhead that comes along with it and then decide not to do it for that reason; throw it over the wall with a license slapped on it and don't ignore the "NO WARRANTY" section (this is the thing that 99% of GitHub projects with burned out maintainers get wrong)
- Get bashful about code quality and say "I need to polish it up first"; nobody cares (since Sciter has already been shared source for a while, I don't expect this to be a problem, but just trying to cover all the bases here)
[+] [-] duskwuff|4 years ago|reply
The Presto source was leaked years ago. You can't use it for anything you're going to release, of course -- but it's out there.
[+] [-] ivanmontillam|4 years ago|reply
I have given it a go some months ago, alongside with Delphi and it's really really easy to get started.
It's not open source yet, but... hey! it doesn't have to be to be to be successful.
Of course, Terra Informatica doesn't have the same level of marketing budget than Microsoft/GitHub to promote it as Electron, but a project can rise to relevance by its own merits I believe. I usually err on the side of naïvety for these cases.
[+] [-] zem|4 years ago|reply
[+] [-] chrisseaton|4 years ago|reply
[+] [-] c-smile|4 years ago|reply
It was damned too easy to fix those birth defects of JS so I could not resist to do that right from the beginning ...
[+] [-] lucasyvas|4 years ago|reply
On the Rust side, I've been looking at Tauri, but would much prefer it be usable with something other than the host webview, like Sciter. Tauri offers a bit more of a complete API for desktop apps and it would be nice to have my cake and eat it too.
[+] [-] krapp|4 years ago|reply
Even better, a lot of the necessary complexity involved in getting the web stack to look and act like native could be done away with by redesigning a version of that stack optimized for displaying applications rather than documents.
It would no longer be the web stack but it could take the advantages of it without the shortcomings.
[+] [-] c-smile|4 years ago|reply
[+] [-] wruza|4 years ago|reply
[+] [-] nyanpasu64|4 years ago|reply
I'm interested in exploring the state of memory management in between pure ownership trees and all-out GC, including stack-allocated structs, refcounting, cycle collection, and per-thread-enabled GCs. I found https://bellard.org/quickjs/quickjs.html and https://news.ycombinator.com/item?id=20413561 when looking for more information on QuickJS's cycle removal, which mentions the "Bacon cycle collector".
[+] [-] c-smile|4 years ago|reply
In QuickJS:
The file variable (object in it) will be destroyed immediately at the exit from the function. Which is more suitable in case of Sciter that is embeddable [in native applications] engine.Contrary my TIScript that I was using before had real moving/compacting GC. Objects were freed at GC cycles (in galaxy far far away from invocation).
[+] [-] ipodopt|4 years ago|reply
https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bac...
Probably specifically refers to "Concurrent cycle collection in reference counted systems" where Bacon is first author?
[+] [-] mattlondon|4 years ago|reply
E.g. if I want OS-style UI components + styles like a browser tab-strip or pane splitters or toolbars etc?
There are loads of things out there with UI elements, but they seem to be focused on webpage use-cases and design patterns, and so are not really suitable for desktop apps running in sciter/electron/tauri/neutralino/wails/others
The closest thing I know about is https://khang-nd.github.io/7.css/ but that only has a limited control set.
[+] [-] yaserahmady|4 years ago|reply
[+] [-] gostsamo|4 years ago|reply
[+] [-] c-smile|4 years ago|reply
It works with Narrator, NVDA, etc. just fine. HTML may contain standard aria-xxx annotations for better quality.
[+] [-] mingodad|4 years ago|reply
[+] [-] c-smile|4 years ago|reply
[+] [-] whalesalad|4 years ago|reply
[+] [-] twistedcheeslet|4 years ago|reply
[+] [-] Sosh101|4 years ago|reply
[+] [-] c-smile|4 years ago|reply
Web browser engine is designed with these priorities:
1. to provide safe browsing experience;
2. to present web pages in standard manner;
Note the order. Safe browsing means the following:
1. You must run user facing UI (tab) in separate process. This involves RPC with the rest of application.
2. You cannot allow any executable code other than managed JS. And so you MUST provide JIT or something like that as JS is the only option to run anything.
The order requires and leads to a lot of code to support those priorities.
[+] [-] akvadrako|4 years ago|reply
It's not a complete alternative, so a lot of APIs and features that Chromium has are missing. The Chromium dev team isn't focused on size, but speed and features. While an alternative that does less can focus on size.
[+] [-] ComodoHacker|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[+] [-] pier25|4 years ago|reply
I seem to remember Sciter being super performant compared to regular web rendering engines.
[+] [-] c-smile|4 years ago|reply
[+] [-] eawoifjaiowepfj|4 years ago|reply
[+] [-] c-smile|4 years ago|reply
It is actually not the fact that V8 in context of Sciter alike use cases will be faster.
Consider this statement:
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.
[+] [-] longstation|4 years ago|reply
UPDATE: Now I have read the linked article, here is the reasons (copied from the article):
API and integration principles are close to what TIScript uses – it took me just 1 month to add QuickJS to Sciter core. And 4 months more to expose HTML/CSS runtime to JS.
Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself;
Liberal MIT license. Sciter cannot use GPL/LGPL code – many customers expressed this requirement;
Readable source code. Well… almost readable.
[+] [-] zamadatix|4 years ago|reply
"Relatively compact implementation – QuickJS is slightly more fatty (by 100 kb) but still in acceptable range. For the note: full version of V8 is about 40 mb – 5 times larger than Sciter itself"
[+] [-] numpad0|4 years ago|reply
[+] [-] xbar|4 years ago|reply
“golden 40 seconds” rule: for the user, to buy a product, it should not take more than 40 seconds from the click on “download” button to the UI to appear on screen.
[+] [-] _jordan|4 years ago|reply
[+] [-] unbanned|4 years ago|reply