7 ms·

The point isn't entirely that "true" native apps are superior, the point is really that WebView wrappers are no more a "native" application than a standard HTML

by Veratyr 10y ago

The point isn't entirely that "true" native apps are superior, the point is really that WebView wrappers are no more a "native" application than a standard HTML web application, because that's exactly what they are and pretending otherwise is deceptive. As for applications built with OS components being inherently better, there are a few reasons for me: - They are guaranteed to fit in with OS styling - They near-universally perform better (and I don't see how this can change, given the way browsers are forced to render things) - The underlying functionality is written in native code, which allows for optimizations that cannot be made on web applications - They don't have the insane and unnecessary bloat of a modern web browser attached.

elmigranto 10y ago
> - They are guaranteed to fit in with OS styling They aren't. For example, if you move your cursor to a word in macOS, and force touch, pop up will appear with word's definition from Dictionary.app. This is not a case in "native" applications that render text differently, Sublime Text is my offender, but there must be others. So "guarantee" is too strong of a word.
- Veratyr 10y ago
  That was in reference to the use of OS-provided components, which by definition have the same styling as the OS. Your point that native applications don't always have to use OS-provided components is taken though.
- OD_ 10y ago
  But sublime isn't really a native app either. When did we start corrupting the meaning of native? When electron apps appeared, and we wanted to divide "compiled" versus "interpreted webapps" on the desktop? Cross platform toolkits, be it proprietary, one-off like Sublime's, or things like Qt, GTK, WxWidgets, Java Swing, were NEVER considered native. Just because an app is written in C or C++ doesn't make it platform native. Textmate is a native editor for MacOS. Sublime is not.
  - kwood 10y ago
    How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition? And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrated with GTK? If not, does that mean as soon as you use any kind of binding/bridging technology "nativeness" is ruled out? Think of C++ apps for Gnome, they use bindings… If yes, we are only left with defining what the "official" way for doing GUI's on a given platform is. Whatever the vendor gives us and preinstalls on its OS? Ok, no Electron, it uses the Chrome rendering engine, that is definitely third party and NOT native! But… What if I open a WebKit WebView from Objective-C[2] to render my HTML from there and write my logic making use of JavaScriptCore[3] on macOS? Are we native yet? :) [1]: https://developer.gnome.org/gnome-devel-demos/stable/beginner.js.html.en https://developer.gnome.org/gnome-devel-demos/stable/beginne... [2]: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DisplayWebContent/DisplayWebContent.html https://developer.apple.com/library/content/documentation/Co... [3]: https://developer.apple.com/reference/javascriptcore https://developer.apple.com/reference/javascriptcore
    - OD_ 10y ago
      > How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition? >And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrated with GTK? Actually, yes, by definition a javascript app written with gobjects is native to a Gnome desktop. It fully integrates with the standards of the system be it text boxes, keyboard shortcuts, general behavior and widget look. The most important, even more than our personal little preferences, is that a native app can be accessed by things like screen readers which is the only way for a person with a disabled sight to use a computer. Anything not written with GTK on Linux is going to be a black box for Orca. In fact webapps would be less of a pain than a compiled app that uses a random crappy cross platform toolkit. While the web's accessibility could do with some improvements, it's still better than the absolute nothing that cross platform toolkit represents. Sometimes devs put extra effort into making cross platforms apps accessible but they're the exception rather than the norm : https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-programmer/ https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-pro... The reason being is that native apps get "most of the work" done for them for free when they use the native tools to make apps, while cross platform apps require a severe amount of work to get them to talk to screen readers correctly. Android Studio seems to be gaining on that side despite the original platform being pretty poor. And of course Sublime Text is absolutely unusable in that scenario. Some apps do crossplatform the right way, although they're rare: they have have a platform-specific GUI rather than use a generic cross toolkit. Transmission is a solid example : https://transmissionbt.com/ https://transmissionbt.com/ The app has a Cocoa, GTK, Qt, TUI and Web end user interface. It's native on all the officially supported OSes. There's a non-native, Qt-using windows port but it's a third party fork and not supported by the main devs.
a85 10y ago
I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language. - HTML based components can be made to fit into OS styling quite readily and by keymapping shortcuts you can get the exact functionality as native OS controls. Most HTML components don't have keyboard shortcuts mapped properly as the browser takes over. This is not the case with Electron. - They can perform equally well. The web platform itself is an example of this. Browsers have improved quite rapidly over the past few years. - Optimizations can be made in JS code as well. Other comments here have some examples. The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) The JS ecosystem has grown much faster and will continue to do so. The building blocks that are available will also improve in quality and I believe that more and more developers chosing Electron will speed up this process.
- Veratyr 10y ago
  > Users don't use things because they are developed in a particular language. If the users in question were the standard near tech-illiterate masses, you might have a case but we're talking about a developer tool in this specific instance. I'd also suggest that you go take a look at the reviews on the Android app store for most banking apps, which are typically webviews. They're nearly always terrible and often due to the webview itself. Users don't distinguish between native and webview wrappers because they don't understand the common factor in the terrible experiences they're subjected to. > HTML based components can be made to fit into OS styling quite readily Yes, this is technically possible but I'm yet to see someone actually do it. > and by keymapping shortcuts you can get the exact functionality as native OS controls. To do this properly requires the developer to implement keymapping properly, which again, is possible but I very very rarely see it done. > They can perform equally well. No, they cannot. HTML components are always burdened by the overhead of a browser. At absolute best, you can come somewhat close. Futher, performance includes not just UI latency but the CPU and memory impact on the machine, which again, can never match true native apps due to the overhead of the browser, which is insane. > Optimizations can be made in JS code as well. Unless something extreme has happened in JS runtimes recently, you can't optimize your code to use SIMD instructions and parallelize, you have to leave that to the compiler. In native code this is not the case. > The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead.
kitsunesoba 10y ago
I would add consistent widget behavior to the list of benefits. More often than not, controls in browser hybrids and web apps fail to take all kinds of little subtleties (some of which are platform specific) into account, dragging down user experience by way of death by a thousand cuts. This can be compensated for obviously, but I'd argue that the time and energy tied up addressing these finer points (which can be quite significant) would be better spent on what your product actually does and the user experience surrounding that.
- kartickv 10y ago
  That's a great point, but does addressing these finer points take more time than building two separate apps, for Mac and Windows? Or if a service doesn't find it feasible to build two native apps, aren't their users better off with an Electron app than accessing the web app in their browser? For example, Simplenote has an Electron app for the Mac, and I much prefer that to having to use simplenote.com in a browser.
  - kitsunesoba 10y ago
    I think there's a lot of variables at play, all of which need to be considered. The answer won't be the same for everybody. To me the ideal candidate for electron is moderate complexity with an audience that's likely to value day-1 cross-platform support over other factors. If it veers toward the simpler side of things like Simplenote, electron is overkill, as developing separate native front ends isn't going to pose too much of a challenge (especially if platform agnostic code is shared). On the other end of the spectrum with a high complexity app (e.g. same class as Photoshop, Maya, etc), you're frequently going to find yourself at odds with the limits and performance issues of web tech and whatever conveniences it affords you are largely rendered moot. As for if a wrapper offers value, with ever increasing OS-browser integration I'd say whatever value that's there is quickly being eroded. Personally, if I have the choice of running an Electron wrapped-web-app vs. running a web app in my browser and a true native app isn't available, I'll take the latter in most cases for the greater control it affords me. It allows me to take resource consumption into my own hands (to an extent) by choosing Safari or Firefox instead of embedded Chromium and it lets me controls what scripts are running, what domains are being accessed, etc.
dkersten 10y ago
- They often (although certainly not always) use less battery

by Veratyr 10y ago

elmigranto 10y ago

> - They are guaranteed to fit in with OS styling They aren't. For example, if you move your cursor to a word in macOS, and force touch, pop up will appear with word's definition from Dictionary.app. This is not a case in "native" applications that render text differently, Sublime Text is my offender, but there must be others. So "guarantee" is too strong of a word.

Veratyr 10y ago
That was in reference to the use of OS-provided components, which by definition have the same styling as the OS. Your point that native applications don't always have to use OS-provided components is taken though.
OD_ 10y ago
But sublime isn't really a native app either. When did we start corrupting the meaning of native? When electron apps appeared, and we wanted to divide "compiled" versus "interpreted webapps" on the desktop? Cross platform toolkits, be it proprietary, one-off like Sublime's, or things like Qt, GTK, WxWidgets, Java Swing, were NEVER considered native. Just because an app is written in C or C++ doesn't make it platform native. Textmate is a native editor for MacOS. Sublime is not.
- kwood 10y ago
  How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition? And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrated with GTK? If not, does that mean as soon as you use any kind of binding/bridging technology "nativeness" is ruled out? Think of C++ apps for Gnome, they use bindings… If yes, we are only left with defining what the "official" way for doing GUI's on a given platform is. Whatever the vendor gives us and preinstalls on its OS? Ok, no Electron, it uses the Chrome rendering engine, that is definitely third party and NOT native! But… What if I open a WebKit WebView from Objective-C[2] to render my HTML from there and write my logic making use of JavaScriptCore[3] on macOS? Are we native yet? :) [1]: https://developer.gnome.org/gnome-devel-demos/stable/beginner.js.html.en https://developer.gnome.org/gnome-devel-demos/stable/beginne... [2]: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DisplayWebContent/DisplayWebContent.html https://developer.apple.com/library/content/documentation/Co... [3]: https://developer.apple.com/reference/javascriptcore https://developer.apple.com/reference/javascriptcore
  - OD_ 10y ago
    > How would you create a native GUI app on Linux for either Gnome or KDE, considering that GTK and Qt are not allowed by this definition? >And yes, you may think: "Easy, if a GTK app runs on Linux its native, if it runs on another platform, it's not". Does that mean JavaScript apps for Gnome[1] can be called native, because they have officially blessed bindings to the underlying framework/platform and are fully integrated with GTK? Actually, yes, by definition a javascript app written with gobjects is native to a Gnome desktop. It fully integrates with the standards of the system be it text boxes, keyboard shortcuts, general behavior and widget look. The most important, even more than our personal little preferences, is that a native app can be accessed by things like screen readers which is the only way for a person with a disabled sight to use a computer. Anything not written with GTK on Linux is going to be a black box for Orca. In fact webapps would be less of a pain than a compiled app that uses a random crappy cross platform toolkit. While the web's accessibility could do with some improvements, it's still better than the absolute nothing that cross platform toolkit represents. Sometimes devs put extra effort into making cross platforms apps accessible but they're the exception rather than the norm : https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-programmer/ https://www.parhamdoustdar.com/2016/04/03/tools-of-blind-pro... The reason being is that native apps get "most of the work" done for them for free when they use the native tools to make apps, while cross platform apps require a severe amount of work to get them to talk to screen readers correctly. Android Studio seems to be gaining on that side despite the original platform being pretty poor. And of course Sublime Text is absolutely unusable in that scenario. Some apps do crossplatform the right way, although they're rare: they have have a platform-specific GUI rather than use a generic cross toolkit. Transmission is a solid example : https://transmissionbt.com/ https://transmissionbt.com/ The app has a Cocoa, GTK, Qt, TUI and Web end user interface. It's native on all the officially supported OSes. There's a non-native, Qt-using windows port but it's a third party fork and not supported by the main devs.

a85 10y ago

I wouldn't say it is pretending if the end user experience is the same. Users don't use things because they are developed in a particular language. - HTML based components can be made to fit into OS styling quite readily and by keymapping shortcuts you can get the exact functionality as native OS controls. Most HTML components don't have keyboard shortcuts mapped properly as the browser takes over. This is not the case with Electron. - They can perform equally well. The web platform itself is an example of this. Browsers have improved quite rapidly over the past few years. - Optimizations can be made in JS code as well. Other comments here have some examples. The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) The JS ecosystem has grown much faster and will continue to do so. The building blocks that are available will also improve in quality and I believe that more and more developers chosing Electron will speed up this process.

Veratyr 10y ago
> Users don't use things because they are developed in a particular language. If the users in question were the standard near tech-illiterate masses, you might have a case but we're talking about a developer tool in this specific instance. I'd also suggest that you go take a look at the reviews on the Android app store for most banking apps, which are typically webviews. They're nearly always terrible and often due to the webview itself. Users don't distinguish between native and webview wrappers because they don't understand the common factor in the terrible experiences they're subjected to. > HTML based components can be made to fit into OS styling quite readily Yes, this is technically possible but I'm yet to see someone actually do it. > and by keymapping shortcuts you can get the exact functionality as native OS controls. To do this properly requires the developer to implement keymapping properly, which again, is possible but I very very rarely see it done. > They can perform equally well. No, they cannot. HTML components are always burdened by the overhead of a browser. At absolute best, you can come somewhat close. Futher, performance includes not just UI latency but the CPU and memory impact on the machine, which again, can never match true native apps due to the overhead of the browser, which is insane. > Optimizations can be made in JS code as well. Unless something extreme has happened in JS runtimes recently, you can't optimize your code to use SIMD instructions and parallelize, you have to leave that to the compiler. In native code this is not the case. > The advantages of having a cross platform application developed in 1/3rd the time especially for new applications are huge (faster time to market, larger number of people for validation) I'm not entirely sure the premise here is accurate. I suspect that an experienced Qt developer could produce a basic native application in roughly the same time as an Electron developer, but with a fraction of the overhead.

kitsunesoba 10y ago

I would add consistent widget behavior to the list of benefits. More often than not, controls in browser hybrids and web apps fail to take all kinds of little subtleties (some of which are platform specific) into account, dragging down user experience by way of death by a thousand cuts. This can be compensated for obviously, but I'd argue that the time and energy tied up addressing these finer points (which can be quite significant) would be better spent on what your product actually does and the user experience surrounding that.

kartickv 10y ago
That's a great point, but does addressing these finer points take more time than building two separate apps, for Mac and Windows? Or if a service doesn't find it feasible to build two native apps, aren't their users better off with an Electron app than accessing the web app in their browser? For example, Simplenote has an Electron app for the Mac, and I much prefer that to having to use simplenote.com in a browser.
- kitsunesoba 10y ago
  I think there's a lot of variables at play, all of which need to be considered. The answer won't be the same for everybody. To me the ideal candidate for electron is moderate complexity with an audience that's likely to value day-1 cross-platform support over other factors. If it veers toward the simpler side of things like Simplenote, electron is overkill, as developing separate native front ends isn't going to pose too much of a challenge (especially if platform agnostic code is shared). On the other end of the spectrum with a high complexity app (e.g. same class as Photoshop, Maya, etc), you're frequently going to find yourself at odds with the limits and performance issues of web tech and whatever conveniences it affords you are largely rendered moot. As for if a wrapper offers value, with ever increasing OS-browser integration I'd say whatever value that's there is quickly being eroded. Personally, if I have the choice of running an Electron wrapped-web-app vs. running a web app in my browser and a true native app isn't available, I'll take the latter in most cases for the greater control it affords me. It allows me to take resource consumption into my own hands (to an extent) by choosing Safari or Firefox instead of embedded Chromium and it lets me controls what scripts are running, what domains are being accessed, etc.

dkersten 10y ago

- They often (although certainly not always) use less battery