6 ms·

Nice write up; agree with some thoughts, disagree with others. Think this is daft though: > The word "native" has always bothered me. No one can seem to agree

Nice write up; agree with some thoughts, disagree with others. Think this is daft though: > The word "native" has always bothered me. No one can seem to agree on a definition, but we all agree that "native apps" are always optimal. > I propose the following alternative definition of native: an app that behaves to the quality standards of the platform it's deployed to. > A well engineered Electron app will give you "native" platform fidelity, regardless of programming language. These are simply things I disagree with, and I find it troubling to see them promoted, because I've heard them before, recently, in person, from colleague. You can argue that 'native is better' or not, but really? Do we have to fuss around with wording and pretend there's some magical alternative definition of what native means, in order for us to cool and be writing 'native' apps? If I define 'native' as, written using sql, can I run 'native' queries in my database? I mean, I get it; the point is that native may not be best, for many reasons. ...but it bothers me that I've heard people talking about how to define native; imo if you've gone down the rabbit hole of 'define all your terms to mean custom things' so you can call whatever you're doing whatever you like, you've lost the plot, and you're deliberately deceiving people. That's bad behaviour, and I don't respect it.

mpalmer 7y ago
> You can argue that 'native is better' or not, but really? Do we have to fuss around with wording and pretend there's some magical alternative definition of what native means, in order for us to cool and be writing 'native' apps? The guy is running a business. The word native doesn't make him "feel cool", it's a valuable marketing term that means little more to consumers than "fast". Do consumers care how fast apps are designed? Whether performance gains are thanks to the thought given to the content delivery and deployment vs the programming language it was written in? They couldn't care less! Who are we protecting by steering clear of the "rabbit hole"? I'll concede that terms like web native are clearer than using native as a catch-all term. But I cosign wholeheartedly on defining native as an app's proximity to the full power of its platform. Whether that's web, iOS, Android. etc. Put the focus on the platforms. When used to their full potential, how do they stack up on performance? Platforms that compete on improving user perceptions of app performance are healthy platforms. This isn't bad behavior, it's an attempt to have a conversation that you are ending rather abruptly.
Waterluvian 7y ago
It's an attempt to rebrand because "native" = good. There are certainly Electron apps that you can't really tell are not "native". They work fine. People who are passionate about something, be it computers or cars or food, tend to obsess over what their passion is built from and not purely on the end result. To laypeople, the end result is all that really matters. I've never once asked to tour a kitchen. But to the nerds, it's really important what their apps are made of, even if the end result is the same. So "native" becomes a contentious word. An insult, even, when the contrary is argued.
- arsenico 7y ago
  Can you give an example of such Electron apps, for which you can't tell they're not "native"? Not trying to nitpick or anything, just curious.
  - Waterluvian 7y ago
    Vscode comes to mind. Now of course some people will exclaim that it's horribly clunky and slow the way some people exclaim that they need 120hz TVs because 60hz is awful. That's fine. But despite that, Vscode is fine.
    - samastur 7y ago
      Fine is not the same as feeling or behaving native (which at least it didn't when I tried it).
inimino 7y ago
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".

mpalmer 7y ago

> You can argue that 'native is better' or not, but really? Do we have to fuss around with wording and pretend there's some magical alternative definition of what native means, in order for us to cool and be writing 'native' apps? The guy is running a business. The word native doesn't make him "feel cool", it's a valuable marketing term that means little more to consumers than "fast". Do consumers care how fast apps are designed? Whether performance gains are thanks to the thought given to the content delivery and deployment vs the programming language it was written in? They couldn't care less! Who are we protecting by steering clear of the "rabbit hole"? I'll concede that terms like web native are clearer than using native as a catch-all term. But I cosign wholeheartedly on defining native as an app's proximity to the full power of its platform. Whether that's web, iOS, Android. etc. Put the focus on the platforms. When used to their full potential, how do they stack up on performance? Platforms that compete on improving user perceptions of app performance are healthy platforms. This isn't bad behavior, it's an attempt to have a conversation that you are ending rather abruptly.

Waterluvian 7y ago

It's an attempt to rebrand because "native" = good. There are certainly Electron apps that you can't really tell are not "native". They work fine. People who are passionate about something, be it computers or cars or food, tend to obsess over what their passion is built from and not purely on the end result. To laypeople, the end result is all that really matters. I've never once asked to tour a kitchen. But to the nerds, it's really important what their apps are made of, even if the end result is the same. So "native" becomes a contentious word. An insult, even, when the contrary is argued.

arsenico 7y ago
Can you give an example of such Electron apps, for which you can't tell they're not "native"? Not trying to nitpick or anything, just curious.
- Waterluvian 7y ago
  Vscode comes to mind. Now of course some people will exclaim that it's horribly clunky and slow the way some people exclaim that they need 120hz TVs because 60hz is awful. That's fine. But despite that, Vscode is fine.
  - samastur 7y ago
    Fine is not the same as feeling or behaving native (which at least it didn't when I tried it).

inimino 7y ago

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