6 ms·

This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossibl

This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossible? It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is simpler - it trades of performance for uniformity of experience across the major platforms. But I'm wondering if it really has to be this way. Do modern browsers really need 2G of RAM in order to send and receive messages in a chat box (looking at you, Slack).

munificent 6y ago
> is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? 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.
- ducktective 6y ago
  I mean, where are they now? Promising or DoA? I fear touching it because of it being a Google project (killedbygoogle.com)
  - chgibb 6y ago
    We're pretty bought into Flutter. No cross platform toolkit is perfect but Flutter is miles ahead of everything else. For a not very scientific analysis: https://trends.google.com/trends/explore?date=today%205-y&q=flutter,%2Fg%2F11h03gfxy9,xamarin https://trends.google.com/trends/explore?date=today%205-y&q=...
    - nwienert 6y ago
      It’s definitely not miles ahead of just about anything. 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.
  - jonathanaird 6y ago
    They’re putting a lot of resources behind and it actually is thriving. They have a real financial interest as there’s pretty thorough firebase support. It’s also reviving their Dart language. As someone that’s using it, it is improving very quickly. Web support is getting quite good.
unnouinceput 6y ago
I wish Mozilla would do the same move as well. I remember in 2000's I had a Mozilla ActiveX that I could bundle in my applications and instant web browser without IE crap (back then was Mozilla vs IE only, Chrome was still in its infancy). Nowadays Mozilla it seems they don't even export the old ActiveX, let alone to have their own webview equivalent.
vulcan01 6y ago
> the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet 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.
- dmix 6y ago
  And in recent years this has gotten much easier. Cross browser support used to be a pain in the ass. Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.
  - Kaze404 6y ago
    Funnily enough in my experience it's usually Chrome and Safari that do weird things, which as a Firefox user always gets me dinged on PR reviews :p
- livre 6y ago
  Not much different but enough to be dangerous. Older Windows use Trident, 10 still uses EdgeHTML, many people are stuck with old Androids that don't have up to date engines (not sure if Android is a target, wasn't easy to find in their website), and webviews have access to the system in ways a website doesn't (like reading files or using the camera without having to ask for permission or being allowed to issue requests to arbitrary domains).
  - moron4hire 6y ago
    But we know from web statistics that these are very few people and shrinking every year.
    - Klonoar 6y ago
      That is not how it works on Windows, as you have to ship either the Webview2 runtime or installer with your app - otherwise you’re stuck with the old rendering engines. At which point, it’s just easier to ship Electron.
hobofan 6y ago
It seems like Electron is decently optimizable for a lowish memory footprint. Both the Element and Discord desktop client run with consistently ~50MB RAM each.
- scambier 6y ago
  Are you sure about that? Most of the time, Electron apps are split into multiple processes, and the task manager (by default) only shows the main one. Order your processes by name and I'd be surprised to see the total under 150MB.
- scaladev 6y ago
  >~50MB RAM each 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.
  - kaslai 6y ago
    Doesn't RSS include shared mappings? That's why metrics like PSS and USS were introduced. 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.
crazypython 6y ago
> 3 (maybe more) UI's on platforms Not really. Targeting the web platform and not aiming for perfect compatibility or looking the same isn't that hard.
slater 6y ago
Electrino, but looks abandoned: https://github.com/pojala/electrino https://github.com/pojala/electrino
- swagonomixxx 6y ago
  Wow, at least from the screenshot in the README, the binary size is much smaller. However I think that's just from the fact that they don't bundle the JavaScript engine and the rendering engine into their binary. You're right though, seems abandoned.
oscargrouch 6y ago
Not just that, it allows to ship with much more api's available to the user. 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..
glen-ellen 6y ago
This is similar to what Plotly did with their Kaleido project[1] that generates static images of plotly.js visualizations. Instead of using Electron or Selenium, they recompiled Chromium, stripping away a bunch of the parts they didn't need. This resulted in a cross-platform build that is much lighter weight. > 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 https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81
kybernetikos 6y ago
Have you seen how Sciter.JS has been developing https://github.com/c-smile/sciter-js-sdk https://github.com/c-smile/sciter-js-sdk There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.
- GirkovArpa 6y ago
  I've performed a couple experiments remaking Electron apps using Sciter. My first target was https://github.com/AkashRajpurohit/clipper 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 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.
c-smile 6y ago
"is this impossible?" Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk 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 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/ https://sciter.com/necromancing-sciter-on-windows-2000/
- deleted 6y ago
  [deleted]
- LockAndLol 6y ago
  From what I understand the internals (aka the engine). That is a problem IMO. I understand it's to create a dependency on the maintainer in order to make money, but yeah... it's the reason I've stayed away thus far.
- gigel82 6y ago
  I like Sciter for the possibilities, but it needs better compatibility with web standards. Being able to port an existing application that uses React -for example- and have it just run would be the cat's meow. Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.
  - c-smile 6y ago
    It depends on what application you have in mind. 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/ https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/preact https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ; MithrilJS ( https://mithril.js.org/ 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-sciter-js/ https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/ https://sciter.com/sciter-js-themes/

munificent 6y ago

> is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? 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.

ducktective 6y ago
I mean, where are they now? Promising or DoA? I fear touching it because of it being a Google project (killedbygoogle.com)
- chgibb 6y ago
  We're pretty bought into Flutter. No cross platform toolkit is perfect but Flutter is miles ahead of everything else. For a not very scientific analysis: https://trends.google.com/trends/explore?date=today%205-y&q=flutter,%2Fg%2F11h03gfxy9,xamarin https://trends.google.com/trends/explore?date=today%205-y&q=...
  - nwienert 6y ago
    It’s definitely not miles ahead of just about anything. 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.
- jonathanaird 6y ago
  They’re putting a lot of resources behind and it actually is thriving. They have a real financial interest as there’s pretty thorough firebase support. It’s also reviving their Dart language. As someone that’s using it, it is improving very quickly. Web support is getting quite good.

unnouinceput 6y ago

I wish Mozilla would do the same move as well. I remember in 2000's I had a Mozilla ActiveX that I could bundle in my applications and instant web browser without IE crap (back then was Mozilla vs IE only, Chrome was still in its infancy). Nowadays Mozilla it seems they don't even export the old ActiveX, let alone to have their own webview equivalent.

vulcan01 6y ago

> the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet 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.

dmix 6y ago
And in recent years this has gotten much easier. Cross browser support used to be a pain in the ass. Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.
- Kaze404 6y ago
  Funnily enough in my experience it's usually Chrome and Safari that do weird things, which as a Firefox user always gets me dinged on PR reviews :p
livre 6y ago
Not much different but enough to be dangerous. Older Windows use Trident, 10 still uses EdgeHTML, many people are stuck with old Androids that don't have up to date engines (not sure if Android is a target, wasn't easy to find in their website), and webviews have access to the system in ways a website doesn't (like reading files or using the camera without having to ask for permission or being allowed to issue requests to arbitrary domains).
- moron4hire 6y ago
  But we know from web statistics that these are very few people and shrinking every year.
  - Klonoar 6y ago
    That is not how it works on Windows, as you have to ship either the Webview2 runtime or installer with your app - otherwise you’re stuck with the old rendering engines. At which point, it’s just easier to ship Electron.

hobofan 6y ago

It seems like Electron is decently optimizable for a lowish memory footprint. Both the Element and Discord desktop client run with consistently ~50MB RAM each.

scambier 6y ago
Are you sure about that? Most of the time, Electron apps are split into multiple processes, and the task manager (by default) only shows the main one. Order your processes by name and I'd be surprised to see the total under 150MB.
scaladev 6y ago
>~50MB RAM each 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.
- kaslai 6y ago
  Doesn't RSS include shared mappings? That's why metrics like PSS and USS were introduced. 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.

crazypython 6y ago

> 3 (maybe more) UI's on platforms Not really. Targeting the web platform and not aiming for perfect compatibility or looking the same isn't that hard.

slater 6y ago

Electrino, but looks abandoned: https://github.com/pojala/electrino https://github.com/pojala/electrino

swagonomixxx 6y ago
Wow, at least from the screenshot in the README, the binary size is much smaller. However I think that's just from the fact that they don't bundle the JavaScript engine and the rendering engine into their binary. You're right though, seems abandoned.

oscargrouch 6y ago

Not just that, it allows to ship with much more api's available to the user. 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..

glen-ellen 6y ago

This is similar to what Plotly did with their Kaleido project[1] that generates static images of plotly.js visualizations. Instead of using Electron or Selenium, they recompiled Chromium, stripping away a bunch of the parts they didn't need. This resulted in a cross-platform build that is much lighter weight. > 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 https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81

kybernetikos 6y ago

Have you seen how Sciter.JS has been developing https://github.com/c-smile/sciter-js-sdk https://github.com/c-smile/sciter-js-sdk There are a few working examples, and they have dramatically lower memory footprint and are quicker to start than full fat browsers.

GirkovArpa 6y ago
I've performed a couple experiments remaking Electron apps using Sciter. My first target was https://github.com/AkashRajpurohit/clipper 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 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.

c-smile 6y ago

"is this impossible?" Possible, see Sciter.JS : https://github.com/c-smile/sciter-js-sdk 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 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/ https://sciter.com/necromancing-sciter-on-windows-2000/

deleted 6y ago
[deleted]
LockAndLol 6y ago
From what I understand the internals (aka the engine). That is a problem IMO. I understand it's to create a dependency on the maintainer in order to make money, but yeah... it's the reason I've stayed away thus far.
gigel82 6y ago
I like Sciter for the possibilities, but it needs better compatibility with web standards. Being able to port an existing application that uses React -for example- and have it just run would be the cat's meow. Needing to rewrite with other UI/JS frameworks to account for quirks gives me pause.
- c-smile 6y ago
  It depends on what application you have in mind. 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/ https://preactjs.com/ ) works out of the box already, see : https://github.com/c-smile/sciter-js-sdk/tree/main/samples/preact https://github.com/c-smile/sciter-js-sdk/tree/main/samples/p... ; MithrilJS ( https://mithril.js.org/ 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-sciter-js/ https://sciter.com/behaviorvirtual-list-for-sciter-and-scite... and https://sciter.com/sciter-js-themes/ https://sciter.com/sciter-js-themes/