Atom 1.34
blog.atom.io
blog.atom.io
Additionally the Atom-IDE packages and what will happen with them, many of them have PRs that have been merged in to fix bugs but never published to the package (for about a year now). Although Facebook dropped support for Atom-IDE it still has nearly 1 million downloads and largely works well but can no longer be contributed to since the repo is archived and the packages aren't up to date.
What makes you stick to Atom? I switched to VSCode due to Atom's terrible performance when opening huge files.
Really it took me many months of tweaking to get Atom to be a daily driver - I don't want to do it again soon
OTOH vscode does have a way to do this using a `launch.json` file which is flexible enough to add custom debugging profiles for a single project and it can be stored directly in version control. I tried the editor out because of this one feature alone in order to debug node and haven't looked back.
Interesting how Microsoft manages to do in TypeScript stuff that Github not even with C++ managed to (according to the interwebs), regarding performance.
Now that they are also part of Microsoft, maybe they could share some information among them.
For example- it's not uncommon for Vim mode in VSCode to just stop functioning for 5-10 seconds on large projects while other addons continue operating.
I keep switching back and forth, primarily because VSCode's performance wins are so deceptive- it will feel amazing and look cool on some things, then in completely unexpected places just absolutely shit the bed. So I hop back and forth, and have even started working on building my own plugins for VSCode to do the things no one's added to it yet that Atom has addons for.
https://code.visualstudio.com/docs/editor/editingevolved#_go...
For everything else these days I use VSCode.
A text editor’s primary goal is to be fast and responsive.
Atom uses a rendering layer that makes no sense in the context of a text editor.
Using a DOM introduces all this cruft that takes away from actually editing text files.
What you are saying is similar to that the Firefox never had priorities right because instead making itself faster and more responsive it made possibles all those script and DOM based extensions.
Being able to extend your tools without messing with binaries or learning dialect of lisp and some weird gui toolkit is a huge feature that Atom brought to editor market.
So those Atom "innovations" are only relevant on a market where developers refuse to buy their tools.
My perfect editor needs to be as configurable and customizable as possible, and I couldn't give a rats ass about startup performance or large file rendering performance.
For me, an editor where I can't display inline images alongside text which is in multiple languages (including some RTL languages) while linting and providing IDE level features all while displaying inline test coverage results is worse than an editor that starts instantly.
From that perspective, a browser is the perfect abstraction.
It's okay if Atoms priorities aren't for you, but saying they are wrong is like saying trains are wrong because they can't do 0 to 60 in 4 seconds.
Emacs does provide these features, and it's not too slow at startup either. It's a really nice operating system "abstraction"... too bad that they haven't gotten around to making a good editor for it.
I stare at this thing for hours a day, I like it to look nice.
That combined with the fact that I'm in JavaScript all day long, so it's super easy to extend and modify Atom, means that it just wins out.
Atom is also a LOT easier to pickup than emacs ever was for me, and I tried a few times.
And that last part is suprisingly important to me. I'm not opposed to paying for software (hell, I use Windows as my development environment of choice!), but with the amount of time I spend customizing, and relying on my editor, it would have to be significantly better before I'd give up the ability to throw together a quick extension to integrate a homegrown test runner, or add syntax highlighting and debugger integration for a business basic style language that I work on from time to time, or be able to dive in and fix bugs or make changes to the core editor in cases where I run into a bug or want to tweak something.
Native just isn't something I care about. You might as well try to sell it by telling me that it uses a fantastic color blue for it's chrome.
And Atom handles big files just fine for me (at least up to a few hundred mb), but an editor is also not the tool I reach for in those cases (opting to pass stuff through CLI tools once it gets above a few megs), so an editor that handles those large files and datasets also doesn't benefit me and my process that much.
I have my complaints about Atom (the biggest at this point is that it sorely needs some direction in the linting/ide side of things. Every plugin does things slightly differently, and with Facebook dropping maintenance of the atom-ide set of packages, I fear it's only going to get worse), but I'm generally happy with it. Maybe I'm just getting old, but every few months I tend to try out alternatives, and I always end up coming back.
I'm still really not sure how/why VSCode feels so responsive and performant compared to Atom, which, according to Atom's devs lengthy blog posts, went through a pile of refactoring, focused exclusively on performance.
Edit: Also, staying with Atom isn't really viable at this point, since development was pretty much halted, in favor of X-Ray (aka Atom 2.0?). The only significant changes that are being made are the GitHub-integration related features.
I’ve been using Atom for the past 3 years. I’ve tried VSCode but it just doesn’t work for my needs (I’m more DevOps than a developer). Not sure what I’ll do if Atom is EOL’d.
In Atom, plugins/extensions are king, and they can do EVERYTHING. Most of what you see in the UI is a plugin. Tabs, the file-listing sidebar, syntax highlighting, etc... If you want, you can replace the file tree with another package, or you can replace tabs across the top with another plugin that does tree style tabs along the side, or you can make a plugin that embeds the site you are working on in a pane in the editor, or one that gives a full image editor in the editor, or more. There is no limit, because plugins pretty much make up the entire editor.
VSCode on the other hand is designed to try and handle most of that on it's own, and plugins are much more limited by design. Many involved with Atom attribute much of it's "poor performance" on the fact that plugins are so powerful. All it takes is one poorly written plugin to break the ability for the editor to handle large files (because that plugin was written in a way that it reads and analyzes the whole file when loaded), and the API surface needed to support that power limits the optimizations that can be done. VSCode tried to stop that, but by design it ended up with a much more limited set of things that plugins can do.
For most, it seems VSCode's trade offs are better. Most people don't need crazy plugins and anything special can be rolled into the editor itself if needed. But I personally like Atom's ability to swap out even core elements and make my own plugins which have the ability to do ANYTHING in the editor. And every time I've tried VSCode I became annoyed at the limitations that were imposed, and I felt I was constrained in how much I could customize and modify the editor to my liking, so that's why I don't use it and I stick with Atom.