I'm not saying that being fast doesn't matter on desktop, I'm saying it's a lot easier to be fast because desktop CPUs are faster. I'm not saying that an optimized experience doesn't matter, just that it's less important than it is on mobile.
My point is that tools like Electron are actually making it harder to do fast and multi-threaded code on desktop compared to other (native) options. So in that sense Electron's just as "bad" as PhoneGap on a mobile device: it actively hinders developers that want to build decently performing applications.
This even happens with applications that are considered "toy" in this thread like Atom: Performance is really much worse than other editors like Sublime or TextMate.
> My point is that tools like Electron are actually making it harder to do fast and multi-threaded code on desktop
Absolutely. Electron is worse than native, I'd never disagree with that. But I don't think people are looking at Electron and saying "hmm, shall we do Electron or native?", they're saying "oh great, Electron means we can make a capable cross-platform desktop app, something we don't have the time nor budget to do otherwise".
Nothing precludes an Electron app from being multithreaded (though WebWorkers, child processes and more) or relying on native components to improve CPU intensive tasks.
If someone is wanting to release a shitty application, they're going to do so irrespective of Electron availability.
That's true. It's an enabler for some companies, which can only be applauded. I'm not sure I'm too happy with the "worse is better than nothing" mentality I guess, but that's a more general problem :)
How does the existence of Electron decrease the ability to use other tools? It only offers another option... Just like .Net/Java do, both of which have disadvantages over C/C++ and the like.
What it comes down to in the end is, is the trade off worth it. With Electron/PhoneGap and the like, you have a much faster path towards an application. Web tooling is broadly understood, and a lot of that logic/workload can and often is already done, and being able to reuse it is helpful... Having a stack that is closer to the rest that you are using anyways means less disconnect.
It's not for everyone, but in the end it doesn't stop anyone from using C++, Go, Java, C#, Python or a number of other languages/tools.
I don't use Electron and haven't been following, but isn't Electron a UI only framework?
What I mean is what is preventing you from writing a C/C++ library, installing it down with your Electron UI and having the Electron App call out to the high performance .so?
PhoneGap gets a lot of hate because it's _slow_ and single threaded in an environment that is starved for resources. This can impact user experience even in _just_ a UI context. On a desktop, a single core is many times faster and there are much greater resources so I don't see it as having as large an impact on UI (if any at all noticeable user experience degredations). This is of course provided Electron is (or can be) UI _only_.
Just curious :) since I have never really heard of Electron before this.
The underlying JS engine is, iirc Node based... you can definitely use/utilize C/C++ modules/packages there... and very little is stopping someone from doing that. There are also child processes (and iirc, web-workers). While a Process !== a thread, on some OSes they are more similar or less in terms of creation cost. RPC/Communication channels are another issue combined with message serialization/deserialization which is the biggest cost to overcome with this type of model.
While I guess you can do that, most developers using Electron are so familiar with HTML/Javascript/CSS and related web technologies that building a C/C++ module for the bulk of their app might seem only a step above going "full native".
