I use Atom daily for work, and I am overall satisfied with the editor and its ecosystem, in particular the mammoth improvements the core team has made toward addressing speed issues that plagued the editor in prior years. I haven't tried the new GitHub integration features in this package, but they seem cool.
That having been said - Atom devs, if you're reading this, _please_ put a priority on fixing the auto-update / 'Restart and Install' feature on macOS.[1] If it's not fixable, please remove the option and offer a workaround.
It's gotten to the point where I now simply download the Atom update in browser and manually replace the package binary in my Applications folder, knowing the auto-update will fail.
Hi. I've been using VS Code for a bit now but I'm actually going back to Atom.
I run into a lot more bugs with VS Code--or at least the (very few) plugins I'm using with it--than with Atom. For example When writing JSX, I'll occasionally add a wrapping element around another, and suddenly I'll get lint warnings about unexpected tokens. Using the "reload window" command or exiting and opening the editor again makes it work, but otherwise I can't get the error to go away.
I also find it to be far noisier by default than Atom. There are so many things on the screen at any given time. The side nav has a bunch of icons, the sidebar seems weirdly un-compact, and it keeps trying to suggest code snippet completions for me. It also seems conventional for VS Code plugins to add inline indicators to the editable region to show things like failing tests or previews of CSS colors. I find things shifting around suddenly on the screen visually jarring, and it makes moving the caret around feel weird. Some of these things are fixable via options, but I like that Atom doesn't require nearly as much fiddling in order to get it to quiet down.
Also, it's slightly annoying to have to reload the editor after installing/removing/disabling/enabling a plugin.
The VS Code developers observed that things can pretty tangled with open-ended plugins and HTML rendering, so they cordon off plugins to separate processes, and only offer limited UI control to plugins. This helps keep things stable and fast, but I think the ability to have plugins easily create new UI in an open-ended way is the coolest feature that Electron enables in an editor.
Atom offers a lot more UI control to plugins, and in my experience, is still acceptably fast and stable.
Same. With VSCode most plugins "just work" as I expect them too, and it's also usable with 0 plugins.
Atom plugins otoh... they're a s-fest of stuff requiring other stuff and never managing to ever auto-magically just work. For Python and JS VSCode is amazing! Also there's a Jupyter plugin that works, an integrated terminal that just works, making it idea for data-science and ML tasks too...
I have no idea what the Atom guys are doing, because in theory I'd like Atom more, but in practice I fee like wanting to throw my laptop at a wall after 30 min of using it because of how semi-broken everything is.
Does anyone anyone have a "curated" set of Atom configs and plugins that "just work"? Maybe by making it into smth like "a distro", it could be usable for people with 0-to-little-patience like myself...
I switched, after a prior history of many other editors, to VSCode, and then to Atom. One main reason: the vim plugin. The VSCode one was (is?) just not good. Atom's is quite good.
VSCode is better for most people; it's a great editor, and does more out of the box without configuration. However, if you're someone who DOES feel the need to tweak everything until it's just right, VSC doesn't hold up. JSON configuration is just clunky. Atom is, at least in some aspects, scriptable without the need to build a full plugin (though it's certainly no emacs), and that's quite valuable. And, when you introduce the atom-ide package, the gap in completion and debugging functionality between the two gets quite a bit smaller.
Also, anecdotally, Atom seems to have had better performance across my machines; especially on lower-end hardware. I'm only working on small-medium sized projects, so this might just be me.
And I went from Atom to VS Code and then back to (Neo)Vim again. I haven't yet seen a Vim plugin which is complete enough for me to use without needing to change habits, so I just use Vim now and for some special situations VS Code.
Although now I've read that Atom is supposed to be faster than before, so I'm going to give that a try again.
atom-ide (https://ide.atom.io) brings a lot of the great intellisense features over to Atom. It's most likely not completely on par, but as far as I can tell and based on my own usage, it's beyond good enough for most work.
I really love Atom over any editor I’ve ever used in the past, but damn it can be slow, so I hope this update addresses some of that. I mostly use it for writing code because of the extremely intuitive editing features, advanced regex, and beautiful syntax highlighting. However it can’t handle really large files like logs and such because it tries to prase everything and consumes tons of memory. For that nothing seems to beat Notepad++ on Windows (written in C!). One thing to remember is that Arom is an Electron app and as such is essentially a browser application, which sadly could never be as fast as a native app.
Is Atom developed by microsoft now? It would be weird for them to invest in developing both editors in the long run, considering how much crossover the two have.
Is the contributor community strong enough that it would keep going strong regardless? I'm not sure how many contributors were from Github vs elsewhere
I haven't used Atom for more than a year. Is the performance better now? Faster than VS Code? Would it still crash if I accidentally opened a 100mb CSV file?
I wish they could get Ruby working in Atom out of the box. I still can‘t believe how weak the tooling is in the Ruby on Rails world. Even Jetbrains fails miserably. Why on earth can‘t we have decent code completion in Ruby?! If the human brain can tell what will be available why can’t my computer.
I don't think even the human brain can consistently figure out what's going to be available in Ruby.
Oftentimes, the only way to know is to set a breakpoint, run the code, and inspect it at runtime. This is why the tooling sucks even more for Ruby than most dynamic languages, and the code completion and static analysis will almost certainly always be worse than the equivalent tooling in a statically typed language where more things are knowable.
If you feel so strongly about tooling, I recommend learning Kotlin, Go, or C#, all of which offer incredibly strong tooling with essentially perfect code completion, jump to definition, and real time code analysis.
I once did a web-project in Go just for the tooling. What I gained there was lost in the verbosity and the write everything from scratch mentality when it comes to webdev in Go.
Really? What’s wrong with RubyMine? I use it for RoR almost daily and it seems to kick ass. It’s not perfect, but then again maybe I don’t know for better. But I agree, developing in Ruby sucks in Atom.
Does Atom work with mounted directories yet? Especially sshfs? I'd love to go back to Atom, but unfortunately, last time I tried to use it, it had massive indexing problems when working through mounts.
The vim plugins in atom completely blow VSCode's out of the water. It's split up into two packages ('vim-mode-plus' for most of vim, and 'ex-mode' for handling ex commands), but they work together very well.
In my experience (which certainly does not reflect everyone's), Atom wins in performance these days, too. Startup time is a bit slower, but once it's running it's quite snappy. It feels... less like a webapp than VSC does, if that makes sense.
That's a poor comparison. The difference between back then and now is: Back then, no one knew we'd have such an exponential increase in computing power. But we got it. Today, everyone expects that tomorrow will yield an exponential increase in computing power, because that's the way its always been. But that increase isn't coming.
In other words, products back then were never engineered with that exponential increase in mind. Often it just happened, accidentally or because the creators had a large vision that genuinely needed that much memory. Products today, like browser rendering runtimes and by extension Atom, literally are. The problem with writing code engineered ideally for the computers of tomorrow is that, in the realest sense of the word, tomorrow never comes. Today, its "32gb of memory is expensive and rare, but it'll get cheaper." You keep that product development mindset and tomorrow it'll be "64gb of memory is expensive, but it'll get cheaper." Your product will always be slow. Tomorrow never comes.
And it'll take teams like the Chrome team far too long to realize that we're fucking done with exponential increases at an industry level. They're over. Maybe in twenty years we'll get a revolution like memristors or graphene or something, but that shit is not going to be soon. The backend engineering world has already figured this out and moved hard to scale-out instead of scale-up, but the UI world is still caught-up in this pretty little fantasy that, well, you know, the next iPhone will have 6gb of memory so it'll just be a little slow until then.
> Everyone knows Atom uses a lot of memory. At some point in the very near future, it will no longer be important.
My five-year-old Mac has 16 gigs of RAM. I won’t buy another that has less than 32 gigs.
As a counterpoint, my 3 year old laptop has 8GBs if memory, my server 12gb and none of them are maxed.
My next unit won’t have more than 16gbs, because that would be an absolute waste.
Maybe use less Chrome and Chromium/Electron based shit, and you’ll find out how insanely much ram 8GBs actually is?
I know this argument tends to become a bit philosophical, but if (ab)using memory the way that browsers or Electron does means that programs can be written faster, be safer, and can run on more platforms, then is it really being wasted?
Sure, it's not runtime efficient in many cases, but that's not the only thing that matters, and it's pretty far from the top priority for many.
I quite frankly make a ludicrous amount of money doing software development. Spending even $1000 on an upgrade to my machine that makes me 1% more productive would end up paying for itself in less than a year.
For me, RAM isn't something I worry about, I have 32GB in this system and i'm not anywhere near maxing it out at my current day job (and for what it's worth, my atom instance that i've had open for about 3 days now is taking up a combined 432mb of memory at this moment, Android Studio is sucking down a whopping 1.5 GB. In my experience the "ram usage" of Electron is blown wildly out of proportion, it's really not that bad to be honest). Atom makes me more productive, so I use Atom, and the memory usage could greatly increase and it wouldn't impact me at all.
Some people work differently, they either aren't as fortunate as I am and can't afford the fancy hardware (or can afford it but simply don't want to buy it, which is okay!), or just prefer working in an environment which starts up faster or uses less resources, or anything else. For them there are other editors, other IDEs, other software they can use.
None of them are objectively "bad" or wrong, they just prioritise different things.
This can go the other way too => People kept complaining about Internet Explorer for years. Then one day better alternatives showed up (Firefox, Chrome) and dealing with sub-par experiences was no longer a necessity.
People complained about the lack of functionality in IE. Atom is functional and iterating fast.
It works great on my 5 year old Mac Book Pro with 16 GB. I understand that some people do have more minimal hardware, but 16GB looks like a $100 investment. Performance and memory usage are being addressed.
I simply see memory usage as less of a problem in 2018/2019. I want more functionality.
That having been said - Atom devs, if you're reading this, _please_ put a priority on fixing the auto-update / 'Restart and Install' feature on macOS.[1] If it's not fixable, please remove the option and offer a workaround.
It's gotten to the point where I now simply download the Atom update in browser and manually replace the package binary in my Applications folder, knowing the auto-update will fail.
[1] https://github.com/atom/atom/issues/2860