4 ms·

Fair enough. At that point, the term excludes so much that I don't think it really has much value. At least, I don't think it's easy to argue that "compiled to

Fair enough. At that point, the term excludes so much that I don't think it really has much value. At least, I don't think it's easy to argue that "compiled to machine code ahead of execution" is something that a user would care about. If you define the things the user actually does care about (fast start up time, fast response to input) then you're back to defining things that are user-visible rather than things that are not. If native means "fast and matches the default look and feel", then to the extent that the user can tell the difference, anything that is not native is worse. But if the user can't tell the difference, then it doesn't really matter whether it is "truly" native or not. I think most people saying that Electron gives you native-like performance or look-and-feel are kidding themselves, which may be a reasonable criticism of Electron apps, but let's criticize them on the user-visible characteristics, not on the technology used to get there. According to your definition, would MS Office be a native Windows app? I think not, on at least two counts.

quietbritishjim 7y ago
> I don't think it's easy to argue that "compiled to machine code ahead of execution" is something that a user would care about. I never said that a user should care about whether a program is native, at least in the coding sense. The GP comment also never claimed that native is better, just that it's factually untrue about Electron. As an analogy, a user shouldn't care whether you used camel case or snake case for identifiers in your code, but that doesn't mean we should declare that "all code is written in camel case" just because you can't tell when you use the program. In practice, of course, it's often the case that native code is faster and uses less memory than non-native code. (This is certainly obvious every time you use a JetBrains IDE, much as I love them, which are written in Java.) But if your app is non-native but still fast and low memory then just directly say that it's fast and low memory, don't pretend that it's native or even bring the subject up. For native GUI widgets this does make a much more direct user impact. But if a toolkit has extremely high fidelity to the native controls then it's a true a user wouldn't care. Again, I'd say it's factually incorrect to describe that as native but saying it's indistinguishable from native widgets seems like a reasonable thing to say about an application. As for MS Office, as I've already said it doesn't make any difference to me as user whether it's native code but as it happens I'm pretty sure it's mostly written in C++ (it certainly used to be). The ribbon is not a native control but a lot of the rest of the dialog boxes are - just look at the font or page layout dialogue in Word, and it certainly uses the native Windows file open/close dialogues once you dive deeply enough into its file menu/tab to open them. So I'd say even from the GUI perpespective it's mostly native with a few custom controls.
- inimino 7y ago
  It's a reasonable perspective, but I think it's also reasonable to point out that "native" is not just used as a technical term but also used a shorthand for all those benefits that the user really does care about. So "fast, standard widgets, and conforms to UI conventions of the environment" is a useful enough group of characteristics that I think it's natural that people are going to use the term to describe them. It's precisely because non-native apps are generally worse on all counts, so if you can go to the trouble of making something that is just as good, people are going to want to label it that way, and if the technology used doesn't affect the user experience in any way, it doesn't need to be mentioned. And I would say Office is native on Windows, I don't see how the flagship product written for that OS could be considered anything but. Even if they wrote the entire UI in an interpreted language and used all custom widgets, that would still be true according to my definition.

quietbritishjim 7y ago

> I don't think it's easy to argue that "compiled to machine code ahead of execution" is something that a user would care about. I never said that a user should care about whether a program is native, at least in the coding sense. The GP comment also never claimed that native is better, just that it's factually untrue about Electron. As an analogy, a user shouldn't care whether you used camel case or snake case for identifiers in your code, but that doesn't mean we should declare that "all code is written in camel case" just because you can't tell when you use the program. In practice, of course, it's often the case that native code is faster and uses less memory than non-native code. (This is certainly obvious every time you use a JetBrains IDE, much as I love them, which are written in Java.) But if your app is non-native but still fast and low memory then just directly say that it's fast and low memory, don't pretend that it's native or even bring the subject up. For native GUI widgets this does make a much more direct user impact. But if a toolkit has extremely high fidelity to the native controls then it's a true a user wouldn't care. Again, I'd say it's factually incorrect to describe that as native but saying it's indistinguishable from native widgets seems like a reasonable thing to say about an application. As for MS Office, as I've already said it doesn't make any difference to me as user whether it's native code but as it happens I'm pretty sure it's mostly written in C++ (it certainly used to be). The ribbon is not a native control but a lot of the rest of the dialog boxes are - just look at the font or page layout dialogue in Word, and it certainly uses the native Windows file open/close dialogues once you dive deeply enough into its file menu/tab to open them. So I'd say even from the GUI perpespective it's mostly native with a few custom controls.

inimino 7y ago
It's a reasonable perspective, but I think it's also reasonable to point out that "native" is not just used as a technical term but also used a shorthand for all those benefits that the user really does care about. So "fast, standard widgets, and conforms to UI conventions of the environment" is a useful enough group of characteristics that I think it's natural that people are going to use the term to describe them. It's precisely because non-native apps are generally worse on all counts, so if you can go to the trouble of making something that is just as good, people are going to want to label it that way, and if the technology used doesn't affect the user experience in any way, it doesn't need to be mentioned. And I would say Office is native on Windows, I don't see how the flagship product written for that OS could be considered anything but. Even if they wrote the entire UI in an interpreted language and used all custom widgets, that would still be true according to my definition.