24 ms·

Sciter, the 5 MB Electron alternative, has switched to JavaScript

327 points by BafS 5y ago

whalesalad 5y ago
Reading thru the spec for the language brought back PTSD flashbacks from doing InDesign scripting with ExtendScript https://extendscript.docsforadobe.dev/ https://extendscript.docsforadobe.dev/
shp0ngle 5y ago
> Fabrice Bellard have created his QuickJS embeddable JS engine Oh. That's the QEMU/FFMPEG Fabrice Bellard? That sounds definitely interesting. (Perhaps more than the actual article, haha.) https://bellard.org/quickjs/ https://bellard.org/quickjs/
- hn_throwaway_99 5y ago
  The whole list at bellard.org is incredible. In my opinion, there are 10x developers, there are 100x developers, then there is Fabrice Bellard.
  - bsder 5y ago
    I maintain that Fabrice Bellard, like Armin Rigo and Wietse Venema, are evidence that self-aware AI has already developed.
    - teruakohatu 5y ago
      People have speculated that he is not one person. His/thier history is documented on Wikipedia, but its possible just one representative has shown up to events in the past. Even for a small team the output would be incredible, but I choose to believe it is just one super-human. One day I hope to meet him.
      - c-smile 5y ago
        Fabrice is real person and, yes, he did that by himself. Just in case, most of JS implementations are one-man shows.
      - lenkite 5y ago
        "People have speculated that he is not one person." The Sum Of All Men.
      - ReactiveJelly 5y ago
        I can believe he is really one guy. When I look at all the "Kinda interesting" projects on my hard drive that died out halfway-through, and compare myself to Fabrice, I think that Fabrice is merely: - One of the least lazy people ever - Mentally healthy - Not publishing small projects he does for himself - Able to consistently pick projects that are both useful and clearly-scoped. The project-picking trick is, make programs that work on existing data. When I make a game, 100 hours of work does not yield even 1 hour of good gameplay, and the game doesn't do anything but let you play the game. But when Fabrice makes QEMU, there is already a bunch of OS images you can try out in it. When he makes ffmpeg, there is already a bunch of media files to decode and transcode with it. When he makes JSLinux, there is already Linux stuff to play with. And QuickJS runs existing JavaScript code. Being too original sinks a project. Every time you see a fun project like "I made my own virtual machine, OS, and language," remember, that project is a game, which provided 100 hours of fun for the developer and maybe 1 hour for you. The game is self-contained and doesn't gain any value by inter-operating with the rest of reality, because the VM, OS, and lang are all one-offs. Fabrice isn't held back by the idealism of "I'll rewrite the world all at once". His stuff is great because he's replacing individual components with stuff that works better, in the same machine. Like GNU did.
        mrweasel 5y ago
        He is clearly an incredible smart guy, but I had the same thought. He work projects that most of us would never start, and that elevates him even higher. The interesting part, me being dumber, how much of could I accomplice assuming the same level of dicipline and similar routines?
  - shp0ngle 5y ago
    Yeah we had that discussion few days ago here on HN But I didn't know he did a fast JS engine, that looks great
    - bjoli 5y ago
      It is fast for what it is. But it is about 50% the speed of JITless v8. What is impressive is that it is about 1/40th the size.
    - vanderZwan 5y ago
      > Yeah we had that discussion few days ago here on HN It's kind of inevitable that this happens every once in a while, really.
    - chrisjc 5y ago
      > Yeah we had that discussion few days ago here on HN Mind providing the link? I'd really love to follow that discussion to gain a little more context for this discussion. Edit: is this the link? https://news.ycombinator.com/item?id=20411154 https://news.ycombinator.com/item?id=20411154 E2: Nm, that link is old (2019), but still a very interesting read.
  - agumonkey 5y ago
    Fun fact, the bell curve was named after him /s
    - amelius 5y ago
      Sad fact: you can be a 1000x developer, and people will not remember your name in 100 years.
      - zem 5y ago
        should've sold substandard copper instead
- jffry 5y ago
  Yes, that's the one and the same Fabrice Bellard! Prior discussion here: https://news.ycombinator.com/item?id=20411154 https://news.ycombinator.com/item?id=20411154
- neurostimulant 5y ago
  Ah, yes, running QuickJS inside a linux vm running under JSLinux in a web browser (use `qjs` command to run QuickJS): https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg
twistedcheeslet 5y ago
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!
chrisseaton 5y ago
The previous scripting language was a I think a superset of JavaScript anyway, so it's not like it was completely different before.
- chrismorgan 5y ago
  It was generally presented as an extension of fairly ancient JavaScript, but as a non-user I believe it was only ever like JavaScript, and not a superset even at the start, because of things like splitting numbers into integer and float types. And since then, the two had diverged, quite significantly and incompatibly in places (in semantics, I mean, not just syntax).
- c-smile 5y ago
  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 ...
  - chrismorgan 5y ago
    I’m concerned that you’re falling into the same trap here with integrating your own variant of JSX, and mulling over adding more things like hyphens in unquoted object literal keys. JSX is popular enough that it’s safe, ECMAScript isn’t going to break it, but your alterations to JSX are already significantly incompatible: you have <input.search /> being equivalent to JSX("input", {"class": "search"}, null), but the JSX everyone else is using has that equivalent to JSX(input.search, {}, null). I’m not certain if your JSX syntax is supposed to be able to be used with React code or anything else that uses JSX syntax, but if yes then it’ll be broken in a significant number of cases so that it’s worse than useless, and if no, well, it’s going to be misleading, and what if JSX did get merged into ECMAScript in some form? Then you’d be incompatible with ECMAScript again. Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now, but just because it’d be a syntax error now doesn’t mean it always will be. Decorators in TypeScript are a good example of things going badly wrong even when an extremely popular project is involved. I say: if you want to go JavaScript, go JavaScript, maaaaaybe plus standard JSX conforming with <https://facebook.github.io/jsx/ https://facebook.github.io/jsx/>, and no further. Even if what you do is obviously superior, &c. &c. I’d apply the same reasoning on your fork of CSS: you introduced it for a good reason back then, but now it’s just friction, even if it’s a little better in a vacuum (and maybe it is in parts, maybe it isn’t in other parts).
nyanpasu64 5y ago
> Reference counting GC with loops detection 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 https://bellard.org/quickjs/quickjs.html and https://news.ycombinator.com/item?id=20413561 https://news.ycombinator.com/item?id=20413561 when looking for more information on QuickJS's cycle removal, which mentions the "Bacon cycle collector".
- ipodopt 5y ago
  https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en&oi=sra https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en... https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bacon+cycle+collection&oq=bacon+cycle 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?
- c-smile 5y ago
  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).
  - pjmlp 5y ago
    In such basic example yes. Now try an data structure, with an unknown size of elements that can non-deterministically scale to several hundreds nodes and delete the graph root node. Which is why all high performance Ref-counting GC rely on background threads for when RC reaches zero, thus mimicking tracing GC implementations.
    - 5y ago
lucasyvas 5y ago
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.
- c-smile 5y ago
  Just in case, this Rust application: https://github.com/rustdesk https://github.com/rustdesk uses Sciter for its UI.
- krapp 5y ago
  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.
  - zem 5y ago
    where would the simplified webview come from though? that is precisely the value sciter delivers - a roughly web-compatible view that is much lighter weight than a full-fledged browser engine.
    - krapp 5y ago
      It looks like sciter is more or less what I was thinking of, only it doesn't support Canvas and WebAssembly as far as I can tell.
eawoifjaiowepfj 5y ago
I wonder why they used QuickJS instead of a faster engine like V8 or JSC?
- numpad0 5y ago
  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?
- longstation 5y ago
  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; Readable source code. Well… almost readable.
- zamadatix 5y ago
  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"
  - samus 5y ago
    40mb is just nuts. These days, jlink would allow me to shrink a Java JVM down to something like that. And that would already include some nontrivial batteries, which Javascript doesn't AFAIK.
  - gigel82 5y ago
    A full V8 is 8Mb on 32bit Windows and 12Mb on 64bit Windows, so not sure where that 40Mb is coming form.
_jordan 5y ago
neato! I've really enjoyed using sciter.
ivanmontillam 5y ago
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.
- zem 5y ago
  sciter is pretty successful already - https://sciter.com/ 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.
  - AlbertoGP 5y ago
    There was a crowdfunding campaign in 2020 through Kickstarter that only reached 1/10th of its funding goal: https://terrainformatica.com/2020/09/07/open-sourcing-the-sciter/ https://terrainformatica.com/2020/09/07/open-sourcing-the-sc... CA$ 100 got you immediate access to the source code under GPL or 4-clause BSD, CA$ 500 got you additionally a lifetime commercial license, etc. One of their customers commented this: > If people want good software they should pay for good software It’s simple as that. > I dont care about bloated electron apps. They are competition. > > Sciter gives me a competitive advantage and it going open source kills that. > As a paying customer I hate that. Above some critical mass of customers, it might be better off not being open source both for its creator and for its users.
gigel82 5y ago
Some previous discussion on SciterJS here: https://news.ycombinator.com/item?id=24797423 https://news.ycombinator.com/item?id=24797423 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.
- acemarke 5y ago
  That's a shame. Being able to use React/Vue/Svelte/etc with a relatively tiny native dependency would be fantastic. Any pointers to discussion on what JS/DOM features it's missing that React needs?
  - c-smile 5y ago
    - React works with some modifications: check https://github.com/c-smile/sciter-js-sdk/blob/main/samples/react/README.md 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/preact/clock.htm 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/ https://sciter.com/forums/topic/svelte-sciter-js/
    - acemarke 5y ago
      Oh neat. What actual React code changes were needed for compatibility?
      - y4mi 5y ago
pwdisswordfish9 5y ago
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)
- duskwuff 5y ago
  > 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.
gostsamo 5y ago
Does this framework support any form of screen reader accessibility? I suspect "no", but it would be nice to be wrong.
- c-smile 5y ago
  It does support accessibility. At least on Windows. It works with Narrator, NVDA, etc. just fine. HTML may contain standard aria-xxx annotations for better quality.
  - gostsamo 5y ago
    Good news then. Being html proved nothing if it is not exposed outside the app. Might try it for a spin.
cyansmoker 5y ago
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 https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com https://tailwindcss.com) and DaisyUI (https://daisyui.com 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 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.
- leetrout 5y ago
  Thanks for rich descriptions and info in what you are using!
- Shadonototra 5y ago
  WebView is a microsoft/windows thing 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
  - amaranth 5y ago
    This isn't the case, webview uses WebKitGTK on Linux, WkWebView on macOS, and either Edge/Chromium or EdgeHTML on Windows.
    - 5y ago
Sosh101 5y ago
Can anyone ELI5 how an Electron alternative can by 5MB?
- akvadrako 5y ago
  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.
  - Sosh101 5y ago
    I didn't say I doubted it.
    - akvadrako 5y ago
      I mean why would you think there is something that requires explaining.
- ComodoHacker 5y ago
  The same way Qt app can, while providing HTML widget.
- The_rationalist 5y ago
  Simply reuse a local webview
  - akvadrako 5y ago
    It doesn't do this.
- c-smile 5y ago
  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.
unbanned 5y ago
From what language
wruza 5y ago
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.
mattlondon 5y ago
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 The closest thing I know about is https://khang-nd.github.io/7.css/ https://khang-nd.github.io/7.css/ but that only has a limited control set.
- yaserahmady 5y ago
  https://framework7.io https://framework7.io is really well done.
mingodad 5y ago
Would be nice if mozilla/linux/... foundation give funding to it and made it opensource and part of OS's like libc is right now.
- c-smile 5y ago
  Yes, and I am ready for anything like that.
xbar 5y ago
I like this from Sciter's pitch: “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.
pier25 5y ago
Maybe I missed it from skimming the article... How is the performance using the new JS engine compared to the previous one? I seem to remember Sciter being super performant compared to regular web rendering engines.
- c-smile 5y ago
  TIScript and QuickJS have the same performance. Some operations can be slightly different but on average - the same.

327 points by BafS 5y ago

Reading thru the spec for the language brought back PTSD flashbacks from doing InDesign scripting with ExtendScript https://extendscript.docsforadobe.dev/ https://extendscript.docsforadobe.dev/

shp0ngle 5y ago

> Fabrice Bellard have created his QuickJS embeddable JS engine Oh. That's the QEMU/FFMPEG Fabrice Bellard? That sounds definitely interesting. (Perhaps more than the actual article, haha.) https://bellard.org/quickjs/ https://bellard.org/quickjs/

hn_throwaway_99 5y ago
The whole list at bellard.org is incredible. In my opinion, there are 10x developers, there are 100x developers, then there is Fabrice Bellard.
- bsder 5y ago
  I maintain that Fabrice Bellard, like Armin Rigo and Wietse Venema, are evidence that self-aware AI has already developed.
  - teruakohatu 5y ago
    People have speculated that he is not one person. His/thier history is documented on Wikipedia, but its possible just one representative has shown up to events in the past. Even for a small team the output would be incredible, but I choose to believe it is just one super-human. One day I hope to meet him.
    - c-smile 5y ago
      Fabrice is real person and, yes, he did that by himself. Just in case, most of JS implementations are one-man shows.
    - lenkite 5y ago
      "People have speculated that he is not one person." The Sum Of All Men.
    - ReactiveJelly 5y ago
      I can believe he is really one guy. When I look at all the "Kinda interesting" projects on my hard drive that died out halfway-through, and compare myself to Fabrice, I think that Fabrice is merely: - One of the least lazy people ever - Mentally healthy - Not publishing small projects he does for himself - Able to consistently pick projects that are both useful and clearly-scoped. The project-picking trick is, make programs that work on existing data. When I make a game, 100 hours of work does not yield even 1 hour of good gameplay, and the game doesn't do anything but let you play the game. But when Fabrice makes QEMU, there is already a bunch of OS images you can try out in it. When he makes ffmpeg, there is already a bunch of media files to decode and transcode with it. When he makes JSLinux, there is already Linux stuff to play with. And QuickJS runs existing JavaScript code. Being too original sinks a project. Every time you see a fun project like "I made my own virtual machine, OS, and language," remember, that project is a game, which provided 100 hours of fun for the developer and maybe 1 hour for you. The game is self-contained and doesn't gain any value by inter-operating with the rest of reality, because the VM, OS, and lang are all one-offs. Fabrice isn't held back by the idealism of "I'll rewrite the world all at once". His stuff is great because he's replacing individual components with stuff that works better, in the same machine. Like GNU did.
      - mrweasel 5y ago
        He is clearly an incredible smart guy, but I had the same thought. He work projects that most of us would never start, and that elevates him even higher. The interesting part, me being dumber, how much of could I accomplice assuming the same level of dicipline and similar routines?
- shp0ngle 5y ago
  Yeah we had that discussion few days ago here on HN But I didn't know he did a fast JS engine, that looks great
  - bjoli 5y ago
    It is fast for what it is. But it is about 50% the speed of JITless v8. What is impressive is that it is about 1/40th the size.
  - vanderZwan 5y ago
    > Yeah we had that discussion few days ago here on HN It's kind of inevitable that this happens every once in a while, really.
  - chrisjc 5y ago
    > Yeah we had that discussion few days ago here on HN Mind providing the link? I'd really love to follow that discussion to gain a little more context for this discussion. Edit: is this the link? https://news.ycombinator.com/item?id=20411154 https://news.ycombinator.com/item?id=20411154 E2: Nm, that link is old (2019), but still a very interesting read.
- agumonkey 5y ago
  Fun fact, the bell curve was named after him /s
  - amelius 5y ago
    Sad fact: you can be a 1000x developer, and people will not remember your name in 100 years.
    - zem 5y ago
      should've sold substandard copper instead
jffry 5y ago
Yes, that's the one and the same Fabrice Bellard! Prior discussion here: https://news.ycombinator.com/item?id=20411154 https://news.ycombinator.com/item?id=20411154
neurostimulant 5y ago
Ah, yes, running QuickJS inside a linux vm running under JSLinux in a web browser (use `qjs` command to run QuickJS): https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg

twistedcheeslet 5y ago

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!

chrisseaton 5y ago

The previous scripting language was a I think a superset of JavaScript anyway, so it's not like it was completely different before.

chrismorgan 5y ago
It was generally presented as an extension of fairly ancient JavaScript, but as a non-user I believe it was only ever like JavaScript, and not a superset even at the start, because of things like splitting numbers into integer and float types. And since then, the two had diverged, quite significantly and incompatibly in places (in semantics, I mean, not just syntax).
c-smile 5y ago
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 ...
- chrismorgan 5y ago
  I’m concerned that you’re falling into the same trap here with integrating your own variant of JSX, and mulling over adding more things like hyphens in unquoted object literal keys. JSX is popular enough that it’s safe, ECMAScript isn’t going to break it, but your alterations to JSX are already significantly incompatible: you have <input.search /> being equivalent to JSX("input", {"class": "search"}, null), but the JSX everyone else is using has that equivalent to JSX(input.search, {}, null). I’m not certain if your JSX syntax is supposed to be able to be used with React code or anything else that uses JSX syntax, but if yes then it’ll be broken in a significant number of cases so that it’s worse than useless, and if no, well, it’s going to be misleading, and what if JSX did get merged into ECMAScript in some form? Then you’d be incompatible with ECMAScript again. Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now, but just because it’d be a syntax error now doesn’t mean it always will be. Decorators in TypeScript are a good example of things going badly wrong even when an extremely popular project is involved. I say: if you want to go JavaScript, go JavaScript, maaaaaybe plus standard JSX conforming with <https://facebook.github.io/jsx/ https://facebook.github.io/jsx/>, and no further. Even if what you do is obviously superior, &c. &c. I’d apply the same reasoning on your fork of CSS: you introduced it for a good reason back then, but now it’s just friction, even if it’s a little better in a vacuum (and maybe it is in parts, maybe it isn’t in other parts).

nyanpasu64 5y ago

> Reference counting GC with loops detection 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 https://bellard.org/quickjs/quickjs.html and https://news.ycombinator.com/item?id=20413561 https://news.ycombinator.com/item?id=20413561 when looking for more information on QuickJS's cycle removal, which mentions the "Bacon cycle collector".

ipodopt 5y ago
https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en&oi=sra https://scholar.google.com/citations?user=guNVlmIAAAAJ&hl=en... https://scholar.google.com/scholar?hl=en&as_sdt=0%2C10&q=bacon+cycle+collection&oq=bacon+cycle 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?
c-smile 5y ago
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).
- pjmlp 5y ago
  In such basic example yes. Now try an data structure, with an unknown size of elements that can non-deterministically scale to several hundreds nodes and delete the graph root node. Which is why all high performance Ref-counting GC rely on background threads for when RC reaches zero, thus mimicking tracing GC implementations.
  - 5y ago

lucasyvas 5y ago

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.

c-smile 5y ago
Just in case, this Rust application: https://github.com/rustdesk https://github.com/rustdesk uses Sciter for its UI.
krapp 5y ago
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.
- zem 5y ago
  where would the simplified webview come from though? that is precisely the value sciter delivers - a roughly web-compatible view that is much lighter weight than a full-fledged browser engine.
  - krapp 5y ago
    It looks like sciter is more or less what I was thinking of, only it doesn't support Canvas and WebAssembly as far as I can tell.

eawoifjaiowepfj 5y ago

I wonder why they used QuickJS instead of a faster engine like V8 or JSC?

numpad0 5y ago
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?
longstation 5y ago
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; Readable source code. Well… almost readable.
zamadatix 5y ago
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"
- samus 5y ago
  40mb is just nuts. These days, jlink would allow me to shrink a Java JVM down to something like that. And that would already include some nontrivial batteries, which Javascript doesn't AFAIK.
- gigel82 5y ago
  A full V8 is 8Mb on 32bit Windows and 12Mb on 64bit Windows, so not sure where that 40Mb is coming form.

_jordan 5y ago

neato! I've really enjoyed using sciter.

ivanmontillam 5y ago

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.

zem 5y ago
sciter is pretty successful already - https://sciter.com/ 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.
- AlbertoGP 5y ago
  There was a crowdfunding campaign in 2020 through Kickstarter that only reached 1/10th of its funding goal: https://terrainformatica.com/2020/09/07/open-sourcing-the-sciter/ https://terrainformatica.com/2020/09/07/open-sourcing-the-sc... CA$ 100 got you immediate access to the source code under GPL or 4-clause BSD, CA$ 500 got you additionally a lifetime commercial license, etc. One of their customers commented this: > If people want good software they should pay for good software It’s simple as that. > I dont care about bloated electron apps. They are competition. > > Sciter gives me a competitive advantage and it going open source kills that. > As a paying customer I hate that. Above some critical mass of customers, it might be better off not being open source both for its creator and for its users.

gigel82 5y ago

Some previous discussion on SciterJS here: https://news.ycombinator.com/item?id=24797423 https://news.ycombinator.com/item?id=24797423 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.

acemarke 5y ago
That's a shame. Being able to use React/Vue/Svelte/etc with a relatively tiny native dependency would be fantastic. Any pointers to discussion on what JS/DOM features it's missing that React needs?
- c-smile 5y ago
  - React works with some modifications: check https://github.com/c-smile/sciter-js-sdk/blob/main/samples/react/README.md 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/preact/clock.htm 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/ https://sciter.com/forums/topic/svelte-sciter-js/
  - acemarke 5y ago
    Oh neat. What actual React code changes were needed for compatibility?
    - y4mi 5y ago

pwdisswordfish9 5y ago

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)

duskwuff 5y ago
> 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.

gostsamo 5y ago

Does this framework support any form of screen reader accessibility? I suspect "no", but it would be nice to be wrong.

c-smile 5y ago
It does support accessibility. At least on Windows. It works with Narrator, NVDA, etc. just fine. HTML may contain standard aria-xxx annotations for better quality.
- gostsamo 5y ago
  Good news then. Being html proved nothing if it is not exposed outside the app. Might try it for a spin.

cyansmoker 5y ago

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 https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com https://tailwindcss.com) and DaisyUI (https://daisyui.com 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 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.

leetrout 5y ago
Thanks for rich descriptions and info in what you are using!
Shadonototra 5y ago
WebView is a microsoft/windows thing 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
- amaranth 5y ago
  This isn't the case, webview uses WebKitGTK on Linux, WkWebView on macOS, and either Edge/Chromium or EdgeHTML on Windows.
  - 5y ago

Sosh101 5y ago

Can anyone ELI5 how an Electron alternative can by 5MB?

akvadrako 5y ago
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.
- Sosh101 5y ago
  I didn't say I doubted it.
  - akvadrako 5y ago
    I mean why would you think there is something that requires explaining.
ComodoHacker 5y ago
The same way Qt app can, while providing HTML widget.
The_rationalist 5y ago
Simply reuse a local webview
- akvadrako 5y ago
  It doesn't do this.
c-smile 5y ago
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.

unbanned 5y ago

From what language

wruza 5y ago

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.

mattlondon 5y ago

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 The closest thing I know about is https://khang-nd.github.io/7.css/ https://khang-nd.github.io/7.css/ but that only has a limited control set.

yaserahmady 5y ago
https://framework7.io https://framework7.io is really well done.

mingodad 5y ago

Would be nice if mozilla/linux/... foundation give funding to it and made it opensource and part of OS's like libc is right now.

c-smile 5y ago
Yes, and I am ready for anything like that.

xbar 5y ago

I like this from Sciter's pitch: “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.

pier25 5y ago

Maybe I missed it from skimming the article... How is the performance using the new JS engine compared to the previous one? I seem to remember Sciter being super performant compared to regular web rendering engines.

c-smile 5y ago
TIScript and QuickJS have the same performance. Some operations can be slightly different but on average - the same.