5 ms·

There’s way less abstraction going on in Lua app that has a hand-rolled GUI versus an app built on top of a web browser like Electron. Hand rolling you’re own U

There’s way less abstraction going on in Lua app that has a hand-rolled GUI versus an app built on top of a web browser like Electron. Hand rolling you’re own UI doesn’t make it less native — is Ableton Live not-native? Or are you drawing the line because Lua is a scripting language?

nwienert 6y ago
You seem to be the one drawing the line saying Electron isn’t vs something like this is. Is a WASM app that renders to WebGL native? I guess the point is native should probably mean “using the toolkit the OS provides” and we should just use “performant” in most cases.
- rhlsthrm 6y ago
  Can you make WASM apps using js toolkits that compiles to native desktop yet? Seems like that will be a huge step forward from electron apps.
  - sp332 6y ago
    What would the defining difference be between the two? "Forward" along what dimension?
  - SahAssar 6y ago
    Sure, as native as any language that runs in a VM. There is no reason a WASM app can or can't be any more or less native than something running on lua (like in this case), jvm or anything else. People don't use Electron to get a js runtime, they use it to get a web-like runtime. Any javascript (including WASM) app can run without electron in either node or in the bundled runtimes that OSX/Windows/Gnome/Whatever has, but the point of electron isn't to write JS, it's to write web-like code. For that it requires a browser in a predictable version, which is what electron gives you (albeit at a high cost.)
    - Wowfunhappy 6y ago
      So, obviously, "native" is a spectrum. On OS X, Cocoa > QT > Java > Wine > Docker + X11 forwarding. But one thing I think is being missed here is that Lua, Python, and other scripting languages are just a lot more resource efficient than electron, in terms of runtime size, memory usage, cpu usage, etc. A very highly optimized Electron app like VS Code might outperform a more run-of-the-mill Lua app, but that's an outlier.
      - saagarjha 6y ago
        Actually, for a while Java was just below Cocoa for "nativeness" the LAF for it was maintained by Apple itself.
        Wowfunhappy 6y ago
        I'd heard that before! I kind of debated whether to put Java or QT first—it came down to the fact that QT apps just feel closer to me on macOS. Although I don’t know how ugly they are under the hood. Edit: What does LAF stand for?
        saagarjha 6y ago
        LAF stands for "look and feel", which is basically Java's name for "UI theme". Another fun fact: Cocoa had official Java bindings at some point!
        didibus 6y ago
        The Java SWT toolkit uses Cocoa native widgets under the hood. So it is a native UI toolkit. That said, like parent said, native doesn't necessarily translate to a user experience of being performant. The rest of the application, being in Java, will often means it will have your typical JVM high memory usage and slow startup times.
      - SahAssar 6y ago
        You're comparing apples to oranges. Lua is a language runtime. Electron is a full browser and a language runtime. If you want to compare them then compare node.js or JavaScriptCore to lua. Or compare Electron with a lua runtime that has a webkit/chromium engine integration. I don't especially like Electron, and sometimes like writing lua, but the two are not solving the same problem or competing in the same space.
- giancarlostoro 6y ago
  Electron is like a whole framework say JVM or .NET but for JavaScript GUIs... Its definitely heavier than a few thousand lines of C and Lua vs the amount of code behind both Chrome and Node.
- didibus 6y ago
  I don't know how people are finding ways to contradict your comment. Native means using the native UI toolkit. Or if not about UIs, it can mean compiled to native machine code ahead of time. People used to care about native vs non-native because of the look and feel. Now people are complaining about performance, memory use, and startup times. Everyone would be happy using a non native toolkit if it was fast, used little memory and started quickly. Why can't we be precise with our language? We're engineers, it seems critical to use precise terminology. If you don't like the look and feels let's discuss that, if you don't like the memory use, let's discuss that, if you don't like the distribution or install size, let's discuss that.
  - nurettin 6y ago
    People mainly want their autocomplete, accessibility and double-click text to work the same everywhere. wxwidget guys on IRC used to showcase how their buttons titlebars and menus blended with the windows xp back in early 2000 but I'm sure they are past that at this point.
- jcelerier 6y ago
  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 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 6y ago
    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.
thomasqm 6y ago
Yep, it’s not Win32, it is a software renderer (according to renderer.c).
np_tedious 6y ago
What's ableton written in? Java / awt?
- jcelerier 6y ago
  Their own C++ UI toolkit mostly

nwienert 6y ago

You seem to be the one drawing the line saying Electron isn’t vs something like this is. Is a WASM app that renders to WebGL native? I guess the point is native should probably mean “using the toolkit the OS provides” and we should just use “performant” in most cases.

rhlsthrm 6y ago
Can you make WASM apps using js toolkits that compiles to native desktop yet? Seems like that will be a huge step forward from electron apps.
- sp332 6y ago
  What would the defining difference be between the two? "Forward" along what dimension?
- SahAssar 6y ago
  Sure, as native as any language that runs in a VM. There is no reason a WASM app can or can't be any more or less native than something running on lua (like in this case), jvm or anything else. People don't use Electron to get a js runtime, they use it to get a web-like runtime. Any javascript (including WASM) app can run without electron in either node or in the bundled runtimes that OSX/Windows/Gnome/Whatever has, but the point of electron isn't to write JS, it's to write web-like code. For that it requires a browser in a predictable version, which is what electron gives you (albeit at a high cost.)
  - Wowfunhappy 6y ago
    So, obviously, "native" is a spectrum. On OS X, Cocoa > QT > Java > Wine > Docker + X11 forwarding. But one thing I think is being missed here is that Lua, Python, and other scripting languages are just a lot more resource efficient than electron, in terms of runtime size, memory usage, cpu usage, etc. A very highly optimized Electron app like VS Code might outperform a more run-of-the-mill Lua app, but that's an outlier.
    - saagarjha 6y ago
      Actually, for a while Java was just below Cocoa for "nativeness" the LAF for it was maintained by Apple itself.
      - Wowfunhappy 6y ago
        I'd heard that before! I kind of debated whether to put Java or QT first—it came down to the fact that QT apps just feel closer to me on macOS. Although I don’t know how ugly they are under the hood. Edit: What does LAF stand for?
        saagarjha 6y ago
        LAF stands for "look and feel", which is basically Java's name for "UI theme". Another fun fact: Cocoa had official Java bindings at some point!
        didibus 6y ago
        The Java SWT toolkit uses Cocoa native widgets under the hood. So it is a native UI toolkit. That said, like parent said, native doesn't necessarily translate to a user experience of being performant. The rest of the application, being in Java, will often means it will have your typical JVM high memory usage and slow startup times.
    - SahAssar 6y ago
      You're comparing apples to oranges. Lua is a language runtime. Electron is a full browser and a language runtime. If you want to compare them then compare node.js or JavaScriptCore to lua. Or compare Electron with a lua runtime that has a webkit/chromium engine integration. I don't especially like Electron, and sometimes like writing lua, but the two are not solving the same problem or competing in the same space.
giancarlostoro 6y ago
Electron is like a whole framework say JVM or .NET but for JavaScript GUIs... Its definitely heavier than a few thousand lines of C and Lua vs the amount of code behind both Chrome and Node.
didibus 6y ago
I don't know how people are finding ways to contradict your comment. Native means using the native UI toolkit. Or if not about UIs, it can mean compiled to native machine code ahead of time. People used to care about native vs non-native because of the look and feel. Now people are complaining about performance, memory use, and startup times. Everyone would be happy using a non native toolkit if it was fast, used little memory and started quickly. Why can't we be precise with our language? We're engineers, it seems critical to use precise terminology. If you don't like the look and feels let's discuss that, if you don't like the memory use, let's discuss that, if you don't like the distribution or install size, let's discuss that.
- nurettin 6y ago
  People mainly want their autocomplete, accessibility and double-click text to work the same everywhere. wxwidget guys on IRC used to showcase how their buttons titlebars and menus blended with the windows xp back in early 2000 but I'm sure they are past that at this point.
jcelerier 6y ago
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 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 6y ago
  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.

thomasqm 6y ago

Yep, it’s not Win32, it is a software renderer (according to renderer.c).

np_tedious 6y ago

What's ableton written in? Java / awt?

jcelerier 6y ago
Their own C++ UI toolkit mostly