4 ms·

OK, I'll bite. What's your definition of "native" that conforms to your intuition and works equally well for all platforms (iOS, Android, Windows, Mac, Linux, .

OK, I'll bite. What's your definition of "native" that conforms to your intuition and works equally well for all platforms (iOS, Android, Windows, Mac, Linux, ...)? Don't get me wrong, I think there are plenty of reasons to hate Electron, but this shouldn't be one of them.

guelo 7y ago
Native means that you're programming against the platform's APIs.
- inimino 7y ago
  OK, which ones?
  - guelo 7y ago
    Whichever ones the platform ships with.
    - inimino 7y ago
      Well, I mean, do you have to use all of them? Where do you draw the line? Does using any third-party library make something non-native? With languages that compile to other languages, toolkits that wrap or abstract other toolkits, it's not so cut and dried. It seems to me a bit like arguing over whether or not something is a scripting language. The specific characteristics of the technology matter, but which side of an imaginary line it falls on does not.
      - guelo 7y ago
        Ok I can see what you mean. It's a continuum, the fatter the library or "framework" the less native it is.
quietbritishjim 7y ago
I suppose "native" has at least two different meanings: * In programming, it means compiled to CPU machine code ahead of execution. So C++ and Rust count, but interpreted languages like Python (on CPython) do not, and JIT-compiled languages like C#, Java, JavaScript and Python (on PyPy) do not. (An exception is Java on Android, which is compiled to machine code on installation so is actually native.) * In GUIs, it means using the graphical widgets provided by the platform itself. This is the only way to really guarantee the widgets are consistent with other applications, including all the niggly features like hotkeys and accessibility. A key differentiator from using a toolkit that attempts to mimic the platform's native widgets is that if the platform changes appearance or behaviour in future (e.g. a new version of Windows changes the visual style of combo boxes) then your application changes appearance without requiring a new version to be downloaded. I don't think Electron satisfies either of these. Edit: If a platform ships without any native way to create widgets – if using a toolkit that draws them manually is your only choice – then even that doesn't invalidate the definition of native (in the GUI sense). It just means that, on that platform, the answer to "is this a native GUI?" is always "no, there's no such thing on this platform".
- inimino 7y ago
  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.
  - 7y ago
ptx 7y ago
How about this definition? Native means that it doesn't work equally well on all platforms but is clearly designed in the context of one single specific platform (although that platform could arguably be layered on top of another platform). If I were a native German, I wouldn't work equally well if suddenly dropped in the middle of France – I would be confused about the language, the geography, the culture, etc. So if someone designs, for example, a window system with support for sound and vector graphics (these being the defining features of the system), a native application for this system would be one that uses the characteristic built-in features of the system to create windows, play sound and draw vector graphics, the expression of the application being shaped by the nuances of how these things work on this particular system. A non-native application would be one that abstracts windows, sound and graphics to work equally well on all kinds of systems and hides the peculiarities (or advantages) of this specific system.

guelo 7y ago

Native means that you're programming against the platform's APIs.

inimino 7y ago
OK, which ones?
- guelo 7y ago
  Whichever ones the platform ships with.
  - inimino 7y ago
    Well, I mean, do you have to use all of them? Where do you draw the line? Does using any third-party library make something non-native? With languages that compile to other languages, toolkits that wrap or abstract other toolkits, it's not so cut and dried. It seems to me a bit like arguing over whether or not something is a scripting language. The specific characteristics of the technology matter, but which side of an imaginary line it falls on does not.
    - guelo 7y ago
      Ok I can see what you mean. It's a continuum, the fatter the library or "framework" the less native it is.

quietbritishjim 7y ago

I suppose "native" has at least two different meanings: * In programming, it means compiled to CPU machine code ahead of execution. So C++ and Rust count, but interpreted languages like Python (on CPython) do not, and JIT-compiled languages like C#, Java, JavaScript and Python (on PyPy) do not. (An exception is Java on Android, which is compiled to machine code on installation so is actually native.) * In GUIs, it means using the graphical widgets provided by the platform itself. This is the only way to really guarantee the widgets are consistent with other applications, including all the niggly features like hotkeys and accessibility. A key differentiator from using a toolkit that attempts to mimic the platform's native widgets is that if the platform changes appearance or behaviour in future (e.g. a new version of Windows changes the visual style of combo boxes) then your application changes appearance without requiring a new version to be downloaded. I don't think Electron satisfies either of these. Edit: If a platform ships without any native way to create widgets – if using a toolkit that draws them manually is your only choice – then even that doesn't invalidate the definition of native (in the GUI sense). It just means that, on that platform, the answer to "is this a native GUI?" is always "no, there's no such thing on this platform".

inimino 7y ago
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.
- 7y ago

ptx 7y ago

How about this definition? Native means that it doesn't work equally well on all platforms but is clearly designed in the context of one single specific platform (although that platform could arguably be layered on top of another platform). If I were a native German, I wouldn't work equally well if suddenly dropped in the middle of France – I would be confused about the language, the geography, the culture, etc. So if someone designs, for example, a window system with support for sound and vector graphics (these being the defining features of the system), a native application for this system would be one that uses the characteristic built-in features of the system to create windows, play sound and draw vector graphics, the expression of the application being shaped by the nuances of how these things work on this particular system. A non-native application would be one that abstracts windows, sound and graphics to work equally well on all kinds of systems and hides the peculiarities (or advantages) of this specific system.