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.)

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.

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.

Actually, for a while Java was just below Cocoa for "nativeness" the LAF for it was maintained by Apple itself.

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?

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!

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.

Yes, and there is no reason you can't have a cow as a pet because they have pointy ears and a tail, like cats. It seems you've lost your way, my friend.

Why is using JS or WASM as a building block for a app any worse than lua, python or ruby?

What is the material difference?

The material difference is that this editor is an order of magnitude smaller than a browser. Sure, you can go "we have plenty of RAM/storage/battery these days", but consuming 10x more of every resource you can think of is quite the hint that you are not using the right tool for the right job, or that you do not employ the right person for the right job.

That's not because of JS or WASM, that's because of the browser. Using JS or WASM does not mean you need to use a browser, you can for example run quickjs, node or whatever other runtime without bundling a browser.

This editor could have been written in js and use the exact same libs for rendering. If it used one of the smaller js runtimes (like quickjs) I'm guessing it would have been similar in size and pretty close in performance.

I don't get why you are conflating using a certain language with bundling a full browser (like electron does). It's two completely different things.

What would the defining difference be between the two? "Forward" along what dimension?