Hacker News Reader

Comment by coldtea | Hacker News Reader

>"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk.

Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget).

>2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly.

Huh?

View on HN

>Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget).

There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations.

Electron has to implement everything chrome has to support even though the apps running in it will never touch it.

Also web engines have to be heavily sandboxed because you cannot allow internet code break out of the sandbox.

Native apps shipped with electron already ship Node and just waste resources sandboxing stuff with security layers.

To be fair, there's lots that could be stripped from chrome bundled with electron. Nobody's really attempted that yet as far as I can tell - but I really hope we'll get there. I mean, there's hundreds of compilation options in there, for components that will never be used by a simple app.

Does your desktop app need a gyro, webrtc and gamepad support? But they're loaded anyway.

> Does your desktop app need a gyro, webrtc and gamepad support?

I doubt those impose very much (if any) overhead for just being present but unused. In any case, those aren't the things that the OP was talking about; there are plenty of layout-related standards like floats that are almost never used in modern web apps yet inhibit or prevent many optimizations that could potentially significantly increase rendering performance. For a more extreme example, imagine how much faster layout rendering could be if you removed all types of layout other than grid—you'd be able to remove a bunch of checks and all the code that handles edge cases, significantly simplifying the happy path.

Nobody (to my knowledge) has done this because it's not as simple as forking Chromium and removing code. Without the mentioned optimizations, I don't think you'd see much benefit.

>There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations.

Embedded browser engines though are either wrappers for Webkit and Blink (thus also including the "legacy parts of browser layout that make it impossible(?) to optimize some rendering") OR simplistic web rendering engines that are not as capable as Chrome/Webkit for layout and not compatible with all modern CSS/HTML features.

But that is where servo can fill the niche, focus on modern/fast parts, ignore legacy compatibility.

For (2), I believe they want to interact with the DOM directly (via whatever language the rest of the app is written in) without needing to go through JavaScript.

No one mention Opera before adopting webkit/blink it was lightweight and fast. And even it's source code appeared in some places after a leak.

Reply on news.ycombinator.com