It is more of a question than issue, how exactly does this approach minimises the Electron footprint?

[andrei-cacio]

Isn't simply bringing a "hello world" electron app starts up with the the whole engine and browser APIs and etc?

Maybe I didn't understand correctly how this works, but what Rust brings to the table is the speed of native cod instead of the overhead of a dynamic language that JS is facing (V8 optimisation mechanisms etc).

I am just curios if besides the reason above, are there other ways of minimising the Electron footprint?

Kind thanks and also kudos for the repo!!! I would love to help out if I can find with what :D

[nathansobo]

There's going to be some fixed footprint associated with Electron that is unavoidable. This mostly boils down to memory, but starting a window might also be somewhat slower than a more focused application using a native toolkit.

The goal is to strike the right balance between the flexibility and extensibility afforded by Electron and the performance goals mentioned in the README. Specifically, on newish hardware, we want to run at 8ms for animations and common text operations, 50ms for coarse-grained operations like opening an editor, and 150ms to open a window.

I'm sure there are editors that can and will do better than this, and we could certainly do better if we bypassed Electron completely. But I think based on user research that meeting these goals will yield a satisfyingly responsive user experience, and in exchange we'll get the benefits of Electron for extensible, cross-platform UI.

So to minimize the overhead of Electron, we're thinking about the following kinds of techniques:

• Limit JS to scripting interactions with the UI and do the rest in Rust. This minimizes pressure on the garbage collector and avoids needing to rely on keeping the V8 optimizer happy. It gives us access to an affine memory model that keeps the CPU cache and prefetcher happy, etc. Simple code is fast by default.
• Activate packages on worker threads. Again, this avoids needing to run setup work on the main thread which hurts Atom's window startup time today and doesn't scale.
• Mandatory use of V8 snapshots on any view code, including packages.
• Avoid using the DOM for intense use cases like the editor text rendering.

Basically, let's make the most of the strengths of Electron as a flexible, cross-platform UI framework, but use the most efficient techniques possible. This is the opposite of Atom's approach, which tries to embrace the "web" way of doing things as much as possible.

It's all about trade-offs. Hacker News loves to hate on Electron and some people will just never be satisfied with anything use it. But web tech does offer the most compelling cross-platform UI framework that I am aware of, and one that is guaranteed to be around and improving for years to come.

Hope this helps.

[YurySolovyov]

Do you think there are places in Electron that can be optimized to benefit all apps, not only xray?

[nathansobo]

Do you think there are places in Electron that can be optimized to benefit all apps, not only xray?

I think that's mostly up to Chromium, and it continues to improve.