TL;DR: it's not Electron or Javascript which makes editors slow, it's how the code is written.
* 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.
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.
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).
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?
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.
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.
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.
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.
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.
That said, I'm also still using Sublime Text / vim primarily because they do feel faster on startup and handle big files well.
But I think rationally it would make sense for me to move to VSCode, because 1) my code editor is almost always open, and 2) I rarely need to edit really large files, and 3) VSCode is plenty fast for pretty much all other use cases and offers a whole bunch of advantages over ST.
Atom I'm less sure of. It seems to get faster every few months that I give it a spin, but it still feels 'laggier' even in normal use, which is definitely a problem for me.
I understand that productivity is important and a significant number of web developers can't seem to learn anything else except JavaScript or worse, don't want to, but such things as professional pride, craftsmanship and excellence do exist and are very appreciated.
Those things represent the opposite of building software applications in JavaScript. I don't know why others criticize such apps, but that's why I do it: they are normalizing flawed software and a lousy experience and mixing it with extreme arrogance.
I've had this deep disagreement with various people ever since web apps were invented. The best of the best of these apps sucked then and they still suck now and are a waste of everybody's time.
To those that truly care about excellence and don't merely pay lip service to it, there is only one way of building: using that platform's native toolkit. For project or ideological reasons one can make a compromise and use something like Qt, Xamarin or wxWidgets, etc.
This leaves JS native-like apps for those that care about doing things fast by only using the knowledge they already have. That would perhaps be understandable, if they admitted that it's a big quality and performance compromise. Yes, we tried our best, but this is the only thing we could do with this budget/team/whatever. Totally fine.
Instead we get uppity devs claiming that desktop apps will be killed and bragging about how they're delivering the best experiences. It's this toxic cocktail of arrogance and lack of ability that is intolerable.
What about the devs who care about shipping a lockstep-feature-parity multiplatform app, and are willing to go through whatever hassles it takes to get "write once, run [with platform-conformant controls + behaviors] anywhere"? Because that—and not "doing things fast" or "only using the knowledge they already have"—is the argument I hear for developing Electron apps.
What would you suggest for those developers? Just give up on their desires and do 10x as much work (likely meaning being 10x as many people) to ship for every platform, like Facebook? Or go through months/years of initial effort to develop a cross-platform UI toolkit abstraction to build their app upon, like the browser chrome of Firefox and Chrome is targeted at? Use something like Java's Swing, and pretend that's better just because "at least it's not Javascript"? Ship a GTK or QT app that doesn't look/work natively on half your platforms?
"10x as much work" is a huge overstatement, especially when platform conformance is a goal.
For native look and feel, I'd pick Qt over Electron any day. The catch is that no toolkit can abstract away all the platform-specific details. A minimum-effort Electron app looks like a web page; a minimum-effort Qt app falls into the uncanny valley.
There can be good reasons to choose Electron! But it also has drawbacks, and it isn't the only option.
Since you are clearly an expert here, can you explain to me how an immediate-mode API from the 1980s in which all painting is done via the painter's algorithm and context switches to kernel mode on every operation is superior to a declarative model that allows for global optimizations to minimize state changes and batch draw, in addition to using hardware Z-buffers to minimize overdraw?
I think your post is a nice summary of the thinking that got us here in the first place: experts always looking at the possible future optimizations and not stopping to think at the present quality or if it's at all reasonable to build complex UIs in a document mark-up language.
Kind of strange to write bindings to something you hate so much. Or was it a changed of mind in the last 11 months?
With that said, I do agree with you, but there's not a single solution out there that does this efficiently, a browser is a ginormous level of indirection after all.
But if you want to spearhead such a thing I'm sure as hell interested.
This whole section has a very polarized/aggro vibe that's putting me on guard against false dichotomies and dogmatic arguing :| I need a chill pill myself.
It's a fair point, however. :) Much of my interest in libui was (a) to provide platform support for the browser engine; (b) to provide a solution for simple projects that don't want large dependencies. I've always believed the native UI frameworks from the '90s to be poor fits for modern graphics hardware. But sometimes your workload is so simple you don't care about whether your UI is as fast as possible, and minimizing dependencies is a more important criterion. That's where simple native UI layers can be a good fit.
Is there anything out there taking a better approach that works for native desktop? React Native and Flutter look like interesting solutions, but RN attempts to do all the hard work with JS, which is far from ideal; and Flutter is limited to Dart (which not that much better) and isn't getting any traction on desktop outside of the experimental Fuchsia.
I just opened a 9.75mb JavaScript file in VS Code and it edits it quite well. It syntax highlights the top of the file immediately, and it does take quite a while for the highlighting to work its way down the file (I'd say about 20 seconds). But as far as editing goes, you can jump anywhere in the file and edit without any hesitation, instantly.
Otherwise, there really isn't any reason why I should care what tools you use.
Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
I'm not using VSCode to edit one-off files from my terminal. The use case is for your folder-based projects. I generally open it once/week or reboot, etc, and finds it loads, mounts my folder and I'm done in the amount of time it takes me to grab a sip of coffee.
I think too many people base speed because they're used to one-off editing files directly from their filesytem. At this point in time, I only do this when editing config on remote servers and such.
EDIT: I just went and opened VSCode from my terminal and it took about 3.5 seconds to load up an entire React Native project on a three year old 11" MacBook Air.
VS Code actually loads faster, doesn't freeze as much, and in general runs faster than any IDE I've ever used. And I've used a few. There are faster code editors, but VS Code is a bit more than most of them, but less than a full IDE typically is.
VSCode has found a place in my workflow now and I don't care what language or platform they've used. It's proven to be more full-featured than competing editors and they are improving it much faster than other editors (based on my completely non-scientific, possibly biased observations).
Yeah I do share that question with you and would love an answer from the team!
> Also, calling it Visual Studio is very deceptive. Most devs know VS to mean something completely different.
Could you clarify what you mean with that? Accusing me of being 'deceptive' seems a bit unwarranted and disproportionately antagonistic, considering that as far as I can tell I've made a clear distinction between VSCode and VS (meaning Visual Studio proper), and considering that I can't think of any reason why I would choose to deceive in this matter. Where did I go wrong?
Reminds me of how pissed I was with Amazon calling their line of regular Android tablets "Kindle Fire". I don't know what the sales teams there think, but for customers, the "Kindle" brand was literally synonymous with "that e-ink screen thing".
They've spent the time since then working on actual features... while they'd probably have just barely released anything if they had to do it all in C++, and wouldn't have nearly the depth of extensions they do.
Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense.
JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one.
It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable.
> non-existant standard library
This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL...
> Must be run in a packaged browser
Node? This is obviously false.
> Anything UI-related must be done by using a document markup language
It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...)
> style sheets
Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.)
> The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved.
Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology?
Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow?
Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning.
pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.
There have been tons of reliable large apps written in dynamically typed languages. This is, again, a tiresome argument.
> the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
The STL took nearly a decade to get hash tables. And for years, users suffered from Microsoft and other vendors taking very different approaches to template expansion, causing no end of ifdef hell. JS never had such issues.
> But that doesn't scale when building widgets and doing positioning.
Huh? How does flexbox "not scale"? Positioning is just one aspect of style.
> At one point web developers need to talk less and deliver
I've been working on browsers for 7 years, and on most of those weekends, thanks.
A typical app can be made pretty reliable with enough testing effort and a good process, so I'm not surprised that large apps have been written in dynamically typed languages, although I am now curious which apps you had in mind. Can't think of anything the scale of e.g. Photoshop, Oracle or Linux.
Re STL: Really? :) I'll take missing hash-tables (dictionaries are fine) any day over no library. I don't know which period you're referring to with the ifdef hell, but at least for the past decade I can't think of any STL compatibility issues. Perhaps you can be more specific here? In any case, JS never had such issues because back then it was being used to make text blink. Now that it's facing more challenges we start seeing the issues.
Re working on browsers: you're not a web developer. I will say though that Mozilla pushing this web-everything agenda is disappointing. The FirefoxOS lesson has not been learned...
Dismissing it for performance reasons is a fool's errand. The performance issues are fixable and we're already seeing them get fixed.
Bold prediction - JavaScript(or rather, a future incarnation of it resembling es7/es8) will be the lingua franca for all platforms(web, desktop, and mobile) within a decade.
HOWEVER, I have several times seen it get into a state where it's unusably slow. As in, type a character, and it shows up 500 ms later. Now, maybe this is a bug that can be fixed. Or, maybe it's a fundamental problem with trying to make an app that forces you to effectively work in a VM, all the time.
Anyway, I still wouldn't have believed, 5 years ago, that a JS/HTML/CSS app in a browser could be so snappy, overall. Maybe it's just a matter of time before perf is great across the board. Or, maybe, like heap-walking GCs, they will always be fundamentally prone to pathological cases, because the whole idea was fundamentally flawed from the start.
Either way, Atom/VSCode have developed a large following which encompasses lots of talented and smart people. They both cannot be completely summed up with the description "slow and clunky." They are absolutely not perfect, but if you really cannot see any of the many reasons people use them, you're being left behind and I strongly suggest you refrain from commenting.
That's an interesting claim, given that Visual Studio (not VS Code) is native through and through and still it's orders of magnitude slower to work with on any sizable code-base compared to the "slow" editor VS Code.
It's almost as if you could say that on modern hardware the architecture of the application dictates overall performance much more than the technology used to implement it.
But yeah, that would certainly be madness, so let's not go there, eh?
But VS Code first and foremost uses a web-browser for UI. How much does the choice of a UI-technology really constrain the rest of your application and its architecture?
I would argue that with a good architecture, the choice of UI-platform should place near zero effective constraints on the rest of your application, how it's structured and how it performs. It should certainly not be a critical component of your overall design, it should be an implementation detail.
Are you arguing otherwise? Can you come up with some concrete examples where the choice of UI-library causes troubles other places in the application? If not, it seems you're more or less agreeing with my original statement.
And as such, I don't see any fundamental problems using a web-browser in a text-editor.
Those IDEs are all much slower in my experience, and even Sublime is outmatched in terms of plugins. Because it's just so damned accessible with VS Code. If it runs good enough on the hardware you're using, wtf does it matter?
Note: native means the platform's native toolkit, running with the best performance on that platform. E.g: Java or C and C++ for Android, C and C++ for Linux, C and C++ and Obj-C for macOS, C and C++ for Windows, etc.
Things that are not native: Python, .NET, Xamarin, JavaScript, Java on anything except Android, etc
It's changed my opinion of electron based programs.
The integrated terminal is far and away my favorite feature, second would be the git+diff integration... though merging/rebasing needs a good story.
Once technologies like Servo and Web Assembly become part of the standard platform, it will be the preferred platform for performance reasons. There will likely be nothing that can give you the same performance and also be cross OS platform.
The only thing that is really incompatible is Windows, and Microsoft working hard to make that less and less true.
Servo will be a drastic improvement, though.
Turns out VS Code is actually surprisingly fast! Startup time is only marginally slower than notepad (and I have several plugins added), and performance when running for things like search and replace is super fast. Try it, it will surprise you.
The Browser.html UI is quite minimal, in the sense that it really doesn't do much at all. It's basically a list of tabs along the right side. I also find it quite laggy, and sometimes it locks up completely. I'm not sure why you think people should be impressed with it.
As for Servo itself, there are noticeable rendering problems with pretty much every web site I've ever tried with it. Even the servo.org home page had rendering glitches when I last tried it several days ago! The scrolling is very broken under macOS. I've also had it crash now and then.
Maybe it will get better in the future. But at this time I'd consider Servo to be pre-alpha quality software. Trying to impress people with it would probably do more harm than good. They'll likely encounter problems with it right away, and it won't leave a good impression on them.