Atom 1.33
blog.atom.io
blog.atom.io
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.
$ brew cask reinstall atom
...
atom was successfully installed!I don't think I've ever introduced an Atom user to VS Code and they stick with Atom. Every one of them switches.
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.
And you can do a lot to clear up the UI of features you don't want.
Not saying you're wrong in your feelings or decision to switch. But there might be remedies!
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...
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.
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.
Yeah, I can get by with cmd+z, but it would be nice not to be forced to context switch when I'm thinking in ex-mode.
Although now I've read that Atom is supposed to be faster than before, so I'm going to give that a try again.
But it's been four years and they still havn't fixed jump to definition in PHP.
Visual Studio Code has this, out the box. And it works really well.
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
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.
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.
VS Code still uses Electron and that's pretty snappy.
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.
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.
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.
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.