6 ms·

One very important thing I'd like to highlight: using one shared browser instance rather than N is not gonna make your apps that consume 1GB+ of memory suddenly

One very important thing I'd like to highlight: using one shared browser instance rather than N is not gonna make your apps that consume 1GB+ of memory suddenly consume much less than that, the problem for those apps is the code they run, it's not the language, it's not the platform, it's the badly written code, and Tauri doesn't change that.

parhamn 5y ago
This is a great point. I think last I measured a basic electron browser/webview is about ~20-36mb which is not far from an about:blank chrome tab. The 300mb+ memory usage you see is mostly the javascript from the apps themselves. Either way, I'm glad more people are in the space!
- c-smile 5y ago
  According to Tauri's documentation (https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri) minimal app: Tauri Electron Memory Consumption Linux 180 MB 462 MB Note Tauri is full fledged Client/Server with WebView (client) running in separate process with RPC between UI process and Rust code (Server). For the comparison: Standalone Sciter (scapp.exe, https://github.com/c-smile/sciter-js-sdk/tree/main/bin https://github.com/c-smile/sciter-js-sdk/tree/main/bin) takes ~8 MB of RAM (with minimal Cairo and GDI backends). That's 20 times less than even Tauri. WebView based solutions are not suitable for applets - small portable desktop applications.
  - account-5 5y ago
    I was going to ask how this compared to Scoter, thanks.
mysterydip 5y ago
Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?
- jstummbillig 5y ago
  People around here seem to really struggle with the miracle that is getting into soft dev from nothing and then actually being employable in the capitalist sense after 6 or so month. Of course it's a trade off! We enabled this miracle by training people that have a very focused, narrow understanding of not even a field but a particular tech. Electron is basically the perfect fit for this type of education. It enables someone to build something where previously they could build nothing. It makes getting from 0 to 1 that much easier. From a business standpoint, it's simply smart to be wasteful with resources that are abundant (average computing power on personal devices), when it helps you save on resources that are not (dev time). But of course, there is much not to like about the side effects.
  - FpUser 5y ago
    >"It enables someone to build something where previously they could build nothing. It makes getting from 0 to 1 that much easier." Making GUI apps using Electron tech for front end is no less time consuming than doing GUI in Lazarus for example. But the end result is way more frugal in the latter case.
    - l30n4da5 5y ago
      > Making GUI apps using Electron tech for front end is no less time consuming than doing GUI in Lazarus for example It is a lot faster if you already know web tech stack, and you would have to learn Lazarus/pascal
      - Spivak 5y ago
        And since you have to know the web stack to exist at all on browsers that box is checked for basically everyone. Break the dominance on the DOM and JS in browsers and you open the door to better cross-platform toolkits.
      - FpUser 5y ago
        The original statement assumes that someone does not know nothing and has to start from scratch. In any way I am all in for the type of developers that know how to screw size 8 bolt into size 8 nut and the rest be damned. It keeps some healthy niche and remuneration for little more versatile types.
deleted 5y ago
[deleted]
oscargrouch 5y ago
i've forked chrome to create something like this (meant for native apps in a multi-process environment) and can confirm. The multi-process architecture and the chrome platform is already a overkill just for a browser (in my opinion), its much more if for each application you have a browser process + gpu process + several renderers. If you have only one main process, + 1 gpu and a process for each application running you solve that problem, even more if those process are not running javascript as in my case.
torginus 5y ago
I don't think that the Js devs are entirely to blame for this - Chrome literally eats memory for websites even with little to no Js. That's not to say that some sites are not guilty of this - Reddit is a travesty for example. The problem is that Chrome does things that make sense for a browser - like hanging on to a lot of cached stuff in the page history, or starting a separate renderer process for an iframe, but are horrible ideas when you are running a desktop app. Additionally, I'm pretty sure stuff like React is also horrible for memory usage - if you create a reference to a HTML element from Js, that means all the native resources that that element uses are subject to GC lifetime, and React, with it's shadow DOM does exactly that.

parhamn 5y ago

This is a great point. I think last I measured a basic electron browser/webview is about ~20-36mb which is not far from an about:blank chrome tab. The 300mb+ memory usage you see is mostly the javascript from the apps themselves. Either way, I'm glad more people are in the space!

c-smile 5y ago
According to Tauri's documentation (https://github.com/tauri-apps/tauri https://github.com/tauri-apps/tauri) minimal app: Tauri Electron Memory Consumption Linux 180 MB 462 MB Note Tauri is full fledged Client/Server with WebView (client) running in separate process with RPC between UI process and Rust code (Server). For the comparison: Standalone Sciter (scapp.exe, https://github.com/c-smile/sciter-js-sdk/tree/main/bin https://github.com/c-smile/sciter-js-sdk/tree/main/bin) takes ~8 MB of RAM (with minimal Cairo and GDI backends). That's 20 times less than even Tauri. WebView based solutions are not suitable for applets - small portable desktop applications.
- account-5 5y ago
  I was going to ask how this compared to Scoter, thanks.

mysterydip 5y ago

Back in the day people coded lightweight because it wouldn't run otherwise, and speed mattered in single core sub-GHz CPUs. We don't have that same constraint today, how do we get people to write more efficient code?

jstummbillig 5y ago
People around here seem to really struggle with the miracle that is getting into soft dev from nothing and then actually being employable in the capitalist sense after 6 or so month. Of course it's a trade off! We enabled this miracle by training people that have a very focused, narrow understanding of not even a field but a particular tech. Electron is basically the perfect fit for this type of education. It enables someone to build something where previously they could build nothing. It makes getting from 0 to 1 that much easier. From a business standpoint, it's simply smart to be wasteful with resources that are abundant (average computing power on personal devices), when it helps you save on resources that are not (dev time). But of course, there is much not to like about the side effects.
- FpUser 5y ago
  >"It enables someone to build something where previously they could build nothing. It makes getting from 0 to 1 that much easier." Making GUI apps using Electron tech for front end is no less time consuming than doing GUI in Lazarus for example. But the end result is way more frugal in the latter case.
  - l30n4da5 5y ago
    > Making GUI apps using Electron tech for front end is no less time consuming than doing GUI in Lazarus for example It is a lot faster if you already know web tech stack, and you would have to learn Lazarus/pascal
    - Spivak 5y ago
      And since you have to know the web stack to exist at all on browsers that box is checked for basically everyone. Break the dominance on the DOM and JS in browsers and you open the door to better cross-platform toolkits.
    - FpUser 5y ago
      The original statement assumes that someone does not know nothing and has to start from scratch. In any way I am all in for the type of developers that know how to screw size 8 bolt into size 8 nut and the rest be damned. It keeps some healthy niche and remuneration for little more versatile types.

deleted 5y ago

[deleted]

oscargrouch 5y ago

i've forked chrome to create something like this (meant for native apps in a multi-process environment) and can confirm. The multi-process architecture and the chrome platform is already a overkill just for a browser (in my opinion), its much more if for each application you have a browser process + gpu process + several renderers. If you have only one main process, + 1 gpu and a process for each application running you solve that problem, even more if those process are not running javascript as in my case.

torginus 5y ago

I don't think that the Js devs are entirely to blame for this - Chrome literally eats memory for websites even with little to no Js. That's not to say that some sites are not guilty of this - Reddit is a travesty for example. The problem is that Chrome does things that make sense for a browser - like hanging on to a lot of cached stuff in the page history, or starting a separate renderer process for an iframe, but are horrible ideas when you are running a desktop app. Additionally, I'm pretty sure stuff like React is also horrible for memory usage - if you create a reference to a HTML element from Js, that means all the native resources that that element uses are subject to GC lifetime, and React, with it's shadow DOM does exactly that.