5 ms·
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-u
by nkkollaw 9y ago
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).
- mikestew 9y agoMemory 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.
- nkkollaw 9y agoYou 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).
- mikestew 9y agoSorry, 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.
- bdcravens 9y ago> I fail to see why one wouldn’t just use VS Code Github is cool, Microsoft isn't. /s
- HumanDrivenDev 9y agoVSCode 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.
- lolc 9y agoMaybe I should give VSCode a try then. I've been using Atom for a year now and some things just never felt good.
- sus_007 9y agoI was in your position a year back. Now I'm in love with VSCode. Do give it a try.
- maskedSlacker 9y agoVSCode 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.
- stouset 9y agoVS 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.
- nkkollaw 9y agoI don't know about this. Configuration via JSON is common (Sublime Text, the most popular), I'd say that it's Atom that is bizzare on this aspect. As for "projects", I'd argue that if you open a folder, that's your project/workspace/whatever. Just thought I'd add this in case someone who doesn't know VS Code[ well] gets confused.
- eagsalazar2 9y agoMan 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?
- shmageggy 9y ago> 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.
- RobertRoberts 9y agoMaybe they should rewrite it in React. I've been argued into the ground under the guise that it's faster than the browser's rendering of DOM.
- kalcode 9y agoThat 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. This has nothing to do with Atom.
- taternuts 9y ago
- bmaupin 9y agoI actually like that Sublime Text keeps its settings in JSON files. That way I can pop em in git alongside the rest of my workstation configuration.
- ASalazarMX 9y agoWe 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?
- nkkollaw 9y ago> We as developers might have plenty of RAM to waste, but our users usually don't. Mh? This is a tool for developers. I don't get your point. My mom isn't going to use Atom for her shopping list :-)
- flukus 9y agoUnfortunately 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 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.
- sigstoat 9y ago> Memory usage? Sure, but as developers we probably have GB and GB sitting there... caching the contents of the disk, so that you get performance and improved battery life. if you're using a modern OS, your RAM is never just "sitting there".
- keymone 9y ago> 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.
- jurip 9y ago> 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.