In my curious search for lighter Electron alternatives to implement Zoho Writer's (https://writer.zoho.com) desktop app: I found Sciter[1]
It supports multiplatform app development with HTML/JS/CSS and the entire engine's runtime is just about 5MB which is unbelievably small!
I further analysed how this was possible, what I found was beyond fascinating.
1. The author has wrote a compiler that supports JS with useful extensions like classes and fancy stuff, even before ES6 came into existence.
2. He had built his own layouting engine that understands HTML and CSS 3.0
Basically he's built a custom browser engine, but custom tailored for writing multi-platform apps. So it's super-fast without as much memory taxes. It's not backed by a BigCo or a huge community (I guess) and I'm not sure whether I'll pick it for a business critical app. But the way it's architected seems far superior than the shortcut approaches that Electron or most other alternatives take.
The project is not even new. It's more than a decade old which itself is amazing.
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 problem is, you can forget about the entire web and node ecosystems of libraries, because it's just not compatible with any of the standard stuff. You'll probably end up having to write almost everything from scratch.
Also, whatever you write won't then be usable in normal browsers. So it's essentially just another cross-platform UI library, with a DSL for the UI parts - of course that's still good enough for many people.
...but if your business need/use case is to port with your existing web app to the desktop with minimal fuss (and you're willing to sacrifice UX), this in no way helps (unlike Electron). If you're going to have to manually rewrite everything for the desktop anyway, why would you want to do it in the DOM, using an older HTML version, a CSS subset, and a somewhat-compatible JS-lookalike? Why wouldn't you just write it in a desktop-native UI kit?
> ...but if your business need/use case is to port with your existing web app to the desktop with minimal fuss...
I pretty much understand this point and see that Electron help.
I would definitely write desktop-native UI, maybe just because I prefer it.
And in large programs it might be somewhat expensive. But on the other hand, I found writing QT programs to be much easier than messing with web stacks.
Nothing wrong with jQuery if it suits your use case! Sometimes mutating the DOM directly is simpler and more maintainable.
IMO React is a response to a problem that not all websites have (complex state-dependent nested UIs). At a certain level of complexity it's worth it, at another level it's necessary, beyond that it's insufficient... but below that it can totally be unnecessary and more pain than it's worth :)
That sounds like the worst of both worlds, actually. A web-LIKE language that only supports some, not all, of real browser features? Sounds like Internet Explorer all over again.
If you can't reuse the same code between web and the desktop, you might as well use a better desktop framework. This just creates a false positive lookalike that is surface-level compatible but really not reusable and maintainable, and trying to figure out which APIs are shared and which aren't would be more work than just working in a different language & environment altogether.
Which better desktop framework for cross-platform with some of the productivity available for web apps? Curious on your experiences because it's hard to avoid a lot of sprawl and inconsistencies over time.
That's a good question, and I don't know the answer :) I wasn't thinking about it that way, like as an alternative to QT or the Java stuff, you mean? That might make sense if your users don't really care about native look & feel.
Was more considering it from the perspective of web-native companies wanting some offline/desktop experience too
Sciter isn't exactly a custom browser engine, because it lacks many, many APIs that browsers would use. It just happens to also use HTML & CSS, but it's not Servo-lite or Chromium-lite with V8 slapped on.
sciter looks good, but just don't think about the recent modern web feature, current web feature is impossible to make it right/full by a small team, even ms can not catch up, so they just choose the chromium.
sciter is good if you are looking for make an app based biz which not depends too much on web spec.
> sciter looks good, but just don't think about the recent modern web feature, current web feature is impossible to make it right/full by a small team, even ms can not catch up, so they just choose the chromium.
Not every feature needs to be supported, which feature are you referring to?
Also, given the use case: what is required in your opinion?
How does the shift in microsofts scope translate to the efforts to sciter?
What did the shift imply?
> sciter is good if you looking for make a small app which not depends too much on web spec.
Since when is it a feature to comply to "web spec"?
Why should anyone continue to comply with all new requirements?
And why do you feel it is required for portable desktop applications?
Why not settle on some proven essentials?
And why I am talking about browser now?
Hopefully you elaborate your thoughts: I am sincerly curious about your opinion.
First of all, I do like sciter, it's fresh air in wails,webview,electron & tauri.
There are several cases why I prefer an electron: BrowserView, FileSystem api, newer css feature(Interop 2022 are greate), and all the newer js feature I use but I don't know it.
I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
> I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
Okay, now I see: As a web dev you are able to make use of all these new features. I do not know about current conveniences.
FWIW is that CSS should be portable across any browser/web view. And given that browsers nowadays occupy tons of memory (even though they are written in highly performant languages) I am still impressed by sciters small shipping size.
> If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
Thank you for the recommendation!! It appears to me that his previous attempts to market his product have left a serious impression. I do remember stumbling about sciter a while ago, neglecting it as well. But I can't recall my reasoning.
> BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
> CSS should be portable across any browser/web view. And given that browsers nowadays occupy tons of memory (even though they are written in highly performant languages) I am still impressed by sciters small shipping size.
Chrome is new IE since June 15 2022, and happy about it. Interop 2022 is about make safari and chrome get on the same page about new css feature.
Memory, portable CSS and browser compat is about cost, if I can make whole company install chrome, that can save a ton of money investing on support unexpected browser, one time install is way cheaper than continue support. If the company is big enough, there will be no problem, like google can rewrite whole Google Doc to canvas to support cross browser.
If building a sciter based app biz, that's all your investing goes, that make sense.
It supports multiplatform app development with HTML/JS/CSS and the entire engine's runtime is just about 5MB which is unbelievably small!
I further analysed how this was possible, what I found was beyond fascinating.
1. The author has wrote a compiler that supports JS with useful extensions like classes and fancy stuff, even before ES6 came into existence.
2. He had built his own layouting engine that understands HTML and CSS 3.0
Basically he's built a custom browser engine, but custom tailored for writing multi-platform apps. So it's super-fast without as much memory taxes. It's not backed by a BigCo or a huge community (I guess) and I'm not sure whether I'll pick it for a business critical app. But the way it's architected seems far superior than the shortcut approaches that Electron or most other alternatives take.
The project is not even new. It's more than a decade old which itself is amazing.
[1] https://sciter.com