Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk

10 times more compact than Tauri, 20 times less than Electron.JS

Yet it has Rust API ( https://github.com/sciter-sdk/rust-sciter ), that if someone need "Made with Rust" label :)

And it works even on Windows 2000, do you remember that thing? See: https://sciter.com/necromancing-sciter-on-windows-2000/

Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.

React needs web browser compatibility layer to work in Sciter.JS as React was designed strictly for browsers.

For that matter: PReact ( https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ;

MithrilJS ( https://mithril.js.org/ ) works as it is also.

SvelteJS works as it is with Sciter.JS too.

Also Sciter.JS has its own native implementation of JSX ( it's built in JS core of Sciter.JS) and also DOM extended by native element.patch(vdom) that makes "reactivity" to work in Sciter.JS with native speed.

Yet quite a lot of UI components are natively built-in. For example:

https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/

Being "almost" web compatible is not a recipe for success, as it's bound to cause confusion and frustration among folks that want it to be an Electron alternative.

Either embrace Web APIs entirely (perhaps a smaller compatible subset), or just position it as something else entirely, like Flutter.

Hmm... and how do I do that? What's your impression?

Sciter.JS is "an embeddable HTML/CSS/JS UI engine" and that's it.

Yes, it is possible to use it without touching native side like ElectronJS, see: https://quark.sciter.com/ , but that's not the primary use case. So far it has around 400 mln installations in embedded form as part of other products, see: https://sciter.com/#customers

If you want you can treat it as Flutter that uses time proven and familiar HTML/CSS/JS resource definitions instead of Dart. Dart is close to JS but not JS, Flutter has some DOM but not HTML DOM, it has some style system but quite rudimental one.

But to most folks, that sounds like a "web browser/view engine", which it is not. Does it pass the Acid2 / Acid3 test?

The power of ElectronJS is not its use of HTML, CSS and JS, but the fact that it is a web browser engine and one can share the millions of frameworks, libraries and muscle memory built for the web in their desktop applications.

> one can share the millions of frameworks ...

For your *desktop* application you need just one, not millions of them.

> libraries and muscle memory

Not a problem, here I am using Remarkable [1] as it is: https://github.com/c-smile/sciter-js-sdk/tree/main/samples/m..., in other places I may use LeafletJS for showing maps, etc. Essentially all libraries for JS/NodeJS should work out of box.

Problem is that desktop UI has different UI model from a web page. Web page / Web app is usually "endless paper tape" opened full screen - has defined width but no height - no need for vertical alignment for example.

And desktop UI is usually different - small or vertically and horizontally space limited windows, etc.

In Sciter you can show element as popup one - in separate window that can be rendered outside of your [small] app window, consider this popup: https://sciter.com/wp-content/uploads/2021/02/select-table.p... , good luck with recreating this in browser. By the way that <select> element is defined as:

   <select>
        <tr role=option value="1">
            <td>Option 1</td>
            <td>*Short*</td>
            <td>123456</td>
        </tr>
        <tr role=option value="2">
            <td>Option 2</td>
            <td>******* LOONG ********</td>
            <td>123456</td>
        </tr>
        <tr role=option value="3">
            <td>Option 3</td>
            <td>*Short*</td>
            <td>123456</td>
        </tr>
   </select>

Also this

   <frameset cols="200px,*">
     <section>A</section>
     <section>B</section>
   </frameset>

TL;DR: Web and desktop UIs use inherently different models. You can share parts between these two different platforms but only parts, really.

[1] Remarkable JS: https://github.com/jonschlinkert/remarkable

But Sciter do not have codecs embedded. Instead

a. it [re-]uses streaming services of underlying OS;

b. has interface for the hosting application to supply its own video streams.

This way some applications use WebRTC as video sources, some use ffmpeg library to provide video streams. Video playback architecture is app dependent usually. Sciter provides to them "video rendering site".

That's idea of Sciter - to reuse underlying OS services as much as possible.

For example Sciter has spellchecking but only if OS provides spellchecking API (and usually they do).

Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem like that far of a stretch.

Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome.

I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well.

https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup...

https://thenextweb.com/dd/2017/11/28/please-build-websites-w...

Maybe in theory all platforms are considered, but in practice many companies just do one and the others mostly just work.

We don't run everything through it, but we run karma to make sure the code runs and the right events fire. It is still possible to write code that runs everywhere but IE.

Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.

At which point, it’s just easier to ship Electron.

Making an installer is not that hard, and you should have enough respect for your users' compute resources to go through the modicum of effort it takes.

No. As shown by the slew of other comments in this thread, it's not just about getting the runtime to load. You still have other issues involved.

You should have enough respect for your own time and money to ship the product and not open yourself up to a litany of cross-platform issues. Your job is not to fix OS vendors failing to get a common UI framework in place.

Signed, someone who has literally dealt with cross-platform-webviews in a shipping product in the past six months, and who builds native Mac apps.

That's basically the history of Flutter. The initial goal was something like "Web: The Good Parts" and the results of that experiment led them to where they are now.

As someone that’s using it, it is improving very quickly. Web support is getting quite good.

It has significant tradeoffs and fits some projects better than others.

React Native has quite a few benefits over Flutter. Especially if building for the web, I’d actually say Flutter is only usable now if you don’t build your web app with it. Which in my cost benefit analysis makes it miles behind RN, but of course, that’s why it depends.

There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.

My first target was https://github.com/AkashRajpurohit/clipper, a neat little clipboard manager. The owner was gratious enough to officially list my project under the "Clones" section of his readme =D The result was a 6mb file, compared to the original 165mb Electron app.

The second attempt was https://github.com/girkovarpa/temps-lite, an aesthetically-pleasing weather app which was motivated largely by the fact that the original was broken and abandoned yet still had people who wanted to use it. According to the open issues and forks trying to resurrect it, anyway. The file size savings were similar to the former, and they start virtually instantly. Unlike the Electron apps which have a bit of delay and then a blank window before they finish starting up.

> The goal of the Kaleido project is to make static image export of web-based visualization libraries as universally available and reliable as it is in matplotlib and ggplot2.

> To accomplish this goal, Kaleido introduces a new approach. The core of Kaleido is a standalone C++ application that embeds the open-source Chromium browser as a library. This architecture allows Kaleido to communicate with the Chromium browser engine using the C++ API rather than requiring a local network connection. A thin Python wrapper runs the Kaleido C++ application as a subprocess and communicates with it by writing image export requests to standard-in and retrieving results by reading from standard-out.

> By compiling Chromium as a library, we have a degree of control over what is included in the Chromium build. In particular, on Linux we can build Chromium in headless mode which eliminates a large number of runtime dependencies, including the audio, video, GUI toolkit, screensaver, and X11 dependencies mentioned above. The remaining dependencies can then be bundled with the library, making it possible to run Kaleido in minimal Linux environments with no additional dependencies required. In this way, Kaleido can be distributed as a self-contained library that plays a similar role to a matplotlib backend.

1. https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81

That's why is not always the best approach to appeal to whats people are saying.

Here on HN this was the #1 thing that people used to ask or complain for when the topic was electron.

"They should just integrate with the system browser" was the common saying. But the the burden would be on the developer,who would not only be back to the hellish scenario of multiple browsers implementations but also having to deal with a very skinny SDK to work with.

In the end of the day, the applications deployed on Electron will win, because they will allow developers to do much more and without the application breaking here and there because of the gimmicks of each platform.

When hearing what people say, you must have in mind the kind of the crowd you are listening to. Here on HN for instance is mostly Apple users, mostly developer types, and that's the reason why they ask for the platform browser, after asking for the platform UI, because that's how apple platform users will tend to think.. and the memory thing is the fact that most here are developers.

But that's far from being representative of the whole world of users. So, you might appeal to the particular crowd here on HN, but once you are out there "in the world" you will have a hard time facing contenders that are more resourceful than you, and the worse of all, is that it is by design. You cornered yourself into it because you forgot you are in a bubble..

https://github.com/pojala/electrino

Not really. Targeting the web platform and not aiming for perfect compatibility or looking the same isn't that hard.

Nowadays Mozilla it seems they don't even export the old ActiveX, let alone to have their own webview equivalent.

You _are_ measuring the total RAM usage, right? Something like `free -m` right before starting the application, and then after it warms up?

Every time I see these "electron is not heavy, it only uses X MBs of RAM", it turns out that the author looked at a single electron process (out of typically 5-10), and then only measured RSS, completely ignoring shared memory.

But that aside, yeah Discord is pretty heavy. My current instance which is only connected to a single server is eating 555 MB PSS, or 846MB RSS. Definitely not a lightweight at all.