[jcelerier]

just having the UI definition given in native code already is a gigantic boost in terms of latency since you don't have to setup a whole javascript engine and HTML DOM to reach actual UI code though, just pass a pointer to the root of your widget tree to your paint function and see magic happening.

e.g. compare Telegram made in Qt Widgets with Signal made with Electron - the latter is incredibly slow to come up (and has broken text rendering) while the former is more or less instant on my machine (which is an overpowered i7...): https://streamable.com/m48hg7

fun fact: approaches such as Qt or also Flutter from what I could see can be more performant than some of the OS-provided UIs of some platforms - in particular Android is a pretty slow mess while Qt has seen a lot of work poured into running on <1Ghz devices.

[nwienert]

Again you just hand waved “native”. The UI definition here is in Lua, it then calls a backend that renders to the system, not sure if that part is C or not.

But... this setup may be a lot simpler, but no different from Electron in that they are both scripting languages that eventually use C to render.

Also, you can’t just cherry pick an example. It’s very possible to write pretty fast interfaces using v8. Certainly going straight html/css is slow, but that’s not necessary and VSCode is a great counter example (not crazy fast, but faster than many “native” apps).

I think the HN crowd has invested so much emotional energy into hating electron they literally can’t think straight about it, including just admitting that this is no more native than any electron app.

In fact, if you take native to mean some combination of “using OS APIs” and “accessibility support and behavior similar to the OS”, then electron wins hands down because of the latter part: font rendering, text selection, input controls, copy and paste, everything mostly just works like native. It’s the Lua app that I’d say is far less native. It’s just a bit faster.