Atom 1.36(blog.atom.io)
blog.atom.io
Atom 1.36
https://blog.atom.io/2019/04/09/atom-1-36.html
74 comments
I think you forgot who owns GitHub.
fyi, the GitHub PR extension[1] for VS Code has review comments in the editor.
[1] https://marketplace.visualstudio.com/itemdetails?itemName=Gi...
[1] https://marketplace.visualstudio.com/itemdetails?itemName=Gi...
VS Code has had excellent git integration for a long time, as well as GitHub-specific integrations through an extension.
Atom may have started the move towards lightweight (relatively) IDEs, but VS Code is undoubtedly the more popular one. Honestly, when I saw this post on HN I was quite surprised to see that Atom is still actively developed - if there's anyone reading this that prefers Atom over VS Code, I'd really like to find out why?
Atom may have started the move towards lightweight (relatively) IDEs, but VS Code is undoubtedly the more popular one. Honestly, when I saw this post on HN I was quite surprised to see that Atom is still actively developed - if there's anyone reading this that prefers Atom over VS Code, I'd really like to find out why?
VS Code, like Python, seems to be the second best tool on everything: it looks good but not as much as Atom, it's fast but not like Sublime or Vim, it's a lightweight IDE but not a full IDE.
I agree except for TypeScript and JavaScript - vscode is the best code editor I've experienced for both.
> VS Code has had excellent git integration for a long time
I don't agree. Last time I've checked vscode fails un some rather basic requirements, as for example vscode's file renaming functionality is entirely oblivious to Git which causes unnecessary problems to the user.
I don't agree. Last time I've checked vscode fails un some rather basic requirements, as for example vscode's file renaming functionality is entirely oblivious to Git which causes unnecessary problems to the user.
Any thoughts on which is more friendly for (complex) plugin writing?
I've been wanting to add multi-cursor modal focused features to an editor for a while and I've been debating which editor would be the best one to write for. Thoughts?
I've been wanting to add multi-cursor modal focused features to an editor for a while and I've been debating which editor would be the best one to write for. Thoughts?
Prediction: I believe eventually MS will kill Atom or let development languish. People will complain that "MS is evil" and "look who they were in the past" and so on, but devs will go where the features are.
VS Code is one of the finest examples of open source Done Right™, and while it owes something to Atom and Electron, this is pure open source darwinism.
VS Code is one of the finest examples of open source Done Right™, and while it owes something to Atom and Electron, this is pure open source darwinism.
Can anyone who has stayed with Atom after evaluating VSCode comment on why to stay with Atom? I switched to VSCode and would never consider going back to Atom at this point.
Since the GitHub acquisition, it makes no sense for MS to maintain both and I agree 100% with the parent comment that this will be killed soon.
Since the GitHub acquisition, it makes no sense for MS to maintain both and I agree 100% with the parent comment that this will be killed soon.
Two things about VSC, in comparison to Atom, that are Done Wrong:
1) Extensibility. There's like a dozen times more friction involved in creating a plugin for VSC than for Atom. Atom was built to be as easy to change as a web app. They also created apm, which is sort of a clone of npm, for installing plugins.
2) Configurability. I can set personal keyboard shortcuts very easily, and in a way that's easily transportable between installations. I can create a new theme in minutes. Also, the way it handles the config for individual packages is well thought out. Plus, I can tarball my packages directory, extract it to a new machine, and it's basically ready to go with everything.
It's very possible for VSC to improve in these areas. In fact, I'd love to see an "Atom mode" that changes the UI/UX to more closely resemble Atom (and, somewhat by extension, Sublime). You laugh, but there's a reason that every editor takes a swing at a "vim mode". People get comfortable with the aesthetics of their tools.
It's very possible for VSC to improve in these areas. In fact, I'd love to see an "Atom mode" that changes the UI/UX to more closely resemble Atom (and, somewhat by extension, Sublime). You laugh, but there's a reason that every editor takes a swing at a "vim mode". People get comfortable with the aesthetics of their tools.
> there's a reason that every editor takes a swing at a "vim mode". People get comfortable with the aesthetics of their tools.
To be fair, vim is radically different in terms of navigation, keybindings, capability, etc. than your average gui-based text editor. I am not saying that your point is wrong, but vim is sort of an extreme example of a. the difference between vim vs. other editors, and b. the zeal with which vim users tend to cling to it (as a vim user).
To be fair, vim is radically different in terms of navigation, keybindings, capability, etc. than your average gui-based text editor. I am not saying that your point is wrong, but vim is sort of an extreme example of a. the difference between vim vs. other editors, and b. the zeal with which vim users tend to cling to it (as a vim user).
It looks to me that keyboard configuration is pretty similar:
https://flight-manual.atom.io/using-atom/sections/basic-cust... https://code.visualstudio.com/docs/getstarted/keybindings#_k...
With VSCode, I haven't had any trouble moving my keybindings file between installations, even between my Windows and Mac environments (I do the same with my theme, and it works great as well).
What functional difference between the configuration styles did you run in to?
https://flight-manual.atom.io/using-atom/sections/basic-cust... https://code.visualstudio.com/docs/getstarted/keybindings#_k...
With VSCode, I haven't had any trouble moving my keybindings file between installations, even between my Windows and Mac environments (I do the same with my theme, and it works great as well).
What functional difference between the configuration styles did you run in to?
Simple is not always better. Especially with plugins you often also want a certain level of quality, organisation and control. I don't know much about the difference between Atom and VS Code on that front in detail, but compared to the more customizable editors (Emacs, vim, Sublime) I was always impressed with the quality of VS Codes plugin-system. While Atom made for a more messy impression, and it was at last the reason why I started to use VS Code more as a side-editor, instead of Atom.
Funny, I just commented on my desire to pick one of the top editors to write a complex plugin in.
While VSC sounds like a better editor, I want to write a multi-cursor, modal based editor with some UI tweaks. Ideally I'll use Xi long term, but I'd like a prototype working first. By your description, it sounds like I should stick to Atom for plugin development then?
While VSC sounds like a better editor, I want to write a multi-cursor, modal based editor with some UI tweaks. Ideally I'll use Xi long term, but I'd like a prototype working first. By your description, it sounds like I should stick to Atom for plugin development then?
I think you'll find that it's easier to do in Atom. However - Atom's API is also probably easier to shoot yourself in the foot with.
Maybe try getting started on both, and see which one is easier or more comfortable?
Maybe try getting started on both, and see which one is easier or more comfortable?
Atom's user interface feels more ergonomic. Atom can show panels on the left and right at the same time, so you can set it up to have the file explorer on the left, and Git on the right, enabling you to work without having to switch between views. The small buttons for quickly folding panels are also a nice touch.
https://github.com/Microsoft/vscode/issues/26777
https://github.com/Microsoft/vscode/issues/26777
Personally I strongly prefer the UI of Atom, especially the iconography, settings menu, and visual layout. VS Code has a lot of extra features it shows by default that for me are just distracting. I love zen mode in Atom and the package ecosystem has been fantastic for me. Teletype is a killer feature, it's such a joy to use and makes me feel like I'm in the future. I've seen a lot of complaints about typing latency but I haven't noticed a difference between Atom and Sublime on either my OS X laptop or my work PC.
I also have a massive personal bias against Microsoft, so take this with a grain of salt.
I also have a massive personal bias against Microsoft, so take this with a grain of salt.
Psst - Microsoft owns Atom too...
I followed the crowd on the switch from Hot Dog Pro to Notepad++, then followed the crowd again to TextMate. Then again to Sublime Text. Then again to Atom. I installed VSCode and it took over my file extensions without asking me and I got annoyed and was going to go back to Atom, but then wondered why I was still playing this game. So I switched to Emacs.
Now I wish I did that 20 years ago!
Now I wish I did that 20 years ago!
Emacs is amazing and I still use it when I'm inside an ssh session. But I'm a convert to VSCode because of the node debugging capabilities. Those are just awesome.
Why? (compared to Sublime Text, Atom and VSCode)
I think it's a case of "you can't be told, you have to discover for yourself"... I've written it off a few times in the past. I thought Emacs was just a text editor - and after trying it a couple of times it seemed like a clunky relic with really stupid keybinds.
This time when I tried it I started to realised that Emacs is a text editor like a saucepan is a popcorn maker: it can do it, but that's not the point.
Once you commit the stupid keybinds to memory, it works the same in most "modes" - git mode, JS mode, file management mode, ftp/remote file mode, hackernews mode... Now I rarely leave Emacs - my entire workflow is inside it and everything starts to feel like "one". It's replaced a dozen third-party apps and websites I'd normally use. I'm annoyed when I have to leave.
It's crap by default, you have to make it your own. Then it's lisp all the way down. You can ask "what is the command bound to the down arrow key?" and it says "next-line". Then you can ask "what is 'next-line"? and it tells you all the function, including a hyperlink to the actual executable source code that you can inspect, or change in place, or use in your higher level scripts.
It's simultaneously living in the past and way in the future. I wouldn't outright recommend it to anyone trying to choose between VSCode and Atom though... you'll just have to discover it for yourself in 20 years time ;)
This time when I tried it I started to realised that Emacs is a text editor like a saucepan is a popcorn maker: it can do it, but that's not the point.
Once you commit the stupid keybinds to memory, it works the same in most "modes" - git mode, JS mode, file management mode, ftp/remote file mode, hackernews mode... Now I rarely leave Emacs - my entire workflow is inside it and everything starts to feel like "one". It's replaced a dozen third-party apps and websites I'd normally use. I'm annoyed when I have to leave.
It's crap by default, you have to make it your own. Then it's lisp all the way down. You can ask "what is the command bound to the down arrow key?" and it says "next-line". Then you can ask "what is 'next-line"? and it tells you all the function, including a hyperlink to the actual executable source code that you can inspect, or change in place, or use in your higher level scripts.
It's simultaneously living in the past and way in the future. I wouldn't outright recommend it to anyone trying to choose between VSCode and Atom though... you'll just have to discover it for yourself in 20 years time ;)
Do you use it as a debugger? For me, this was the difference in switching (when I am in a desktop environment) to VS Code. The debugger is just so powerful and I have no learned (despite using Emacs for 20 years) how to replicate that in Emacs.
https://github.com/emacs-lsp/dap-mode brings vscode debugger into Emacs.
Nope, just lsp-mode (and Tide). Perhaps that'll take me another 20 years, but I've poured so many hours into debuggers and have never found them as useful as I think they should be. I'm probably "holding it wrong", and if so - I'll get there eventually!
I got it, but I'm not sure I'm ready :-) Thanks for sharing!
I personally never liked VSCode's UI. That's 100% subjective, I'm not claiming Atom's UI is better, I just like it a lot and it was kind of a “love at first sight moment”, and VSCode just didn't gave me that feeling.
Also, I'm using a ton of Atom plugin that didn't exist on VSCode at the time I tried (this may have changed, but since I disliked the UI, I'm not going to try VSCode again).
Also, I'm using a ton of Atom plugin that didn't exist on VSCode at the time I tried (this may have changed, but since I disliked the UI, I'm not going to try VSCode again).
Atom's Vim-Mode-Plus is amazing. VSC's vim plugin still has a way to go. (It's buggy, sometimes things just don't work)
VSC is just not as extensible. If I want to change that bottom bar color, I have to set it in a config file, there's no hook to change it on the fly. If I want to navigate around the interface only via keyboard, it's not a pleasure. If I want to simply open a file in the file explorer on MacOS, I can't just hit <enter>... and I don't think anyone's figured out a way around that yet.
> Atom's Vim-Mode-Plus is amazing
Its even better than vim itself... multi-cursors Vim Mode in Atom is insanely good.
i know you can basically do the same thing with native vim, but having instant feedback like in atom makes it just so easy
Its even better than vim itself... multi-cursors Vim Mode in Atom is insanely good.
i know you can basically do the same thing with native vim, but having instant feedback like in atom makes it just so easy
Still stick with Atom as my main text/code editor here. I started out with it mainly to write LaTeX, but since do most of my code editing also in Atom. I looked at VSCode back in '17 but found it quite clunky and not as intuitive as Atom. Things like changing key-binding based on a profile for example needs a quick Google - or maybe I am just slow!
I keep going back now and then to VS Code especially when I need to use the debugger to step through some code. But otherwise, my workflow since has evolved around the little niggles of Atom(like having to open separate terminal windows) so I don't feel the need to switch.
I keep going back now and then to VS Code especially when I need to use the debugger to step through some code. But otherwise, my workflow since has evolved around the little niggles of Atom(like having to open separate terminal windows) so I don't feel the need to switch.
I, for one, couldn't get used to VS Code look and feel for some reason. I mostly do Sublime Text, but I combined it with Atom a lot in the past. So yeah, not about features or anything.
I switched from Atom to VSCode (rather enthusiastically). My biggest loss is the find/replace interface from atom -- it was _such_ a nice interface -- so fast to browse over all the matching contexts and replace piece by piece or all at once.
Atom's find/replace interface was the favorite version of the feature I've used in any editor -- would be cool to see how that design evolved to support other kinds of automated edits (like refactorings).
Atom's find/replace interface was the favorite version of the feature I've used in any editor -- would be cool to see how that design evolved to support other kinds of automated edits (like refactorings).
I stayed with Atom for a long while because my main use case at work is editing single text files on remote servers... There's not a great plugin for this in VSCode. Atom makes it easy to quickly open, edit, save, and close over FTP/SFTP.
Tree Sitter. Being able to do Alt+Up/Down and have syntax blocks selected with such a confidence has really changed the way I write code.
This! Tree Sitter is the only thing I miss in VSCode
I still use atom over VSCode because of the UI and the extensions.
The extensions in atom seem to have quite a few more permissions to change the ui than they do in vscode.
At least for clojure development.
The extensions in atom seem to have quite a few more permissions to change the ui than they do in vscode.
At least for clojure development.
I don't use Atom, but one feature it has that I wish VSCode has is "atomic tabstops". It means if you are forced to work against your will on code that inexplicably uses spaces for indentation, it will act as if they really used tabs.
Atom is the only editor I've seen that has it unfortunately.
Atom is the only editor I've seen that has it unfortunately.
I was with Atom for years, switched to VS Code and feel in love (save for the find and replace as cited above, I still felt/feel Atom's is better than VS Code's) and stuck with it (VS Code) for months.
The thing that made me switch back was that there was some combination of plugins I was using in VS Code (I think it was the VIM plugin and something else maybe) started freezing periodically and the whole editor would become unresponsive and I'd have to restart. After that became normal I decided to switch back.
In the end I preferred to spend my time coding rather than hunt down the problem.
Also Atom's VIM plugin is strictly better for my use case. The highlighting effect to show you what you just `yw` for example is great!
The thing that made me switch back was that there was some combination of plugins I was using in VS Code (I think it was the VIM plugin and something else maybe) started freezing periodically and the whole editor would become unresponsive and I'd have to restart. After that became normal I decided to switch back.
In the end I preferred to spend my time coding rather than hunt down the problem.
Also Atom's VIM plugin is strictly better for my use case. The highlighting effect to show you what you just `yw` for example is great!
Funny, I had a similar (but somewhat opposite) experience: was a happy Atom user for some years until it started slowing down, freezing at increasing frequency; it was due to my having a massive tree of folders and files (top-level folder with all projects), with lots of symbolic and hard links. I had checked out VS Code a few times, but finally a couple months ago I was forced to make a switch - then pleasantly surprised how easy it was to migrate to it.
VS Code is not as hackable of an editor, but it comes with great sensible defaults out of the box. I gave up trying to fully customize it, settled with a few tweaks, and have been very satisfied with it as a daily driver. At least for my use case, it's been more reliable and performant than Atom.
The type hinting and "IntelliSense" is one of my favorite features (I'm sure Atom has a plugin for it). I think VS Code hits the sweet spot between an editor and a full-on IDE.
EDIT: Oh, I didn't see this in the article, but it seems Atom is addressing the exact issue I was having:
> The fuzzy finder’s project crawling performance has been improved dramatically by switching to a ripgrep-powered backend. This is most noticeable in projects with large numbers of files - for example, we measured a 14x speed boost in a project with 270K files.
VS Code is not as hackable of an editor, but it comes with great sensible defaults out of the box. I gave up trying to fully customize it, settled with a few tweaks, and have been very satisfied with it as a daily driver. At least for my use case, it's been more reliable and performant than Atom.
The type hinting and "IntelliSense" is one of my favorite features (I'm sure Atom has a plugin for it). I think VS Code hits the sweet spot between an editor and a full-on IDE.
EDIT: Oh, I didn't see this in the article, but it seems Atom is addressing the exact issue I was having:
> The fuzzy finder’s project crawling performance has been improved dramatically by switching to a ripgrep-powered backend. This is most noticeable in projects with large numbers of files - for example, we measured a 14x speed boost in a project with 270K files.
Atom has always 'Just Worked' for me. For my projects (which are mostly Ember and Laravel) VSCode always had some issue, something to do with import maps. It also feels more sluggish to me than Atom.
There's been previous discussion over this:
https://news.ycombinator.com/item?id=18507817
Take what you will from it. I'm not sure they will kill it, but I don't know why they need to maintain two editors either, then again they already maintain Visual Studio as well. I think it would be nice to see how both teams push their editors, but I feel like over the long haul it will be some VIM vs Neovim type of this. Additionally, VS Code will focus on strongly supporting Microsofts tech (via plugins), while Atom will focus on GitHub to some extent.
https://news.ycombinator.com/item?id=18507817
Take what you will from it. I'm not sure they will kill it, but I don't know why they need to maintain two editors either, then again they already maintain Visual Studio as well. I think it would be nice to see how both teams push their editors, but I feel like over the long haul it will be some VIM vs Neovim type of this. Additionally, VS Code will focus on strongly supporting Microsofts tech (via plugins), while Atom will focus on GitHub to some extent.
My guess is that if anything, they'd turn Atom over to an external body to maintain and let it sink/swim on its own. Currently they seem to be fine with having both, which is cool. Maybe it is to have two separate teams work on different ideas and see which ones work and mainline it into Visual Studio Code? Not sure.
I wish Visual Studio Code replaced Visual Studio, but unfortunately, it still holds value if working against Microsoft's stack. I like having them both and will occasionally use Code for .NET edits, but you definitely feel like it is missing some comforts at the very least when using it.
I wish Visual Studio Code replaced Visual Studio, but unfortunately, it still holds value if working against Microsoft's stack. I like having them both and will occasionally use Code for .NET edits, but you definitely feel like it is missing some comforts at the very least when using it.
Until vscode and omnisharp support design time builds of msbuild projects, visual studio proper isn't going anywhere. Vscode cannot support anything beyond the happy path of csproj files which means I will always have to dip back into visual studio
> VS Code is one of the finest examples of open source Done Right™
It's easy to do OSS right when your a major cloud OSS vendor who are able to use your billions of profits from hosting OSS to fund a 30+ strong dev team in creating a free "OSS" product.
If that's the definition of doing OSS right, then the only sustainable "free" products that will be done right will come from multi-billion dollar cloud vendors. I do love VS Code tho, just not a fan of seeing most of the generated wealth from OSS being collected by the major cloud vendors, this trend is going to hurt the diversity of the OSS ecosystem as we know it.
Irrespective of the funding model that made it possible, I will say the VS Code team is doing a fantastic work iteratively shipping new features with each release at a super high velocity.
IMO it's a poster child for why most future Desktop Apps will be built using a Hybrid or WebView dev model like Electron where its productivity is unmatched.
It's easy to do OSS right when your a major cloud OSS vendor who are able to use your billions of profits from hosting OSS to fund a 30+ strong dev team in creating a free "OSS" product.
If that's the definition of doing OSS right, then the only sustainable "free" products that will be done right will come from multi-billion dollar cloud vendors. I do love VS Code tho, just not a fan of seeing most of the generated wealth from OSS being collected by the major cloud vendors, this trend is going to hurt the diversity of the OSS ecosystem as we know it.
Irrespective of the funding model that made it possible, I will say the VS Code team is doing a fantastic work iteratively shipping new features with each release at a super high velocity.
IMO it's a poster child for why most future Desktop Apps will be built using a Hybrid or WebView dev model like Electron where its productivity is unmatched.
And then we'll all go back to Vim and the cycle of life will once again complete itself.
15-20 commits per week says they just support it and don't implement any major features. Hope I'm not right here.
Looking only at the commit numbers of the `atom/atom` repo is a bit misleading as the Atom source code as the core plugin packages (e.g., the language modes, but also fundamental features like the tree and the fuzzer) are each in their own repo. For instance, the fuzzy-finder repo alone had 15+ commits in the last three weeks.
Strongly disagree. VS Code is a corporate tool IDE, which is dull and awkward to use as just an editor, and binary spyware in it "phones home" to its users' masters in Redmond. It's exactly what an MSDN subscriber would like, but dire for anyone else.
Atom is fun. It's easy to configure in weird personal ways, get rid of parts you don't use, add your own plugins, change CSS as you like. There's an insane number of plugins and themes. It's like emacs but organized and nice.
So far the statements from project owners in public and on Slack have been that Atom 1 & 2 development continues full speed.
If it is "killed" we'll just fork it and run up a black flag.
Atom is fun. It's easy to configure in weird personal ways, get rid of parts you don't use, add your own plugins, change CSS as you like. There's an insane number of plugins and themes. It's like emacs but organized and nice.
So far the statements from project owners in public and on Slack have been that Atom 1 & 2 development continues full speed.
If it is "killed" we'll just fork it and run up a black flag.
I think you missed the /s in your comment.
[deleted]
No need to insult whoever dislike your preferences.
> and binary spyware in it "phones home" to its users' masters in Redmond
Not a problem, https://vscodium.com/
Not a problem, https://vscodium.com/
[deleted]
I do a lot of code review, so I'm excited to be able to do that from my editor where all of my other tooling is set up instead of in a web browser. Suggested code changes will be much easier if I write them in a context where I can compile/run them. And no more clicking that "expand" thing 20 times to see something earlier in the file.
Thanks, Atom team!
Thanks, Atom team!
To anyone who is following Atom closely,
1. What happened to Xray? The Next Generation of Atom that was suppose to fix all the performance problem of Atom.
2. Is Atom as fast as VS Code now?
1. What happened to Xray? The Next Generation of Atom that was suppose to fix all the performance problem of Atom.
2. Is Atom as fast as VS Code now?
1. I haven't heard anything about it recently but that doesn't mean work isn't continuing on it. Xray wasn't supposed to "fix" anything really, it was a fairly extreme experiment to see if it would be worth going down that path.
2. No, and it's not trying to be, as "speed" isn't their top priority, extensibility is.
That being said, the days of opening a 5mb file and the editor getting brought to its knees are largely over (unless you have poorly written extensions which can still take everything down, because again in Atom extensions are EVERYTHING and can do ANYTHING).
2. No, and it's not trying to be, as "speed" isn't their top priority, extensibility is.
That being said, the days of opening a 5mb file and the editor getting brought to its knees are largely over (unless you have poorly written extensions which can still take everything down, because again in Atom extensions are EVERYTHING and can do ANYTHING).
Strange they are not focusing on Speed.
The primary reason VS Code took over Atom was because of Speed. It shows what is possible with Electron. Not that it is anywhere near the speed of Sublime Text, but it was good enough for most and at least bearable to me. Compared to Atom, all the feedback ( on most Internet forum at least ) are performance related.
The primary reason VS Code took over Atom was because of Speed. It shows what is possible with Electron. Not that it is anywhere near the speed of Sublime Text, but it was good enough for most and at least bearable to me. Compared to Atom, all the feedback ( on most Internet forum at least ) are performance related.
I tried 1.36.0 and found it pleasantly faster than I remembered, especially the highlighting on large files. I would. Startup-time is still painfully slow, but it feels like once it is "up and going" it's just as fast.
It's just a difference in strategy. If Atom started restricting what plugins can do in a way that VSCode does, i'd drop it in a heartbeat, since that is the biggest reason why I use it.
The ability to literally customize everything, the ability to replace the built-in plugin that enables tabs with a different one with different features, or the ability to create and use plugins like git-time-machine, or the ability to have full offline documentation with popular libraries baked into the editor, or the ability to write a plugin that turns the editor into an SQL ide allowing me to highlight and ctrl+enter a statement and have it run in a local DB while developing to test some stuff and show the results in a new pane in the UI, or a browser plugin (and editor plugin) that allows me to type this comment in my Atom instance and have it mirror to the web textbox so I have all my normal shortcuts and keybindings, or even just tweak a plugin yourself locally in a few minutes.
For example I run a somewhat unique setup for a current project where I'm running an IDE tool in WSL (the linux subsystem) in windows. The IDE tool runs in the linux layer, but my editor (atom) runs in the windows layer. The editor kicks off the tool and tells it which files to run on, but the paths are different on the 2 sides. So I quick pulled down the plugin, modified it to convert the paths back and forth correctly, and linked it locally and i'm up and running in literally half an hour. that kind of thing isn't nearly as easy in other editors like Sublime or even VSCode in many cases where those tools are either built-in to the editor, or need to use a specified interface which would make this kind of thing much harder to accomplish.
The fact that it takes 5 seconds to startup doesn't bother me at all, and in usage it's more than fast enough for just about everything I can throw at it (again, excluding poorly written plugins that can ruin things sometimes). At most I open my editor a dozen times a day (normally once or twice), but switching to VSCode where plugins are more limited in what they can do (for performance reasons mostly) would cost me significantly more time each day in just switching windows to do things that I used to be able to integrate into my editor.
And at the end of the day, it doesn't need to be perfect for everyone. I get that most people don't want to spend the amount of time that I did and still do customizing and building my editor from plugins, and for them VSCode is great! And still others like yourself value startup time significantly (whether you just enjoy it more or you have a workflow which requires it doesn't matter), and in those cases something like Sublime or even others might be better! It's not a zero sum game, we can all coexist happily!
The ability to literally customize everything, the ability to replace the built-in plugin that enables tabs with a different one with different features, or the ability to create and use plugins like git-time-machine, or the ability to have full offline documentation with popular libraries baked into the editor, or the ability to write a plugin that turns the editor into an SQL ide allowing me to highlight and ctrl+enter a statement and have it run in a local DB while developing to test some stuff and show the results in a new pane in the UI, or a browser plugin (and editor plugin) that allows me to type this comment in my Atom instance and have it mirror to the web textbox so I have all my normal shortcuts and keybindings, or even just tweak a plugin yourself locally in a few minutes.
For example I run a somewhat unique setup for a current project where I'm running an IDE tool in WSL (the linux subsystem) in windows. The IDE tool runs in the linux layer, but my editor (atom) runs in the windows layer. The editor kicks off the tool and tells it which files to run on, but the paths are different on the 2 sides. So I quick pulled down the plugin, modified it to convert the paths back and forth correctly, and linked it locally and i'm up and running in literally half an hour. that kind of thing isn't nearly as easy in other editors like Sublime or even VSCode in many cases where those tools are either built-in to the editor, or need to use a specified interface which would make this kind of thing much harder to accomplish.
The fact that it takes 5 seconds to startup doesn't bother me at all, and in usage it's more than fast enough for just about everything I can throw at it (again, excluding poorly written plugins that can ruin things sometimes). At most I open my editor a dozen times a day (normally once or twice), but switching to VSCode where plugins are more limited in what they can do (for performance reasons mostly) would cost me significantly more time each day in just switching windows to do things that I used to be able to integrate into my editor.
And at the end of the day, it doesn't need to be perfect for everyone. I get that most people don't want to spend the amount of time that I did and still do customizing and building my editor from plugins, and for them VSCode is great! And still others like yourself value startup time significantly (whether you just enjoy it more or you have a workflow which requires it doesn't matter), and in those cases something like Sublime or even others might be better! It's not a zero sum game, we can all coexist happily!
> in Atom extensions are EVERYTHING and can do ANYTHING).
So Atom is the emacs of Webstack-World?
So Atom is the emacs of Webstack-World?
Pretty much! It's quite freeing if you enjoy working in an editor like that, and it's incredibly powerful!
But obviously if you value "time to open" and if you don't want to customize things, neither of them is going to be a good choice for you!
But obviously if you value "time to open" and if you don't want to customize things, neither of them is going to be a good choice for you!
1. https://github.com/atom/xray/graphs/contributors
Seems it's been not much done since february.
>The fuzzy finder’s project crawling performance has been improved dramatically by switching to a ripgrep-powered backend. This is most noticeable in projects with large numbers of files - for example, we measured a 14x speed boost in a project with 270K files.
Another leaf out of VS Code's book?
Another leaf out of VS Code's book?
I don’t understand why Microsoft hasn’t pulled the GitHub integration into VS Code. It seems like it would be in their best interest given that they own both now.
I get that it's got a bit more going on, but Atom's startup time is still so much slower than Sublime Text.
I open a file, there's still this "clunky" lag of 2-3 seconds to open. I hope they work on optimizing this at some point.
I open a file, there's still this "clunky" lag of 2-3 seconds to open. I hope they work on optimizing this at some point.
Atom lost the HTML Editor race.
Atom is still being developed?
While Atom was Mac-only, VSCode was eating their lunch.
It's too little, too late now.
It's too little, too late now.
> While Atom was Mac-only, VSCode was eating their lunch. It's too little, too late now.
What do you mean? Atom has always been available for macOS, Windows, and Linux.
What do you mean? Atom has always been available for macOS, Windows, and Linux.
...ever tried actually using it on Windows? Like a year ago it got to ok-ish usable. A bit before that even on most Linuxes it had crappy performance.
Again, I like Atom's hackability, and mainly avoid it because the ecosystem of plugins is so full of halfly owkring abandonware
Again, I like Atom's hackability, and mainly avoid it because the ecosystem of plugins is so full of halfly owkring abandonware
First I've heard of this. I used Atom for a few years on windows and ubuntu without any issues except opening very large files.
GitHub and Atom have a very linked future, with GitHub planning to become more involved with the actual code-writing process. Atom will be the conduit though which they achieve that.