Electron is not superior. Web grew because of the great "application delivery" system and despite everything else that originated from the static web. By having huge number of js developers the thing was forced to do other tasks. Now with Electron it may as well do desktop apps (by removing the awesome "application delivery" system; isn't that funny?). Its only advantage is that you've got lots of js developers.
The "new" js desktop technology is new only in the sense that js is new to the desktop (so it still doesn't really know about all the desktop requirements). Same for servers: there are better tools for the job from the purely technical point of view.
So is slack, which (from what I've heard, I have no personal experience) eats RAM like a maniac. Neither of these example applications tips the scale between Qt or Electron on being superior.
Again, based on what I've heard/read, Qt being less recourse hungry and written in C++ allows it to be (for example) embedded (to cars or iot devices, for example).
Why Electron is superior? We do mobility simulation and the UI part is the minor of our concerns. We are focused in modelling capabilities and performance (so C++). Having a solution that uses the same language across all the application layers help us a lot.
Because Electron is not "superior". Both have their strengths and weaknesses, and which one is the right choice depends on what you're doing and what your existing skills and components are.
Yes. HTML + DOM + CSS + JS was not created to write interactive applications, and it still shows. Most of the inconvenience can now be worked around with frameworks, but a large performance penalty remains. And Moore's Law is over.
Deploy a lambda function in multiple regions (15 regions!) with just one bash script using Apex up.
Add route53 on top with Latency Based Routing enabled and you've a latency in 10s of millsecond from anywhere on the globe without paying a hefty fee for this kind of latency.
Audio software has strict buffer/latency demands which usually cannot be guaranteed on interpreted language platforms.
Doing audio synthesis with JS or any other interpreted language really is totally possible and has been done in a more or less serious way in several implementations and webtoys etc. But if you need extremely low latency and guarantees you cannot go that route, sadly.
the UI is the minority of the code. the main engine is gonna need to be implemented in some language which has strict guarantees about performance. also, not having a garbage collector that fires in a seemingly random way helps a lot too :)
There are few reasons:
- they most of the time run embedded in a DAW
- they are usually computationally intensive themselves
- they are meant to be instanced as far as memory/CPU can go
ad to the third point:
Music producers already require and use pretty powerful rigs: 32-128GB RAM is not uncommon, CPU as good as it gets.
There's great benefit when you can run 100 instrument synthesizer instances parallel vs 14 instances - it's a difference between a differentiated orchestra and a rock band.
I think Dart was a result of optimizing JavaScript VM and learning about the cons of language which are hard to optimize for JS VM then getting rid of them.
Even Amazon's music search sucks. It can never find the song unless you provide an accurate name. Its fuzzy matching sucks too, doesn't even account for regional trend in songs.
Apple's music search sucks too, especially if your music tastes are even slightly outside the mainstream. It simply doesn't personalize per user, so when I search, I have to wade through a list of unfamiliar band and musician names until I type almost the whole thing. For a company whose motto once upon a time was "design is how it works", this is inexcusable.
Today we've a superior technology like Electron. Why should we use old technology like Qt?
VSCode is built in Electron.