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.
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.
Your point that native applications don't always have to use OS-provided components is taken though.
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.
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/beginne...
[2]: https://developer.apple.com/library/content/documentation/Co...
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-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 :
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.
- 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.
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.
I am very well aware that our audience is a developer tool and well again, people do not use tools because of the languages they are written in but because of the experience they deliver. You are bringing up extreme examples to support your viewpoint. Bad developers will write terrible experiences in any language. Writing native apps requires a level of expertise that is not with the average developer either. Look at other comments in the thread talking about a "native" app going from good to bad.
> "HTML based components..."
Well, one of the reasons why one has not come up is that most users don't care about OS styling as such. Again, UX benefits over pedantic comparisons.
> "They can perform equally well..."
Why is the browser a bad environment assuming the level of performance required is known? I don't see any technical limitation here. CPU/memory impact on the machine can be handled equally well in Electron by offloading components onto native languages if required. I guess then one should always write in assembly languages? As far as I recall, games were written in C and specific parts were optimized in an assembly language. Those lower level constructs are still available in other ways. I am not sure you understand that technological choices are made with specific constraints towards a goal rather than purity of abstractions.
> "Qt developers..."
And I am sure so can any competent developer through any of the choices available in the market. A copy of a product is easy to create. A product is harder to iterate and maintain.
One difference here is there a lot of JS developers available to hire an much fewer Qt or even C++ devs.
Also IME, Electron apps are generally an of magnitude better than mobile webview apps.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That said, i don't use Postman, heard of it the first time today. But you might be able to reproduce some of the issues by loading a very animation-heavy imgur page like https://imgur.com/a/0L8Bu , scrolling to the gifs, maybe zooming out a little to get more on screen, and starting up a bunch of different electron apps. Particularly helpful would be using https://technet.microsoft.com/en-us/sysinternals/processexpl... to keep an eye on the interrupt CPU usage. Once you start seeing lots of red activity you're getting close.