VSC streamlines the data it needs to load, doing the least amount possible in hot paths as far as I know. They also multi-thread on startup so it is perceived as being quicker to boot up.
I think vscode was built with performance in mind from the ground up. Atom on the other hand was focussed on hackability. Down to actual reason, I haven't scanned the source code but have noticed vscode delegates lots of processing to separate child processes that could prevent potential freezing/lockups in the main process/window.
It's not magic by VSCode, other web-based editing components such as the ACE editor are also lightning fast. There are two main reasons:
- VSCode is rendering in the DOM what you see, not what you scroll to.
- VSCode is using the correct datastructures, so an insert of a line at the top, doesn't require updating/relayouting all lines below it, but more likely something like log(n) lines.
And these two reasons you can summarize as the difference between old skool engineers with proper training in datastructures, cache behavior and algorithmic complexity -vs- new skool "full-stack developers" that rely on a billion lines of code they haven't written (or understand) and who mainly script a bit in between. The (wrong) assumption in the recent decade was we don't need to train engineers to understand the algorithmic complexity of their code because 'computers will continue to become faster'. That was never true and never will be true, because an exponentially slow algorithm simply won't ever be fast enough regardless of the amount of transistors. And making something like a simple text editor (without syntax highlighting and all of that -- just being able to edit the code), is actually an easy test to distinguish between the two wildly different skillsets.
The honest answer -- Microsoft has a lot of people with experience in building these things, so they aren't making the typical mistakes that Atom made with their architecture. For example: Atom was rendering dom nodes for your whole file -- not just the parts that were visible. Using the DOM as a stateful container of all that could be visible does not scale really well.
Compare to something like the ACE editor (an OSS editing component that you can plug into any website) which is lightning fast -- it only renders what you see though -- but the filesize is not at all relevant to the performance.
These are all techniques that people who ever wrote complex UI toolkits are incredible aware of. I don't think that describes anybody who worked on ATOM ever, which means they just have to relearn and re invent this stuff until they get it right.
Generally, these days a lot of developers get a lot of experience combining existing technologies. Proper engineering skills, or even being aware of the data structures you are using and their algorithmic complexity, how cache friendly it is -- all of this is prioritized much less now.
So Atom answers a simply question. Has hardware become significantly fast to not care about proper engineering? No, not really and it never will. If your datastructure is structured in a such a way that inserting a line all the way at the top requires a relayout of every line below that, for example, you will run into real limits.
Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron?
That's part of it. The other part is "write using tools which lots of developers are familiar with", i.e. the general browser stack. That still applies.
For that matter, even if your app requires occasional core high-performance bits written into C, that's probably still a benefit to you. Similar to the standard Python argument, which advocates a very similar development pattern.
After all, it's not like you're not compiling it on each platform anyway to get the native app you're distributing.
I think with any technology like this, as long as the structure of the wrapper (Electron, in this case) allows for cleanly integrating into lower level components of code, it's fine. The point is that the majority is managed in a lighter-weight accessible language. The majority of the application is still based on web technologies that a larger audience can contribute to. If they need to write something lower level for a core part of the application to achieve performance, I think that's alright.
Not every Electro app should have to deal with a huge dom tree like Atom does. I just think the Electron is a bad fit for this particular type of application, but it does not mean it can be a bad fit for other type of stuff.
Honestly I'm a little curious about whether compiling it to WebAssembly would have offered similar benefits. If so, that would make writing performance-critical parts of Electron apps in another language a more approachable proposition.
I don't think the ability to put some of the heavy lifting in C++ code diminishes the value of Electron or Node.js any less than any other scripting language that lets you write modules in C or C++. The way Node.js C++ addons are written and built doesn't diminish the "write once, run on all platforms" nature unless you try really hard to write platform-specific code.
> Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron?
C++ data models can be write once compile almost-everywhere (all desktop platforms at least) pretty easily. You can write C++ code that compiles on iOS, Android, Windows, and MacOS, and Linux, without any great difficulty.
Making all the UI and system integration code cross platform is a more valuable service. Just dealing with something like the Clipboard on all the above mentioned platforms is a lot of boilerplate code. Not to even get to actual UI widgets!
This makes sense, but seems like a(n unspoken?) pivot...? Electron doesn't call itself a UI framework after all, but an application framework.
I thought most of the excitement was about getting away from manual memory management into higher level languages and building something that works across the web and desktop, not just simplifying desktop busy work with native UIs.
Their tagline is "Build cross platform desktop apps with JavaScript, HTML, and CSS"--if you need C++ to truly get the app you want, it seems like the value proposition is severely diminished.
> If you are doing manual memory management in modern C++, you are doing it wrong in most cases.
You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime.
You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!)
And memory is still being fragmented, especially if the data model is complex.
In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues.
Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language.
> You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime.
As you do in any language.
> You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!)
In the case of modern C++, Swift, even ObjC–by “you”, you mean the runtime? Following relatively simple rules does not create a huge cognitive burden on developers, I think.
> And memory is still being fragmented, especially if the data model is complex.
Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age.
> In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues.
Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language.
There is also a quantifiable performance penalty to GC’d languages and defragmentation. And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
Most GC languages force the issue for you. Everything on the heap. That said, I'd love it if more GC'd languages were smart enough to know when they can stack alloc. :)
> Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age.
They become a problem with any long lived application that throws around large chunks of data. From video games to productivity apps. Soon as interactive runtimes become multi-hour, life gets harder.
> There is also a quantifiable performance penalty to GC’d languages and defragmentation.
Depends on usage. Destructor chains can take up large amounts of time as well, and from the programmer's POV, are about as deterministic as GC pauses. On the plus side, they typically only pause one thread instead of the entire world. :) (Not much help if it is the app's main thread, or UI thread, heh)
> And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
And they also prevent a lot of those same issues. It is a trade off. But I'd say that for 90% of coding, the cognitive load from GC is lower than from using C++. A brand new C++ codebase written by people who are all strictly following the Right Way to do things will look good, but the majority of code is old. The majority of libraries being used were not written in accordance with the latest C++ spec, every single third party library doesn't use unique and shared pointers, leading to natural conflicts at interfaces between libraries.
Pick a mature (has libraries written in it) GC'd language and that all goes away.
> But I'd say that for 90% of coding, the cognitive load from GC is lower than from using C++. A brand new C++ codebase written by people who are all strictly following the Right Way to do things will look good, but the majority of code is old.
Don’t forget we are speaking about a new component written in Atom, or a new project being started. Legacy code is legacy code; it is almost certainly a pain (even in Java). But when starting a new project and following some basic guidelines, C++ has become somewhat pleasant to work with, something that has not been the case in the past (for me at least).
> But when starting a new project and following some basic guidelines, C++ has become somewhat pleasant to work with
I can agree with this, with the caveat that old libraries, still in popular use, are all over the place. For one thing, a lot of OS interop relies upon these libraries, although C++17 is aiming to standardize a lot of what used to be OS level functionality.
But you still don't need C++ to "truly get the app you want." Only when you cross a certain performance threshold do you need to look elsewhere. Most electron apps perform well enough despite the rampant RAM and battery consumption.
> Am I confused or is it not the case that the whole argument for Electron is "write once in Javascript, have a native app for all platforms"? If this is what a flagship Electron app has to do to be performant, is there a real future in Electron?
You are absolutely right and that's the biggest irony of all that, them going down to C++ .
What they should have done is like Sublime Text. Write the GUI in C++ then use Javascript as the scripting layer for your apps (instead of Python).
That's one good reason that you might choose to use Electron, but it's not the main reason that Atom uses it.
One of the main goals of Atom is to be the most hackable text editor ever. Given that goal, Electron is the ideal platform for the app. Thanks to node's native module system, we can cleanly drop any component we want down to C++, while keeping our main application logic written in the most widely-known (and fastest-executing, thanks to V8) scripting language in existence. I'm happy with this architecture as opposed to starting in C++ and then bolting on some specific, limited scripting APIs.
To be sure, Atom has performance issues that remain, but we're making steady progress on them, and Electron isn't standing in our way at all.
There is nothing more horrifying in the known world than accidentally opening a 200meg log in VSCode or Atom... (both have other great advantages, though).
A lot of vim plugins take a different approach that initially makes one think they are broken: they only render syntax based on what's in the buffer, which leads to things like HTML closing tags with opening tags not visible in the buffer (presuming you didn't scroll past the opening tag and jumped straight to the current position) won't be highlighted correctly, etc. but it means never having to parse the entire file just to get syntax highlighting working. It's a good compromise, on the whole.
This seems like something that if they are going to address performance
comprehensively they are going to need to benchmark and watch for improvements and regressions on their builds.
One thing that really surprised me was that my terminal emulator made even things like nano or neovim have high latency.
I suspect that most people don't really care that much about the difference between 30 and 10, but care whenever the latency spikes to 60-70 (which is more likely in VSCode and especially Atom, compared to neovim).
How does VSCode manage to take up less disk space than Atom, with similar feature set? Currently on Windows box:
VSCode 1.14.0 - 156MB
Atom 1.19.0 - 516MB
I don't think anyone is questioning that; I believe the OP's question was more along the lines of "what wasteful resource management strategies on behalf of Atom's developers lead to the product consuming so much space and running so slow?"
You misunderstood my answer. The only way you get to "I want this app to be no larger than 80Mb" is to make that goal and get to work. You cannot, for example, make your operating system boot faster from 30 seconds down to 3 seconds just by making things faster everywhere you can. You have to set the budget at three seconds and approach every problem from there. Atom is large because it has no size budget
We always have to have somebody remind us how wonderful VSCode is compared to Atom every time there's a post about Atom.
I'm wondering—if you prefer VSCode, why even comment a post about Atom? I doubt your care that much..?
Atom is built on Electron. That means that it includes a whole version of Chromium (OMG!), and it isn't even optimized, so its size is 5 times that of VSCode.
Is that really a problem? Are you trying to tell me that as a developer you don't have 400MB to spare on your hard disk for one of—if not the most—important tool to work your job, and the size is really a reason to pick one editor over another?
Atom is about 100 times slower than Sublime Text, and like you pointed out 5 times bigger than the insuperable VSCode.
Now, I use Atom as my main editor, because I find it simpler than others for certain things, and it saves be a lot of time because GitHub integration is done very well. Also, I like the name (can't say the same thing about VSCode).
Some people like Atom because they're more productive, and don't care about its size, super-crappy speed, and whatever else you think Atom is worse than VSCode at.
Where's the harm in having an actual discussion about this? If you're comfortable with your choice of Atom, you can just ignore anyone comparing Atom to VSCode.
The harm is that every time there's an Atom post, most comments are about how much it sucks compared to VSCode, and always from the point of view of memory footprint, and size. I have both GB of memory, and GB of HD space.
I'm guessing they are trying to run atom on an embedded android smartwatch OS backported to 2006 hardware? I've never found the argument compelling. My memory is there to be used by apps I use.
Atom also happens to be built on Electron; I think that commenter was genuinely curious as to how Atom was that much smaller than VSCode when both are built with similar technologies.
It's actually a valid question: Both Atom and VSCode are built on Electron, both provide similar functionality, and one is a lot faster than the other. (Or _was_ a lot faster than the other?)
So it's valid to ask what did the VSCode people do to come to the different result?
On a related note, I wonder about the speed difference now, after Atom has done a lot of optimizations.
I'm guessing a lot of cruft built up on atom as it was iteratively built on top of developing front-end frameworks and transpilers over the years, compared to vscode which came on the scene much later when a lot of this had already settled. My guess it's just an older project with many times more contributions that accumulated legacy cruft that takes time to fully expunge.
I'm also not convinced the feature set is identical. Atom comes with a lot of language support, customization options, and extensibility out of the box.
VSCode is also built with electron[1], so that doesn't excuse it. Atom's defenders always bring up that it was made with electron as the reason for it's slowness. Then, VSCode came along and invalidated that. Now, that leaves only one conclusion: Atom is slow because it was not engineered well.
And no, I don't think anyone is ready to stop pointing out that Atom is slow. Atom can implement a thousand killer features, but until they fix their performance problem nobody is going to switch back to it.
I tried many editors when I decided which one to use—including VSCode—and Atom was the one where I was the most productive by a long shot.
Speed isn't everything. Atom is quick enough for the code I work on, and in other, much faster editors like Sublime Text I would be less productive and therefore slower. For instance, editing settings/packages in Sublime Text in unnecessarily nightmarish. Changing settings and installing plugins in Atom is a breeze.
Who cares if the editor is a few milliseconds faster when you're many minutes slower..? Just because of its excellent GitHub integration Atom is worth 100 times more than Sublime Text to me (even if it wasn't free).
I get annoyed about having to switch to GitHub, for instance.
It's fine to have opinions, I'm just annoyed by the fact that every time there's a post about Atom the conversation gets hijacked by "VSCode vs. Atom" comments.
That's fixed in the linked update: "Saving a file now happens asynchronously without blocking the UI, so that you can move smoothly from one task to the next."
Where is the proof on vscode being "fast"? And compared to what? I can only talk about my and some of my friends' personal experience but it won't praise vscode's performance. It's maybe less glitchy(latency) than atom but it feels like it's still far from sublime/emacs/vim.
vscode is slow as dogshit. Its performance is barely passable on windows(making it just barely usable), but when you run it on linux its pathetic and glitchy. If Vscode could eliminate click latency and unselecting highlighted text latency/glitches, it might be an ok editor. I will say the features it has are impressive, but its downsides are outweighing its benefits for me on ubuntu 16.04.3 on the brightside, my replacement ssd will be here soon and i can return to windows 10 and vscode is much better on windows, since windows always has superior desktop performance to linux.
GitHub integration is done very well --
Not nearly as well as the Git integration in VSCode
Also, Atom has in the past been much slower than VSCode in nearly every aspect.
VSCode has a built-in debugger which takes it dangerously close to being called a full-fledged IDE rather than just a text editor with plugins cough Atom cough
The reason they keep getting compared is really simple: they both aim to achieve the same goals, and both use a very similar approach.
One editor I haven't seen mentioned in a LONG while, though, that can probably be considered the 'grandfather' of both of these is Brackets. If I remember right, it had a lot of performance issues, as well.
>VSCode has a built-in debugger which takes it dangerously close to being called a full-fledged IDE rather than just a text editor with plugins cough Atom cough
OMG! is right, imagine trying to make sure the zoo of various Node and Chromium versions on your computer do not have any unlatched vulnerabilities.
And you know? I have 400 MB for one Electron app. I even have 8000 MB for 20 Electron apps. I just do not want to give them because you'll eventually tell me that your containerized Electron-on-Docker-on-Electron virtual machine requires 64GB of RAM to run.
Now, I'm not saying that you should not use Electron ever. But if using a TEXT EDITOR on a laptop with 2GB of RAM requires sacrificing a quarter of its resources, that text editor is not a good piece of software. And if you say I should buy an OP max-spec computer to write freaking HTML, you are creating an unnecessary barrier to CS.
Maybe it boils down to npms? Atom is using `dugite` npm for git, which takes more than 40MB alone, babel-* packages are probably above 50MB and silly things like emoji-images >11MB... but to be honest VSCode must be taking more space than that, maybe they're keeping npms outside of the main app because electron framework itself takes 167MB on the current Atom so technically you can't get below that.
Even VSCode is sloppy and could go down easily IMO.
They have a folder with js modules (I didn't look too deep into it, there might be native dlls there too) that's 75 megs, compressing (and i.e.: recompressing on any change, update, download, etc.) would help with disk space taken and loading times. Not even an SSD will beat a zip file kept in memory, SSD, resolving file paths, NTFS, they still have overhead and I'm sure it'll be more than just decompressing out of a zip in memory.
would beat keeping that zip in memory and accessing it to decompress any script when needed.
75M resources
17M resources.zip
6.7M resources.7z
Third party ones aren't even minified which would be free size savings!
It's basically free saving and super common in game dev to package files and not have them scattered like that.
Customization is a lot easier. In atom, I can easily tweak plugins that I install. Also, theming is done using less/css. In VS Code, theming isn't done via CSS and that makes things a lot more difficult.
The VIM plugin for Atom is a lot more feature rich than the VS Code version.
I really love the vim-mode-plus on atom. It is excellent in many ways (especially how it interacts with Atom's multi-cursor support): https://atom.io/packages/vim-mode-plus
The VIM plugin in VSCode is atrocious. I use VIM a lot so I'll be going back to ATOM after today's non-sense. FYI, Ive been using VSCode for several weeks. I also like the settings UI better and the packages and themes UI better in ATOM.
Personally I only use VS Code if I'm working with TypeScript or Go. The plugin ecosystem is usually better with Atom. And if it weren't for tons of easy to use plugins, I'd just stick with Sublime or vim anyways.
This opens two separate windows, each representing a project. Any editor can do this. Parent meant opening two projects in the same window.
This is the number one reason I do not use VS Code. I love having multiple projects open in the same window at the same time, accessible with cmd+p fuzzy search in Sublime.
Does opening up the parent folder of the two project folders not accomplish that exactly?
I prefer thinking of codebases as folders in a file structure then as "projects", so I might be missing something obvious and is probably the reason I interpreted the parent comment's question the way I did.
Atom is a solution in search of a problem. Unless the problem was "My code editor is too easy to use, and not nerdy-looking enough. I need something that takes three hours to configure out of the box because I'm more interested in being an uber-geek than actually getting work done."
Can't say I agree. Markdown looks positively beautiful on atom. Out of the box. Plus you can tweak it, without wanting to kill yourself, to show images in markdown too. Even syntax highlighting. And real time rendering. All this means that I use it as my coding logbook, and it works better than anything else out there at that.
> I need something that takes three hours to configure out of the box because I'm more interested in being an uber-geek than actually getting work done."
Actually, that's what I thought when I tried using Sublime Text for a while. It took me hours of editing the JSON file to get it do look and behave like I wanted, while Atom has a very convenient GUI to change settings and install plugins and themes.
When I was finally done, I realized that the project tree view—if that's how it's called—sorts files with folders first like on Windows, and being on macOS it was too confusing for me since that was the only place throughout the OS where that happened.
To me, Atom is the solution to Eclipse's stagnation, Sublime Text's somewhat high price tag (I know we can afford it, I'm just saying), and personal preference, plus really good GitHub integration which for me is paramount.
I’d actually suggest the opposite. It’s much less nerdy than say VIM or emacs, and is easy enough to use. I don’t know of any text editor that doesn’t require hours of investment (or a slow trickle over months/years), and I don’t think it’s even really possible unless you use something like Xcode that is just so constrained (and even then you’ll remap keyboard shortcuts, etc). Text editors are a key part of people’s workflow, and everyone will have different needs or have been “brought up” in a certain style/configuration. Some are more mouse based, others are more keyboard driven, some require a certain toolbox, others are more basic in needs. Then add in different languages, project complexity, version control, project management software and styles... there’s too much diversity out there to have a one-size-fits-all approach.
First comment (currently), comparing to VSCode and saying how much better VSCode is: faster, smaller footprint, just wonderful. Someone was asking what's wrong with having a discussion about Atom vs. VSCode, but what's wrong about having a discussion about Atom and the topic of the post without hijacking the conversation into the same old "VSCode is better than Atom" nonsense?
This is getting like Windows vs. Mac. Doesn't make any sense.
Let VSCode be more optimized or technologically advanced than Atom like macOS might be compared to Windows, but without making that the reason why people should immediately switch to it.
You know, macOS and VSCode might be better, but there are people who are perfectly fine and more productive on Windows or Atom.
Sure. Variety is the spice of life and all that. Still, they are both electron based code editors that seem to have similar goals. Seems apt to compare them and worthy of discussion.
If you publish a new release and you happen to have a competitor in the same market that is currently eating your lunch people are naturally going to ask what makes it worthwhile to switch.
> Seems apt to compare them and worthy of discussion
Sure, but that's not the tone used. Besides a few, most comments are dismissive of Atom and just point out how much better VSCode is and wondering why anyone would use Atom.
It's factions, like Mac vs. PC. There is no productive discussion, here.
That's not true. I just got some great answers to my questions. You seem to be the one insisting this is some kind of a tribal thing and it's just not.
Can't agree with you here. Your comment seemed to be saying "VS Code may be better than Atom in every way, but that doesn't mean we should keep bringing that fact up, or that anyone should switch because of it." It's actually a perfect reason to do both.
I'm not sure how Atom fares in this regard but search has been nearly unusable for me in VSCode as of a recent update (even for moderately sized projects). Searches take longer than they should to complete and cause CPU usage to jump to over 50%. ag / The Silver Searcher completes the same searches in microsecond time.
Simple answer: Plugins. It'll be the same answer every time this question is asked, for me.
As someone who doesn't see using typescript in the foreseeable future, and doesn't feel impacted by performance benchmark comparisons, VSCode doesn't seem to offer me any compelling reason to switch to it and go through reconfiguring another editor.
I think Atom still exists because it got here first. I doubt it would have been created, let alone achieved the traction it has, had it not been "first to the market" in this particular niche.
Oh I dunno.... back in the day, there was Texmate, and it was like a pretty Emacs. Then came Sublime, Coda and Espresso. That was an era of pretty text editors. I was used to vim, so all that beauty didn't really entice me. When Atom first was announced, I just figured it was another Sublime copy. I had no idea what Electron was at that time. I just thought... hmm, an editor from GitHub... ok... I'm sure there's some reason for it to exist. But from my perspective, it wasn't competing with other javascript/browser-in-a-box editors... it was just another in a long line.
In vscode is it possible to use alt+backspace to delete a word till the next '_' (underscore) or '-'(dash)? (ctrl-backspace works, but that deletes the whole word.)
This is something I do all the time in atom, and miss quite a bit when using vscode (for typescript).
I saw it somewhere else, but a direct response is, vim-mode-plus. It's the absolute best I've seen in any editor. I was able to port every shortcut/binding/snippet from my .vimrc. The thing is just awesome. I tried the vim plugin for VSCode, and absolutely hated it. I have no doubt that it'll be improved in time but... it really gave me no reason to want to switch. I might go back to regular vim at the end of the year... I'm trying to make it an entire year with Atom.
What I am saying is that VSCode vs. Atom is the same "war" that people who like to use VIM have against people who like to use Emacs. The people who defend Atom/VSCode do it the same way people defend VIM/Emacs, it doesn't matter if one was built with tiger's blood and the other with wolf's blood, the "war" between them is just an ideology, otherwise everyone would be ignoring one and using the other.
OK, so more and more C++/native stuff... Why not make a fully C++/native app? I don't see anything special in the UIs of Atom, VSCode, Bracket or whatever that is really hard to implement natively. It might be somewhat harder, but it is worth it.
Because designing UIs in a universally-understood, well-tooled markup language like HTML is a lot more developer-efficient than [insert-native-C++-library-here]. Electron allows the use of web tech on the front end with as many native or non-native calls on the backend as you want.
Speaking of responsiveness and memory usage... When Atom first came out, I was one of those people harping about how goddamn slow and unresponsive it was compared to ST2 (and later ST3). When I realized just how much those milliseconds meant to me, I decided to see what was faster than even ST out there and I ended up on neovim.
It's 2017, and after two decades of fighting vi and vim at every corner, I am finally a convert. I spent (and still spend) a crazy amount of time getting neovim to behave the way I expect an IDE to behave, but the speed and responsiveness of vim in my terminal and the degree of customization finally, finally made me embrace (neo)vim and see the light, all these years later.
(rust developer life tip: forget racer, it is absolute garbage and ridiculously immature and incomplete. It is eons away from being useful to "code via intellisense" and the list of missing functionality or just simply wrong functionality is longer than the list of things it gets right. Just as I was about to give up on rust code completions, I discovered rls and its mixed racer/rustc approach to completions and haven't looked back. The
ide and language-independent nature of the language server protocol and its blossoming implementations for different cilents and different languages is incredible, I wish it all the best.)
141 comments
[ 3.2 ms ] story [ 185 ms ] threadIt claims to fix the biggest complaint about atom: speed of editing and memory usage of edited files.
They did it by re-writing backing store for documents from JavaScript to C++.
- VSCode is rendering in the DOM what you see, not what you scroll to.
- VSCode is using the correct datastructures, so an insert of a line at the top, doesn't require updating/relayouting all lines below it, but more likely something like log(n) lines.
And these two reasons you can summarize as the difference between old skool engineers with proper training in datastructures, cache behavior and algorithmic complexity -vs- new skool "full-stack developers" that rely on a billion lines of code they haven't written (or understand) and who mainly script a bit in between. The (wrong) assumption in the recent decade was we don't need to train engineers to understand the algorithmic complexity of their code because 'computers will continue to become faster'. That was never true and never will be true, because an exponentially slow algorithm simply won't ever be fast enough regardless of the amount of transistors. And making something like a simple text editor (without syntax highlighting and all of that -- just being able to edit the code), is actually an easy test to distinguish between the two wildly different skillsets.
https://github.com/Microsoft/vscode
But I agree that it is mostly typescript through and through, they just have implemented basically everything as a non-blocking promise.
And most importantly, the extension system cannot block the UI. It runs in a completely different process also.
Compare to something like the ACE editor (an OSS editing component that you can plug into any website) which is lightning fast -- it only renders what you see though -- but the filesize is not at all relevant to the performance.
These are all techniques that people who ever wrote complex UI toolkits are incredible aware of. I don't think that describes anybody who worked on ATOM ever, which means they just have to relearn and re invent this stuff until they get it right.
Generally, these days a lot of developers get a lot of experience combining existing technologies. Proper engineering skills, or even being aware of the data structures you are using and their algorithmic complexity, how cache friendly it is -- all of this is prioritized much less now.
So Atom answers a simply question. Has hardware become significantly fast to not care about proper engineering? No, not really and it never will. If your datastructure is structured in a such a way that inserting a line all the way at the top requires a relayout of every line below that, for example, you will run into real limits.
For that matter, even if your app requires occasional core high-performance bits written into C, that's probably still a benefit to you. Similar to the standard Python argument, which advocates a very similar development pattern.
After all, it's not like you're not compiling it on each platform anyway to get the native app you're distributing.
Which is the idea behind WebAssembly and why we're seeing it discussed more often these days
C++ data models can be write once compile almost-everywhere (all desktop platforms at least) pretty easily. You can write C++ code that compiles on iOS, Android, Windows, and MacOS, and Linux, without any great difficulty.
Making all the UI and system integration code cross platform is a more valuable service. Just dealing with something like the Clipboard on all the above mentioned platforms is a lot of boilerplate code. Not to even get to actual UI widgets!
I thought most of the excitement was about getting away from manual memory management into higher level languages and building something that works across the web and desktop, not just simplifying desktop busy work with native UIs.
Their tagline is "Build cross platform desktop apps with JavaScript, HTML, and CSS"--if you need C++ to truly get the app you want, it seems like the value proposition is severely diminished.
You are still creating objects, be they heap or stack based. You are still choosing data structures and designing systems that will have an impact on object lifetime.
You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!)
And memory is still being fragmented, especially if the data model is complex.
In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues.
Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language.
As you do in any language.
> You are still worrying about taking references during captures of objects, and making sure it is the right type of reference, and that the object does eventually get released. Bonus points if this happens across threads (and with today's async programming models, it will happen across threads!)
In the case of modern C++, Swift, even ObjC–by “you”, you mean the runtime? Following relatively simple rules does not create a huge cognitive burden on developers, I think.
> And memory is still being fragmented, especially if the data model is complex.
Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age.
> In a GC language, that fragmentation goes away. Worrying about when an object is out of scope goes away. Capture as often as you want, toss objects between threads, no worries, it will get cleaned up eventually. There are pitfalls to avoid, accidentally keeping a reference around will leak memory, but that it true in C++ as well. GCs solve most of the issues.
Modern C++ makes it better, but there is still a quantifiable ease of use difference between modern C++ and a GC'd language.
There is also a quantifiable performance penalty to GC’d languages and defragmentation. And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
Most GC languages force the issue for you. Everything on the heap. That said, I'd love it if more GC'd languages were smart enough to know when they can stack alloc. :)
> Agreed, but then, we are speaking here of desktop-class applications, and fragmentation issues should be very rare in this day and age.
They become a problem with any long lived application that throws around large chunks of data. From video games to productivity apps. Soon as interactive runtimes become multi-hour, life gets harder.
> There is also a quantifiable performance penalty to GC’d languages and defragmentation.
Depends on usage. Destructor chains can take up large amounts of time as well, and from the programmer's POV, are about as deterministic as GC pauses. On the plus side, they typically only pause one thread instead of the entire world. :) (Not much help if it is the app's main thread, or UI thread, heh)
> And GC introduces a class of issues that are so subtle, only experienced developers with experience are able to properly debug or even know about.
And they also prevent a lot of those same issues. It is a trade off. But I'd say that for 90% of coding, the cognitive load from GC is lower than from using C++. A brand new C++ codebase written by people who are all strictly following the Right Way to do things will look good, but the majority of code is old. The majority of libraries being used were not written in accordance with the latest C++ spec, every single third party library doesn't use unique and shared pointers, leading to natural conflicts at interfaces between libraries.
Pick a mature (has libraries written in it) GC'd language and that all goes away.
Don’t forget we are speaking about a new component written in Atom, or a new project being started. Legacy code is legacy code; it is almost certainly a pain (even in Java). But when starting a new project and following some basic guidelines, C++ has become somewhat pleasant to work with, something that has not been the case in the past (for me at least).
I can agree with this, with the caveat that old libraries, still in popular use, are all over the place. For one thing, a lot of OS interop relies upon these libraries, although C++17 is aiming to standardize a lot of what used to be OS level functionality.
You are absolutely right and that's the biggest irony of all that, them going down to C++ .
What they should have done is like Sublime Text. Write the GUI in C++ then use Javascript as the scripting layer for your apps (instead of Python).
One of the main goals of Atom is to be the most hackable text editor ever. Given that goal, Electron is the ideal platform for the app. Thanks to node's native module system, we can cleanly drop any component we want down to C++, while keeping our main application logic written in the most widely-known (and fastest-executing, thanks to V8) scripting language in existence. I'm happy with this architecture as opposed to starting in C++ and then bolting on some specific, limited scripting APIs.
To be sure, Atom has performance issues that remain, but we're making steady progress on them, and Electron isn't standing in our way at all.
They seemed to have a lot more beta releases than other versions. Perhaps because there were a lot more changes..?
https://pavelfatin.com/typing-with-pleasure/
Without some concrete benchmarks I'm not inclined to go to the trouble of trying it again.
http://imgur.com/0G3qbpr
One thing that really surprised me was that my terminal emulator made even things like nano or neovim have high latency.
I suspect that most people don't really care that much about the difference between 30 and 10, but care whenever the latency spikes to 60-70 (which is more likely in VSCode and especially Atom, compared to neovim).
(edit: the parent comment has been edited. Mine no longer makes sense in context.)
I'm wondering—if you prefer VSCode, why even comment a post about Atom? I doubt your care that much..?
Atom is built on Electron. That means that it includes a whole version of Chromium (OMG!), and it isn't even optimized, so its size is 5 times that of VSCode.
Is that really a problem? Are you trying to tell me that as a developer you don't have 400MB to spare on your hard disk for one of—if not the most—important tool to work your job, and the size is really a reason to pick one editor over another?
Atom is about 100 times slower than Sublime Text, and like you pointed out 5 times bigger than the insuperable VSCode.
Now, I use Atom as my main editor, because I find it simpler than others for certain things, and it saves be a lot of time because GitHub integration is done very well. Also, I like the name (can't say the same thing about VSCode).
Some people like Atom because they're more productive, and don't care about its size, super-crappy speed, and whatever else you think Atom is worse than VSCode at.
Can we put this thing to rest..?
So is VSCode.
> Can we put this thing to rest..?
Where's the harm in having an actual discussion about this? If you're comfortable with your choice of Atom, you can just ignore anyone comparing Atom to VSCode.
I don't get the point.
It seems more like discussion just for the sake of it, then because of actual, real-life problems.
My laptop isn't even amazingly powerful, and I constantly have 3GB to spare despite the fact that I run many random apps and almost never restart it.
As a developer, I don't see what the problem would be if my main tool occupied even 2GB of memory (and we're talking about 500MB-1GB in most cases).
I never heard any graphic designer complaining about Photoshop occupying 10GB of memory for a logo (which happened to me a few hours ago).
So is VSCode! Hence the constant comparisons.
So it's valid to ask what did the VSCode people do to come to the different result?
On a related note, I wonder about the speed difference now, after Atom has done a lot of optimizations.
I'm also not convinced the feature set is identical. Atom comes with a lot of language support, customization options, and extensibility out of the box.
And no, I don't think anyone is ready to stop pointing out that Atom is slow. Atom can implement a thousand killer features, but until they fix their performance problem nobody is going to switch back to it.
[1] https://en.wikipedia.org/wiki/Visual_Studio_Code
I tried many editors when I decided which one to use—including VSCode—and Atom was the one where I was the most productive by a long shot.
Speed isn't everything. Atom is quick enough for the code I work on, and in other, much faster editors like Sublime Text I would be less productive and therefore slower. For instance, editing settings/packages in Sublime Text in unnecessarily nightmarish. Changing settings and installing plugins in Atom is a breeze.
Who cares if the editor is a few milliseconds faster when you're many minutes slower..? Just because of its excellent GitHub integration Atom is worth 100 times more than Sublime Text to me (even if it wasn't free).
Me. I care. That little hang Atom does after saving a file gets annoying after a while.
I get annoyed about having to switch to GitHub, for instance.
It's fine to have opinions, I'm just annoyed by the fact that every time there's a post about Atom the conversation gets hijacked by "VSCode vs. Atom" comments.
That's why I'm bitching.
I shall go update Atom instead.
How so?
GitHub integration is done very well -- Not nearly as well as the Git integration in VSCode
Also, Atom has in the past been much slower than VSCode in nearly every aspect.
VSCode has a built-in debugger which takes it dangerously close to being called a full-fledged IDE rather than just a text editor with plugins cough Atom cough
The reason they keep getting compared is really simple: they both aim to achieve the same goals, and both use a very similar approach.
One editor I haven't seen mentioned in a LONG while, though, that can probably be considered the 'grandfather' of both of these is Brackets. If I remember right, it had a lot of performance issues, as well.
Is that a bad thing? I like debuggers.
VSCode ranges closer and closer to a full-fledged IDE, which is awesome.
It would be like if Honda made a better car utilizing a Mazda engine than Mazda itself.
(I hate iTunes, and have no idea if the Windows version was a better Windows programs than others, I just thought I'd leave this here)
OMG! is right, imagine trying to make sure the zoo of various Node and Chromium versions on your computer do not have any unlatched vulnerabilities.
And you know? I have 400 MB for one Electron app. I even have 8000 MB for 20 Electron apps. I just do not want to give them because you'll eventually tell me that your containerized Electron-on-Docker-on-Electron virtual machine requires 64GB of RAM to run.
Now, I'm not saying that you should not use Electron ever. But if using a TEXT EDITOR on a laptop with 2GB of RAM requires sacrificing a quarter of its resources, that text editor is not a good piece of software. And if you say I should buy an OP max-spec computer to write freaking HTML, you are creating an unnecessary barrier to CS.
They have a folder with js modules (I didn't look too deep into it, there might be native dlls there too) that's 75 megs, compressing (and i.e.: recompressing on any change, update, download, etc.) would help with disk space taken and loading times. Not even an SSD will beat a zip file kept in memory, SSD, resolving file paths, NTFS, they still have overhead and I'm sure it'll be more than just decompressing out of a zip in memory.
would beat keeping that zip in memory and accessing it to decompress any script when needed. 75M resources 17M resources.zip 6.7M resources.7z
Third party ones aren't even minified which would be free size savings!
It's basically free saving and super common in game dev to package files and not have them scattered like that.
It would be nice to not have to disable .git on mounted servers.
The VIM plugin for Atom is a lot more feature rich than the VS Code version.
amVim does it better, but is missing ; for repeating the last t or f command
This opens two separate windows, each representing a project. Any editor can do this. Parent meant opening two projects in the same window.
This is the number one reason I do not use VS Code. I love having multiple projects open in the same window at the same time, accessible with cmd+p fuzzy search in Sublime.
I prefer thinking of codebases as folders in a file structure then as "projects", so I might be missing something obvious and is probably the reason I interpreted the parent comment's question the way I did.
Actually, that's what I thought when I tried using Sublime Text for a while. It took me hours of editing the JSON file to get it do look and behave like I wanted, while Atom has a very convenient GUI to change settings and install plugins and themes.
When I was finally done, I realized that the project tree view—if that's how it's called—sorts files with folders first like on Windows, and being on macOS it was too confusing for me since that was the only place throughout the OS where that happened.
To me, Atom is the solution to Eclipse's stagnation, Sublime Text's somewhat high price tag (I know we can afford it, I'm just saying), and personal preference, plus really good GitHub integration which for me is paramount.
I wouldn't define myself a uber-geek.
This is getting like Windows vs. Mac. Doesn't make any sense.
Let VSCode be more optimized or technologically advanced than Atom like macOS might be compared to Windows, but without making that the reason why people should immediately switch to it.
You know, macOS and VSCode might be better, but there are people who are perfectly fine and more productive on Windows or Atom.
If you publish a new release and you happen to have a competitor in the same market that is currently eating your lunch people are naturally going to ask what makes it worthwhile to switch.
Sure, but that's not the tone used. Besides a few, most comments are dismissive of Atom and just point out how much better VSCode is and wondering why anyone would use Atom.
It's factions, like Mac vs. PC. There is no productive discussion, here.
I wanted to find out more about this release, and all I got was that I should switch to VSCode.
I'm saying "might very well be better"...
Sorry, English isn't my first language.
Simple answer: Plugins. It'll be the same answer every time this question is asked, for me.
As someone who doesn't see using typescript in the foreseeable future, and doesn't feel impacted by performance benchmark comparisons, VSCode doesn't seem to offer me any compelling reason to switch to it and go through reconfiguring another editor.
http://mohd-ali.com/images/aesthetic.png
This is something I do all the time in atom, and miss quite a bit when using vscode (for typescript).
What I am saying is that VSCode vs. Atom is the same "war" that people who like to use VIM have against people who like to use Emacs. The people who defend Atom/VSCode do it the same way people defend VIM/Emacs, it doesn't matter if one was built with tiger's blood and the other with wolf's blood, the "war" between them is just an ideology, otherwise everyone would be ignoring one and using the other.
SublimeText is written in C++ with the Skia library [1]
It exposes an ABI that you can consume via Python scripts.
[1] https://news.ycombinator.com/item?id=2822114
Web developer-efficient... But when this goes against the end-user efficiency, I'd prefer the latter one.
It's 2017, and after two decades of fighting vi and vim at every corner, I am finally a convert. I spent (and still spend) a crazy amount of time getting neovim to behave the way I expect an IDE to behave, but the speed and responsiveness of vim in my terminal and the degree of customization finally, finally made me embrace (neo)vim and see the light, all these years later.
(rust developer life tip: forget racer, it is absolute garbage and ridiculously immature and incomplete. It is eons away from being useful to "code via intellisense" and the list of missing functionality or just simply wrong functionality is longer than the list of things it gets right. Just as I was about to give up on rust code completions, I discovered rls and its mixed racer/rustc approach to completions and haven't looked back. The ide and language-independent nature of the language server protocol and its blossoming implementations for different cilents and different languages is incredible, I wish it all the best.)
https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
I want to like Atom becuause it's free and open source... but Sublime is so much faster.