Hacker News Reader

Comment by throwGuardian | Hacker News Reader

Agree with all the pros stated in the article. However, there are cons:

1. Each desktop app is shipping almost a full browser, updating it independently and bloating RAM, storage and CPU utilization in the process.

2. RAM/CPU bloat issues are real - even the V8 team advices against overreliance on excess RAM. They've noticed a speed increase in the process of releasing V8-lite aimed at aggressive gc

3. Even amongst the most mature GUI frameworks based on html/js, there's far too much overhead for trivial things, like reading/writing to file. For instance, in electron, since the browser V8 context isn't allowed willy-nilly storage access, a file read from the browser V8 goes across a couple IPC requests to complete. Also, these hops aren't widely documented and understood, making desktop apps janky by default, instead of fast by default

View on HN

As I understand it, the author isn't even talking about web based GUI toolkits like Electron but more about the web itself (i.e. CTRL-F, back button, etc).

> Each desktop app is shipping almost a full browser

Unless you use the OS included web view.

We used this approach in a project last year and we went from about 100MB for an Electron macOS app to 4MB. Memory consumption also went down drastically although I don't remember concrete numbers.

> RAM/CPU bloat issues are real

If you only use the web view for the GUI it should be pretty lean.

> there's far too much overhead for trivial things

You can easily solve the IPC problem by using a local web server and making requests from your web view. Also, the IPC overhead is only a problem in intensive use cases many of which can be mitigated by moving logic away from the web view and into your native layer.

> If you only use the web view for the GUI it should be pretty lean.

That only keeps your binary size lean. It doesn't help at all for your RAM/CPU usage issues.

So far nobody has made a lean web view in terms of RAM & CPU/GPU usage that can also handle modern JavaScript & CSS. It just doesn't exist currently.

> Also, the IPC overhead is only a problem in intensive use cases many of which can be mitigated by moving logic away from the web view and into your native layer.

That requires you to have a native layer at which point why bother with the limitations & complexities of a web view instead of just using QT, GTK, Swing, etc...?

> It doesn't help at all for your RAM/CPU usage issues.

Well, it does, because most likely the system webview is already loaded on ram. The problem of electron is that every single electron app uses a different instance of Chrome — webviews are shared, and unless you have no browsers/apps with webviews running, it can just share the memory already loaded.

Only the binary is shared and not even all of it. And it's not at all the dominate usage of RAM anyway.

See all the memes about chrome and ram usage - and that's all shared across tabs!

You don't need to run stuff in Electron. I usually use stuff like Spotify and Slack in Firefox, which works well enough.

And yeah, the web isn't perfect. As mentioned in the article I just wanted to highlight some of the good things here. It's not intended to be a comprehensive overview of all the pros and cons.

I wonder what would happen if all major OS & Browser vendors decided to agreed on a long-term plan to migrate/evolve the HTML, CSS, and JS specs & implementations towards a functional equivalent variation that could be efficiently implemented with the same semantics and level of security (or better) but with far less CPU and memory inefficiency, removing indirection and dynamic abstraction layer by layer, until suddenly we get something that has all the legitimate benefits of modern web development, but with the same memory/CPU footprint of Cocoa or .NET, being also cross-platform and built into every OS. Wouldn't that be great?

Before that can happen, we'll get WebASM + WebGL interfaces (efficiently) in our browser. I expect an explosion of alternate layout mechanisms to arise from that. They won't be very good at first, but they may end up somewhere neat.

> I expect an explosion of alternate layout mechanisms.

No need WebASM for that. Just one CSS property:

    div {
      flow: custom [funcname/url(of-layoout-controller)];
    }

+ single function funcname() that will replace children and report min/max intrinsic sizes.

Wait, is this real? What's it called, so I can google it?

I'm guessing he's talking about https://developer.mozilla.org/en-US/docs/Web/Houdini

Building on top of WebGL would mean completely custom renderers that have to reimplement everything else too, such as scrolling and context menus and text selection. This has been tried dozens and dozens of times by big players, and never works out.

What we need to do custom layout in browsers properly without the need to give up all the nice builtins like font rendering and scrolling and a11y, is simply the ability to measure text properly.

I'd be happy if they just stopped cramming more stuff into HTML CSS and JS and just worked on optimisation from here on in. That way we could let our computers catch up.

Lets call it done.

I feel like this is unrelated to the post, which was not talking about electron apps and was instead talking about the text-based origins of the web, and why that's good.

1 is only an issue for electron. Not viewing web apps in your web browser.

Note they talk about the web, not HTML/CSS (and many of their pro arguments do not apply to Electron by default, so it's clearly not included)

Reply on news.ycombinator.com