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.
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.
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.
Your point that native applications don't always have to use OS-provided components is taken though.
- 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.
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.