You're looking in the wrong place for performance improvements. These are not the inner loop. They're not even the outer loop.

These can be in fast path, depends on the code, but that's not the point.

Coming from embedded development, the amount of short-lived heap allocations that are so conveniently swiped under the carpet with C++ is ridiculous. Even with something like slab allocators and extremely cheap allocs, there are always cases when alloc-free cycles fall on the edge of slab and become very expensive. The less is allocated during the run-time the better.

When these are combined across the whole codebase, optimizing them away _does_ result in a noticeable speed increase and makes the whole thing behave more predictably. Regardless of their perceived per-call cost.

To contextualise, my comment absolutely assumed a modern desktop target.

I obviously would not be using this (or anyone else's higher level framework!) if I was targeting an embedded platform.

Chromium is to blame not Electron. Electron is “just” Chromium + Node.

Web and ECMAscript standards are to blame not Chromium. Chromium and Node are "just" implementation work, it's not like Firefox is that much better either!

Ha, I totally agree. Actually if we’re being honest, it’s the programmers that are to blame.

But the downvotes indicate the cognitive dissonance here. It’s still fashionable to hate on Electron.