5 ms·

I am not sure why something would be inherently superior if it is using pre-built OS components. Any software can have memory leaks, buggy behavior, weird input

by a85 10y ago

I am not sure why something would be inherently superior if it is using pre-built OS components. Any software can have memory leaks, buggy behavior, weird input issues etc. I'd rather look at the user experience and qualify something as better/worse after using it. Postman had issues in the beginning when we started porting things over but these were quickly solved and in fact gave us much more power over the experience.

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
viraptor 10y ago
Even if it's not superior, this is still false advertising. But, embedding the app in a browser always adds bloat - there's no way around that. It may not be obvious in case of huge apps, but there are many examples of trivial things shipped with electron - which make a simple single-dialog box app a 300MB monster.
- a85 10y ago
  I believe there is some inherent bias here with regards to existing experiences and as technology improves those biases will go away. I am not talking about simple single-dialog box based apps either or advocating every single piece of software should be written as an Electron based app.
  - viraptor 10y ago
    As I wrote - it may not be obvious in case of huge apps. But the bloat is still there. It may be a good idea if it saves time for the dev team. But as you said, there's still a lot of tech improvement to be done for the experience. And some things you're just not going to get around. Objects are heavier than their equivalents in native code. You still have a whole copy of the browser runtime to ship. These things will not go away. You're going to waste resources compared to an actual native app.
    - a85 10y ago
      What you define as bloat depends on the system where you expect things to be running on. If we were building a super thin client which probably runs on a low memory device - it's worth saving the bloat on memory and CPU. Saving dev team time is exponentially rewarding as a product matures. I'd rather say that as the team gets better at saving dev time on testing and platform parity, they can use that to optimize the experience across all platforms simultaneously. Meanwhile, if you are a small startup (like we are), you would have validated your business proposition and have a larger team to take bigger challenges. That's exactly what we have seen in our experience.
Mithaldu 10y ago
Have a 100% solid reason why: There's already too many of them, and some hardware doesn't like having too many chrome instances running at once. My PC is an i7 with 4 hyper-threaded cores, and an Nvidia Quadro 2000M. I usually have running, as far as electron goes: Chrome, Discord, remote-working app. As soon as i add another electron app to the mix the hardware interrupt activity of my machine goes out of control, presumably because too many chrome instances are trying to share the same device for hardware acceleration. This never happens with non-electron software.
- a85 10y ago
  We'll investigate if that causes issues with Postman. I haven't faced that problem and I don't think there is a hard limitation on the platform where it can't be optimized. Hardware acceleration is not something that happens continuously - only when things are rendering. More true for games than desktop software perhaps.
  - Mithaldu 10y ago
    I know it's a rare case, and i haven't been able to reproduce it 100% reliable, but in most cases when 4+ chromes want to do stuff, my hardware goes "nope, fuck that" and degrades performance for everything while spooling the CPU up noticably. The same hardware handles a single chrome just fine even when doing full-on 3d stuff. Sometimes just scrolling through twitter with 3 electron apps running starts the stutters. So for me electron apps are simply only viable if i absolutely need them, and i curse the name of anyone who thinks they're a good idea for anything but rapid prototyping every single day. Mind, i'm aware you have what you have right now, and going another path would be quite the expenditure. However i think it's not much to ask to refrain from calling it native, when it's actually electron, and thus helping people impacted by this kind of performance issue figure out that your app is one of the contributing ones.
    - a85 10y ago
      Hmm. If you are on Postman, I'd love to get your help in debugging this. Performance issues that I have seen exist at massive scale for us - ~10K requests or hundreds of collections. Of course, working on optimizing for all of these cases.

by a85 10y ago

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

viraptor 10y ago

Even if it's not superior, this is still false advertising. But, embedding the app in a browser always adds bloat - there's no way around that. It may not be obvious in case of huge apps, but there are many examples of trivial things shipped with electron - which make a simple single-dialog box app a 300MB monster.

a85 10y ago
I believe there is some inherent bias here with regards to existing experiences and as technology improves those biases will go away. I am not talking about simple single-dialog box based apps either or advocating every single piece of software should be written as an Electron based app.
- viraptor 10y ago
  As I wrote - it may not be obvious in case of huge apps. But the bloat is still there. It may be a good idea if it saves time for the dev team. But as you said, there's still a lot of tech improvement to be done for the experience. And some things you're just not going to get around. Objects are heavier than their equivalents in native code. You still have a whole copy of the browser runtime to ship. These things will not go away. You're going to waste resources compared to an actual native app.
  - a85 10y ago
    What you define as bloat depends on the system where you expect things to be running on. If we were building a super thin client which probably runs on a low memory device - it's worth saving the bloat on memory and CPU. Saving dev team time is exponentially rewarding as a product matures. I'd rather say that as the team gets better at saving dev time on testing and platform parity, they can use that to optimize the experience across all platforms simultaneously. Meanwhile, if you are a small startup (like we are), you would have validated your business proposition and have a larger team to take bigger challenges. That's exactly what we have seen in our experience.

Mithaldu 10y ago

Have a 100% solid reason why: There's already too many of them, and some hardware doesn't like having too many chrome instances running at once. My PC is an i7 with 4 hyper-threaded cores, and an Nvidia Quadro 2000M. I usually have running, as far as electron goes: Chrome, Discord, remote-working app. As soon as i add another electron app to the mix the hardware interrupt activity of my machine goes out of control, presumably because too many chrome instances are trying to share the same device for hardware acceleration. This never happens with non-electron software.

a85 10y ago
We'll investigate if that causes issues with Postman. I haven't faced that problem and I don't think there is a hard limitation on the platform where it can't be optimized. Hardware acceleration is not something that happens continuously - only when things are rendering. More true for games than desktop software perhaps.
- Mithaldu 10y ago
  I know it's a rare case, and i haven't been able to reproduce it 100% reliable, but in most cases when 4+ chromes want to do stuff, my hardware goes "nope, fuck that" and degrades performance for everything while spooling the CPU up noticably. The same hardware handles a single chrome just fine even when doing full-on 3d stuff. Sometimes just scrolling through twitter with 3 electron apps running starts the stutters. So for me electron apps are simply only viable if i absolutely need them, and i curse the name of anyone who thinks they're a good idea for anything but rapid prototyping every single day. Mind, i'm aware you have what you have right now, and going another path would be quite the expenditure. However i think it's not much to ask to refrain from calling it native, when it's actually electron, and thus helping people impacted by this kind of performance issue figure out that your app is one of the contributing ones.
  - a85 10y ago
    Hmm. If you are on Postman, I'd love to get your help in debugging this. Performance issues that I have seen exist at massive scale for us - ~10K requests or hundreds of collections. Of course, working on optimizing for all of these cases.