I do go back to Atom often because of a few details that I like better over VS Code, but it's a lost cause, and reading this proves it.
Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
What they'd need is a huge architectural overview, and the fact that they're showing off how much they're optimizing proves that they'll never be as performant (or even close) as they'd need to.
Also weird that they blame extensibility. Emacs does it, Firefox does it, Chrome does it, and most importantly VS Code does it. I'm sure it's not easy, but it's done by other projects.
Too bad, because the UI is very nice, package management is very good, as well as not having to edit JSON files for settings (which sure I can do, but I see no added value and I'm lazy).
Memory usage? Sure, but as developers we probably have GB and GB sitting there
GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor.
And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resource hungry? See above, I have those resources for other stuff, not your piggish version of Notepad. A lot of these things can be excused for an OS, a database, crypto currency worker, but NOT AN EDITOR.
But even if I were more tolerant, as you point out the general use case has been abysmal in my experience. If this kind of thing is what you want, I fail to see why one wouldn’t just use VS Code.
You know, I'm not saying those things aren't important.
I'm just saying that the general use case sucks enough that I'd think you'd want to worry about that _first_, then perhaps think about startup time (maybe).
Sorry, wasn’t really arguing with you personally. And I agree, I am way more tolerant than I should be because “shiny”. Last I used VS proper (and it has been a while), it was a pig, but kinda worth it for the developer experience. But as you point out, all that piggishness and the experience is less than great? Umm, someone needs to do a rewrite.
VSCode is really bizzare, in a good way. All the configuration is done through JSON files. It's a good editor as well as an IDE. There's no "projects" or "solutions" or wizards. I almost never run into issues with it.
It doesn't feel like a microsoft product at all. Nothing like Visual Studio.
I disagree. It has smart auto-completion, refactoring, it informs me of errors in my code before I run or compile it, integrated version control, auto-compilation, and many other features.
I use vscode as a Golang IDE. It's pretty comprehensive with the extension that integrates the Go toolchain.
I tried Gogland EAP for a while, and liked it a bit better, but now it's a paid product, I'm happy with vscode (which has 95% of the features I use and 0% of the price).
Atom can also configured via JSON files. They create their config file as CoffeeScript Object Notation (CSON) by default, but nothing is stopping you from changing it to ~/.atom/config.json
VS Code is basically everything Atom tries to be and/or should have been. To me it’s the spiritual successor of the original TextMate: works great out of the box, but can also be customized to fit your needs.
VSCode won me over grudginly. It's faster, lighter, and just as extensible. I was conditioned at an early age to throw holy water at anything Microsoft, and still, I like VSCode better than Atom.
Man you are so pissed and condescending. Do they make you use Atom at your work or are you really that angry that other people use an editor you don't like?
> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
They specifically address those issues in the post:
> Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.
> Removing remaining synchronous IO: - Atom still uses synchronous IO (which blocks the UI thread) in some places... Much of the synchronous IO has been eliminated, but there are several Git-related code paths that we still have not updated, and which kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths and convert them all to use asynchronous IO.
Turns out that for the important things in an editor, React has a hard time optimizing as much. I'm a huge proponent of React, but the right tool for the right job is an important principle for the pragmatic.
I think since then, they've circled around to a much more restrictive and faster virtual dom. React could be made quite a bit faster (as proven by Inferno) without changing the API and moving to a more monomorphic, but verbose API could probably offer a big performance boost.
I've wondered in the past if the best solution wouldn't actually be to render the editor part as a canvas element and remove the normal DOM from the picture completely. VS Code did something similar with their console a few versions ago.
EDIT: Looks like they've given some thought to canvas already (for the next go around). With webassembly, they could even offload to a nice C++ or rust library running and repainting a canvas element in another thread.
This is the exact reason I've commented (and been shouted down for) saying that React is a fad. It's trying to replace fundamental core system with a layer, and do it better. It will never work, it can't.
Eventually everyone will figure out that building "apps" with DOM manipulation will never be as performant as lower level coding (ie, not a script layer), and they will move on. And the DOM will return to light apps and general purpose websites with basic interactivity.
How can it go any other way? Btw, the only reason I am posting this is bit out of frustration that stating something so obvious makes some people really angry. I suspect its because they have invested so much in React, and don't want to consider it a temporary hack until webassembly or shadow dom or some other tech makes it completely obsolete.
I tried out Atom, it's miserably slow. And I recently downloaded VScode, just to give it a whirl, and it's impressively faster. But I use Komodo, and that is based on Scintilla and Firefox, and it works just fine.
React’s declarative Api is much easier to read and update than working with dom calls directly. And React itself doesn’t even have to target the dom, as with react native which generates native system UI
That doesn't make sense...the browser always does the rendering of the dom. Not react.
React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom.
It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make 1.
Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes.
Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI.
If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?
> In May, we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible. We made use of the latest DOM technologies and rendering techniques, and built a tiny React-like library called etch that allows us to structure our rendering code cleanly while still allowing for imperative DOM manipulation for maximal performance in certain code paths. The result is that when typing, typical DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.
Because they already implemented something similar as per the blog post.
React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.
> Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
Adding to the other comments about having better use for my memory than piles and piles of JavaScript bloat, how do you think GC performance is affected by the amount of memory it has to manage?
All the micro lags in rendering and input handling are affecting your performance consciously and subconsciously.
You know, the exact thing you complain about:
> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
> Who cares about start-up time? I only open the thing once/day.
I care.
I live in three editors: Xcode for iOS/Mac/Swift on server development, VS Code for Rust, Go and Python, and Sublime for a thing that starts up fast, opens new windows fast and can deal with huge amounts of text. I wouldn't mind reducing that number to two, but it doesn't seem likely to happen anytime soon.
We as developers might have plenty of RAM to waste, but our users usually don't. If it runs well on our machine but not in the users', what good is it?
Even if it runs well on the users' machines, how many resource-heavy applications can they run concurrently? Will they have to close one to open another?
Unfortunately the attitude is pervasive and electron is also used for applications more in line with what your mom would be using. I think many would be shocked that a good chunk of their audience has less than 8GB: http://store.steampowered.com/hwsurvey
It's also a mistake to assume developers have plenty of RAM to waste. A couple of years ago I was using a potato for coding on the way to work that only had 2GB, which made atom a no go.
Also, what happened to the idea of dog-fooding? It's not dog-fooding if your on a machine much faster and with more memory than your users. I think the problem with windows 10 is that all the devs were dog-fooding on top of the line surface pros.
Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal.
What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness.
What they'd need is a huge architectural overview, and the fact that they're showing off how much they're optimizing proves that they'll never be as performant (or even close) as they'd need to.
Also weird that they blame extensibility. Emacs does it, Firefox does it, Chrome does it, and most importantly VS Code does it. I'm sure it's not easy, but it's done by other projects.
Too bad, because the UI is very nice, package management is very good, as well as not having to edit JSON files for settings (which sure I can do, but I see no added value and I'm lazy).