Because those are companies dominated by webdevs that can't be bothered to learn anything else.
Even VSCode is probably a side effect of Microsoft trying to be cool and cattering to the new generations that don't know anything else.
For me, it just made me buy a Sublime Text license instead.
You could argue that it's a similar story for things like Slack - for business reasons, they more-or-less needed to have a web-based UI. If you're already committed to that, then it makes sense to use Electron in order to maximize your code reuse.
I can't speak to Discord or Atom. Those ones make less sense to me, but there might be a reason there, too.
Speaking completely personally, Qt has never felt like a viable option for a commercial project to me. It does have some bindings for other languages, but, at least last I checked, they're all community supported. When you're talking about language binding libraries, it's reasonable to think of "community" as a polite way of saying "poorly". That can quite justifiably influence a person's willingness to rely on them for non-hobby projects.
I don't like JavaScript much better than I like C++, but at least I can more easily think of business cases for why I might accept being locked into JavaScript. The ones up above, for example.
Electron exists because of Atom (yes, in that order). Electron was previously called Atom Shell[1] because it was created specifically to house Atom, although they mention it wasn’t created just for that. If there’s one app that has a reason to be built on Electron, it’s Atom, because it was an experiment to see how viable that solution would be.
But even they understand that solution wasn’t the best because it’s slow, so they’re experimenting with a model where the application logic is written in Rust and only the UI is built with web technologies[2].
Electron is good for an MVP if you have or need a web app. Companies keep using it afterward because it commodifies developers and externalizes costs.
I doubt Microsoft (VSCode) is in that camp. Or that that was the main concern of the others. And I think that's a facile explanation anyway: the same kind of companies flocked to do native mobile apps in the past -- but nobody much cared for QT on desktop still.
Otherwise I'm not sure why most people care about the internals of their editor.
They had a native app. They decided to throw it all away.
Tell me about it!
working on Max/MSP by any chance ?
> Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it.
But someone built Telegram with it, which is of fairly equivalent complexity (https://aozoeky4dglp5sh0-zippykid.netdna-ssl.com/wp-content/...).
Besides, I'd say that there are enough quality Qt apps in the KDE ecosystem to not need $ELECTRON app :-) just yesterday Krita was making the highlights for instance. Likewise, I doubt people being used to the power and speed of KDevelop or QtCreator would feel the need to switch to VSCode.
Even going outside of the "libre" ecosystem, there are many many many nice-looking recent apps written with it... take a look at substance painter (https://www.allegorithmic.com/sites/default/files/DML_1.jpg), the Blizzard launcher (https://i.kinja-img.com/gawker-media/image/upload/s--zbfvud8...), Native Access (https://support.native-instruments.com/hc/article_attachment...)...
I did eventually download the Qt version. It doesn't support emacs keybindings. I can't use ctrl+b ctrl+f to move my cursor in text boxes, like I can in every macOS native app and Electron app.
I think this is a pretty strong argument for Electron: It actually behaves like a native app.
I also think Telegram is lower complexity than Slack, Discord, Atom, or VS Code. For instance, as far as I can tell, it doesn't have features like emoji reacts, which I'd guess would be something easier to implement in HTML/JavaScript than in Qt.
Substance Designer is a giant graph editor that should be perfect for multitouch trackpad pan/zoom gestures, but it doesn't support them. To zoom in and out you scroll up and down as if you're using a mouse wheel, but moving your fingers about 1mm will zip you instantly past where you were trying to get. And IIRC it expects a middle mouse button that you can drag to pan; on a laptop you get to two-finger-drag while holding down Option.
Electron, being based on a web browser, is probably easier to set up for various input types beyond keyboard and mouse.
EDIT: Here's an old video I recorded of the trackpad zoom. If you look very very very closely you might see my fingers move.
https://gfycat.com/FlippantBonyHusky
TLDR cross platform UIs still take work
From the thread's master:
> The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge. Note the word 'viable'. Those who might suggest that Qt covers that role have to explain why, even though it has been capable of fast, attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode in it.
Most industry standard VFX applications utilize Qt for the UI and other application parts. It helps that there was a standards body (admittedly, very Linux biased but starting to open up) set up between vendors and studios for choosing major frameworks/libraries (VFX Reference Platform[0]):
* Autodesk Maya
* Autodesk 3DS Max
* SideFX Houdini
* Foundry Nuke
* Foundry Mari
* Foundry Katana
* Foundry Modo
* Allegorithmic Substance Painter
* Allegorithmic Substance Designer
With the exception of macOS in the very recent years, these applications work pretty seamlessly and efficiently. Qt is not as easy to get up and running with compared to web based frameworks like Electron, it does provide a pretty 'viable' framework for building cross-platform applications. Getting 'native' in appearance will probably never happen 100%, but Qt does a pretty bang-up job. Regarding the apps listed above, they all use custom styling so you get the same interface across all platforms, so native doesn't even matter anymore.
The bigger bummer is that “cross platform” for this sort of thing is only talking about Windows, Linux, and maybe Mac. Substance Designer and Painter would both be outstanding to use on an iPad Pro as long as you had someone on desktop platform feeding you the 3D models.
Designer has had proper Hi-DPI/scaling support since early/mid-2017. Painter has the support, too, but not to the same degree. Apparently it rounds between 100% and 200%, but nothing in between. Although a user said 150% works.
https://forum.allegorithmic.com/index.php/topic,1191.0.html
> The bigger bummer is that “cross platform” for this sort of thing is only talking about Windows, Linux, and maybe Mac.
That I think is between Qt and Apple. Mari 4 came out at the end of last year and the macOS version has been in a perpetual beta since about 6 months after GA, but should arrive with the 4.5 release currently in beta (fingers crossed for those users). As reported by the dev team, it comes down to some serious stability and useability issues from Qt on macOS (the way they've implemented it) that is just not working well between various macOS versions. Some users the beta works fine, others not at all. And this happens to users of the same OS version and hardware.
On the platforms, my bigger issue is the complete lack of iOS for these apps more than the iffy Mac support. It would’ve been really good.
Heck, even the Surface Pro would’ve been great if they’d properly supported gestures in the graph view. They didn’t though, and I don’t have a Surface Pro anymore.
And most of their UIs look alien and unusable crap only a professional forced to use it would...
It always takes a small adjustment period of getting used to the application's actions paradigm and you get over it. The UI's don't really get in the way, and you kind of stop caring about visual appearances after the first few weeks. At the end of the day, it's all panels and buttons. As long as it's internally cohesive and consistent.
Even so, 3D apps have it way worse than pro apps like Photoshop, Cubase, etc with equally "wide range of functionality".
The ribbons thing admittedly is more discoverable, so occasionally I’ll look for something there instead of going straight to google, but once I know what it’s called I’m right back to the command line.
Web browser developers have shown by example that you can come up with a sophisticated standard, including executable code, have everybody implement it on their platform, beat them into compliance with cool validation tests, and even starting with one of the worst possible architectures for performance (sending raw JavaScript code over the wire!) make it perform far better than anyone might have reasonably expected.
Meanwhile, operating system vendors are doubling down on proprietary APIs. These days you practically need to use the right programming language for your OS, too.
A whole lot of groups seem to have completely missed the web's lesson. Instead of "standardization is great", they heard "HTML/CSS/JS is the ideal substrate for writing applications".
FreePascal have one. TCL, before.
The bigger problem, I think, is the language tie-in. For get the amazing Delphi/FreePascal UI you need to work with pascal.
To get TCL-UI, you need to work with TCL. This mean anybody that not want to code on that not even consider the option.
And how integrate your language of choice? You need to pass by C. C sucks. SUCKS SUCKS SUCKS. Is so bad that is the glue for native development.
In the other hand, Elector/React Native is tied-in with JS. If C sucks, JS sucks even more, BUT, you DO NOT HAVE A CHOICE. Is Js or the highway by proxy of the browser. So, even if you code in other language, you MUST (not everyone, but enough) soon or later to accept this fate.
And interface with JS is not as bad as with C.
The more of my project I can write in C, the happier I am.
Same issue with WxWidgets, which is otherwise great - AIUI, it was started as a C++98-ish library with support for lots of pre-standard compilers, and a lot of its deep weirdness is a direct consequence of that. OTOH, at least it has good bindings for other languages like wxPython.
In the other hand, I wish C get allowed to improve much more, and do python2/python3 split (with better handling of the situation, of course), to remove lingering issues, clean the syntax/API, and just add algebraic data types, match and Option<T>, and a good UTF-8 string (the only additions that I think are worthwhile without making C too different).
I envision a C-good that transpile to C-classic and slowly take over.
I experience bliss while writing stuff in Go. It is not as fast as C, but it is getting closer with every release. Garbage collection in Go is so fast now that there may as well not be any pause at all.
It's worth a look, in my opinion.
I was recommending Go to someone that wanted C plus a few things. For me, that's Go.
Why does the lack of generics come up all the time?
It didn't get very popular though.
If you learn to make great looking and functional websites then you can make that into electron. Add to the fact that many services want to have a desktop and web application, it just makes a lot more sense to design its core in Js in a browser environment
As for the obligatory "qt can do that" qt uses chromium to do browser related tasks. The alternative is webviews which are unreliable in any full sized application.
These days Qt is fairly close to this ideal, even on Mac: apps like calibre look a bit weird but their menus are in the right place and their coloring roughly matches my os settings. Electron apps are all over the place: vscode, slack, etc. all pick their own design styles and ruin the visual consistency of my desktop.
To some degree? It is incredibly anti-user, especially if the user happens to have a disability. I know I've said this before but it is absolutely ridiculous that having a "dark mode" is considered some kind of notable feature in 2018, when in 1995 you could just set all your colors and fonts however you preferred them.
But that's the world we live in now. Personal computing is dead, you just rent your computing from some corporation and they'll tell you when to update and how everything should look and what you can and cannot install (for your own good comrade!).
As far as personal computing is concerned we're living in the darkest timeline. Makes me ashamed to have anything to do with the tech industry.
For an apples-to-apples comparison, I’d rather use Slack through something like Adium that puts me in control of the ui. And VSCode would be nicer if it looked more like textmate.
I think Flutter means native in the sense that it runs at native speed, perhaps even faster in some carefully selected apps
As for a look and feel thing, Flutter widgets feel alright to me..
I have found the perf to be just fantastic on android. Especially compared to react native, which is a native offering.
What's interesting is that you can literally run the same app on all platforms, because flutter draws the whole ui in dart code, using the canvas. And well, dart can run basically anywhere now...
https://medium.com/flutter-community/flutter-on-desktop-a-re...
Bottom line, Its very safe to say that dart is a much better language than JS.
The language of choice has never ever, really mattered in software history.
And don't forget that the big G is behind this thing, which is well equipped to push it forward without the need of it being as popular as js.
Right now Flutter/Dart looks like an ongoing political war between ChromeOS, Android and Fuchsia.
By the way, Fuchsia is getting Android suport and a new language agnostic UI composition engine, Scenic, so lets see for how long Flutter stays as the Fuchsia official UI toolkit.
But isn't the point of a truly cross platform framework just that? So what if fuschia has a different native toolkit. Maybe they are trying to launch a platform specific api that's more bare metal.
I mean Isn't the whole point of flutter is that you take the same app and run it anywhere?
Maintaining parity between two applications running on different GUI platforms is very expensive - much more than twice the effort of maintaining a single codebase.
This is the point about Clojurescript too: yes it compiles slower and runs slower, but it allows access to what is essentially the world's largest and most complete UI framework, known as the browser. That makes apps cheaper and faster to produce, at the cost of sluggish/bloated performance. The market has indicated that this is an acceptable tradeoff. Until some other solution can match it on these axes, Electron/Javascript/React SPAs will dominate.
I work with a Qt-like C++ GUI framework (JUCE), but we've seen increasing portions of our front-end work replaced with Electron/React Native. It saddens me to see binary sizes and memory consumption balloon, because native development encourages you to care about these things. But even I cannot deny the order-of-magnitude improvements in productivity from hot-reloading, a deep (if byzantine) system for styling and layout (including text), and reuse of modular components across all platforms.