TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written.
TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written.
Lots of good architecture decisions made. The marriage with TypeScript has also worked out well; it's on fire and coffee is smouldering. This helps with getting people to jump in and contribute.
* Terminal built-in
* Sublime style Alt-O for header file switching
* Minimap
* Javascript/Typescript support made a lot of my plugins obsolete
I have language plugins installed for Dockerfiles, protobuf, and a few others, but VSCode felt really complete out-of-the-box. I didn't feel the need to install a ton of plugins to make it useable like I did for Atom.
It would not have been humanly possible to get something like Spotify (we have lists of text and icon-sized images) so resource intensive in any other language.
Now if you want to spend ten (hundred?) times the effort to actually make javascript do something decent I truly hope you get pleasure from that sadistic adventure.
PS: I think Spotify should have simply stayed in the browser, the desktop app is redundant.
But I yes the biggest impact javascript will have on mankind is that noone will ever be bothered to create a good foundation for cross platform applications.
The desktop app is absolutely paramount for Spotify to stay relevant. Not sure if I've seen or heard of anyone using it in the browser (not that that is relevant, but I'd stop using it the very second I can't use it as a standalone app).
It's as native as it gets, it imitates native widgets perfectly and allows the designer to easily recreate every element of a particular OS' HIGs with the use of stylesheets and native code.
In before "doesn't look native in my macOS": Because the people writing in cross-plat tools usually don't care about getting every detail right, they just want their app to run well everywhere. But Qt does allow the developer to nail those details without too much effort if he actually cares.
The only problem with Qt is C++.
In qt6, there will be "native components" that use the actual underlying OS widgets[0]. They'll be less stylable, but will integrate better with the native look and feel. That should take care of the annoying cross-platform problems.
The other problem left is how big it actually is. As it turns out, it's possible with the LGPL to statically link your program and still comply with the license[1]. Basically, you just need to provide a way to download the .o files so they can be relinked against a different version of Qt.
Thanks to this, it should be possible to create (relatively) lightweight, statically-linked binaries of Qt software.
As far as the C++ is involved... There are qt bindings for just about every other language out there. Just today, bindings for go were released[2].
The future is bright for qt and cross-platform apps.
[0] http://blog.qt.io/blog/2017/02/06/native-look-feel/ [1]: https://news.ycombinator.com/item?id=4302517 [2]: https://news.ycombinator.com/item?id=14068525
Absolutely not. And the ones that do work are ginormous. The Go bindings are LGPL licensed, meaning they aren't an option for most people until Go plugins are available across the board, at least.
With that said, QML does have plenty of bindings, thankfully. And indeed, Qt's future looks bright, while Gtk's uncertain, so the former is definitely the saner option.
Benefits for a web app (non-desktop):
* User don't have to download the "browser" (Electron or nw.js)
* The user don't need "install" permissions
* The app can be accessed via an URL
* The app runs in a VM (a browser) that don't give full (root) access like a Electron/nw.js app does.
btw, I did not know Spotify had a web app. There's only a tiny link to it at the bottom of the page, impossible to find unless you really look for it, witch is probably why no one is using it.
P.S I'm now enjoying Spotify via the web app after not using it for years because I don't like "desktop" apps (for the reasons above)I could totally see all of this on the browser. But then the file system needs to go to the cloud, we need to consider hipster browsers (like k-meleon and omniweb), and we have to deal with the browser determining how our assets are cached and evicted.
From what I recall piecing together it came about internally as MS due to monaco and TypeScript. I'm under the impression it was a TypeScript dogfood/dev environment project. It worked out well and they threw it over the fence to the public where it caught fire.
Why isn't Electron a good foundation for cross platform apps? The only possible negative to Electron is that the runtime is gigantic. A decent tradeoff if it means for example the VS Code team can support three OSes and push out rapid updates. I really can't see any downside to this, what am I missing?
https://news.ycombinator.com/item?id=13940014
Edit: Ah a bug. I still hate apps that don't use my OS's native UI controls though; even if you can stomach the inconsistencies in look and feel, you DO most definitely lose out on many features that the OS would give you for free.
Some here may recall that early VS Code had a but where drag to highlight and menu option highlighting on mouse-over was busted in Virtual Box. So crazy and also a chromium bug.
https://github.com/Microsoft/vscode/issues/24107
I don't know for a fact that it is RDP but it's the common factor among other people with the same issue.