Or are you drawing the line because Lua is a scripting language?

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.

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.

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.

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.

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.

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

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.

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.

Edit: What does LAF stand for?

The rest of the application, being in Java, will often means it will have your typical JVM high memory usage and slow startup times.

What is the material difference?

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.

Not using a full blown web rendering engine (if that's the case) but OS painting (not necessarily GUI) APIs would make it much more native in my eyes...

It's more "native" because the stack is much shorter, much more direct. If it was more common to have plain JS interacting directly with input APIs and plain canvas, the argument for parity would be stronger. But it's just very rarely the case.

It is not running on a web browser shaped to act like a text editor instead.

It's a webscripting language. Which is totally fine but it will never be native.

There needs to be focus on building tooling that enables rapid development of native applications. GTK is a good example. Glade is a perfectly fine editor, but the underlying tooling for GTK is a mixed bag.

I think this is less true when you don't assume people know all about web tech already, IOW there would be less of a difference for someone coming into software dev completely naive of web tech.

> There needs to be focus on building tooling that enables rapid development of native applications.

Fully agree.

Move fast and break things has become the cancer of software engineering.

Because as you said "It's certainly not perfect yet"