Atom 1.34(blog.atom.io)
blog.atom.io
Atom 1.34
https://blog.atom.io/2019/01/08/atom-1-34.html
32 comments
I’m old school vim person, so don’t have much clue. Is atom still relevant or is vscode taking over everything?
Our shop has 4 devs, one on VSCode, unlikely to convert, three on Atom. I was the last covert to Atom here - after 15+ years on jEdit.
For a second there, I thought I finally found the other person on the internet who was a jEdit zealot. But then I realized it's the same person I've known for years ;)
What makes you stick to Atom? I switched to VSCode due to Atom's terrible performance when opening huge files.
What makes you stick to Atom? I switched to VSCode due to Atom's terrible performance when opening huge files.
:) I don't open huge files, finally found a good SFTP plugin, php-debug hooks with xdebug.
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
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
I used Atom for a couple years and raved about it's features and package management but when it came to using it as an IDE, it fell short for one reason. It doesn't have a configurable way to debug across all languages. For example, try debugging python vs node. Python works well but node doesn't afaik.
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.
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.
VSCode is the only Electron app that I care to have on my computer, mostly due to TypeScript and Rust.
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.
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.
At the same time, on a giant project, I'm finding VSCode's performance starts to fall apart completely where Atom performs the exact same as before.
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.
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.
Got To Symbol is basically non-working in non-trivial sized Python projects and doesn't seem to have anything to do with whether or not ctags is installed.
https://code.visualstudio.com/docs/editor/editingevolved#_go...
https://code.visualstudio.com/docs/editor/editingevolved#_go...
For merges and other finicky git actions I’ve been increasingly turning to Atom instead of the commandline. I like how it auto-formats my commit messages to line wrap and how it makes highlighting merge conflicts easy.
For everything else these days I use VSCode.
For everything else these days I use VSCode.
I know this is not a popular opinion but I feel that atom never had the right priorities for a project.
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.
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.
It's very popular opinion and it's demonstrably wrong. Atom was carving out niche from all the fast and responsive text editors by being open source editor with plugins that are easy to write, inspect and fix when they are buggy. Only dangerous competition for atom is vs code because it does exactly the same only a bit faster.
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.
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.
Nah, I remember being able to do all of that with Windows commercial editors like SlickEdit.
So those Atom "innovations" are only relevant on a market where developers refuse to buy their tools.
So those Atom "innovations" are only relevant on a market where developers refuse to buy their tools.
But your wants and needs aren't universal.
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.
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.
> 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.
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.
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.
A big problem I have with emacs, and I fully acknowledge that it's shallow and superficial, is that it looks bad.
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.
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.
Spacemacs looks beautiful tough, and has some pretty nice defaults (for example, it automatically adds a layer for each language you're using, so you have good IDE-like features without fuzzing with packages).
SlickEdit does all of that while being native, fast and handling big data sets.
I'm happy there are options, but Atom does all that as well, and it uses the same tech that I'm working with every day, and it has extensions for just about everything, and it's free software.
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.
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 was a big fan of Atom, but it's constant performance problems combined with the fact that even after Atom's team rewriting huge parts of the project in C++, doing witchcraft and what not, made me switch to VSCode.
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'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.
Do you have any more info on active development stopping on Atom?
I'm saying this based on the decrease of activity in Atom's repo (publicly visible in the "Insights" tab in their repo) and the fact that the last few releases haven't had any significant changes, expect the GitHub integration.
Interesting...
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.
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.
I'm curious what atom does that VScode doesn't? I can see why someone wouldn't want to use either Atom or VSCode for devops, but I really can't imagine a situation where I'd choose Atom OVER VSCode or vim/nvim or even emacs?
For me it's that VSCode has targeted a slightly different market.
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.
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.
And that MS bought GitHub and despite them staying the opposite I don’t believer Atom will be given the same attention as VS Code. FB have archive their plugins and the ex React manager stated that they just didn’t use it. Atom did some rendering refactor work to go AST based recently and it was since then that I’ve noticed a whole load of stuff breaking. Particularly the FB plug ins which of course will no longer be fixed. The problems with big files crashing it means I’m moving away. VS Code seems like the best way to go but it’s hard to go MS.
I was an Atom user until 1.30 or so and I really like its UI, but sometimes it would just max the CPU usage in my Linux box until I closed it and opened it up again. I don't like VSCode as much, especially its clunky Git interface, but it is more stable than Atom and I'm sticking with it for now.
It seems like all of these changes are related to being able to use git inside of atom, but I use the terminal for that and have zero desire to use clunky GUI. The last few release haven't addressed any of the issues or really progressed the editor forward.
Will Electron's development slow down when Atom has other strong competitors and lose traction?
commit previews: https://github.com/atom/github/pull/1767
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.