For once, on an atom release thread, can we have a discussion about atom and this release rather than endless threads about folks preferring vscode or sublime?
Absoltely agree. Love the UI, add-ons(love the terminal add on). I agree go-to decalaration needs to be fixed. There are a couple of packages that try to do it, but none of them do a good job. Atom needs to fix this on priority, it's a basic feature that must work out of the box. I have got this working by manually generating ctags(installed with brew) and then using the same go to declaration option. Works like a charm like it should have :)
which terminal addon do you use? As I am extremely interested to use terminal within Atom.The other day, I was using terminal-plus and it seems to have some issues.
So I don't clog up the rest of the comment thread I'll add my atom/vscode/sublime thoughts here.
I've been a long time sublime user and found it very very difficult to switch to anything else, mainly for performance reasons. But I decided to give atom and vscode a real try for a couple of weeks each. These are my findings and results.
I started with VScode when dotnet-core was officially released for OSX. The debugging features, performance, and usability were awesome. I was going to stop right here and jump to vscode except for these reasons.
- Tabs. I know they're coming, but every time I had to go looking for the correct file I was ripped out of my train of thought.
- Shortcuts. They're completely different to sublime/atom and I didn't feel like learning a bunch of F-key shortcuts.
So I decided to give atom another go. Right off the bat I had a very nice looking editor. I appreciate the settings UI that isn't just a text file. The project view on the left is way better than sublime's. A major pain point of mine with sublime was opening a file with CMD + T, but then being unable to find it in the project view on the left. Atom has a reveal in project feature that expands the tree and focuses the file. The git status indicators on each file are nice too. The shortcuts are similar enough to sublime that there's no learning curve.
Atom has a lot of really nice quality of life improvements over sublime text. Startup is really slow. Incremental search is really slow. When I'm viewing large text files I still load them up in sublime text. But for the majority of my coding now, I'll be using atom.
I do quite a bit of C# development in a windows VM, so I might fire up vscode for that use case if dotnet core becomes an option for the app I'm working on.
Sublime also has the reveal in sidebar functionality. At least my setup has, not sure if it came with the enhanced sidebar plugin, but you need that one anyway to be able to work properly.
Indeed I liked the good looking atom without configuration. Lately I switched back and use sublime with the material theme which is great, but atom is much easier to style, or doesn't event need it.
In the end it was startup performance that killed atom for me. I use it to view all sorts of single files as well and each time it took ages to open a file which I wanted to look at for 20 seconds.
I use sublime to quickly look at files for exactly this reason. But I find for actually editing files in a project that atom is doing the job a bit better.
> For once, on an atom release thread, can we have a discussion about atom and this release rather than endless threads about folks preferring vscode or sublime?
Not on HackerNews in this reality, a while back someone did analysis of most voted comments, the top-comment is usually contrary to the post and its first reply is counter-contrary (pro-OP). Post about Golang -> get pro-Haskell comments, Android <-> iOS, iPad <-> Surface, Linux <-> *BSD. Its what we are.
> For once, on an atom release thread, can we have a discussion about atom and this release rather than endless threads about folks preferring vscode or sublime?
Sure, let's focus on Atom's speed issues.
"Oh, I don't have a problem with my laptop's CPU fan spinning like a lawnmower. Surely deep architectural nonsense will be solved in the next minor update."
Wholeheartedly agree. I just tested this new version out.
I really keep trying to use Atom, but it's just unacceptable currently when compared to Sublime. Very slow startups and laggy. This new version takes 5-10 seconds before I can start coding, that's far too slow. With every update I keep hoping things are faster, but only marginally so. VS code loads in less than 3 seconds and is a lot more snappy.
I don't understand why they don't address this issue as the highest priority problem. It's by far the most complained about issue. If the MS guys can make VS code launch that fast I don't see anything holding back Atom (save maybe coffeescript :P (tongue in cheek)).
I suppose there are limits to Electron launch time ?
VS Code and Atom both launch a 'full' browser and server, html, css, js and the whole shebang to make all of that work; while Sublime is compiled C++ (with a python API).
When my laptop is booting I'm usually fetching coffee. Most of the time I just crack the lid, it wakes up, and all my editors are still running anyway. I probably boot an app like Atom once or twice a week. Plenty of tools I use (PHPStorm, vagrant boxes, VMware) all take way longer than 5 seconds to load and that has no noticeable impact on my productivity or happiness.
It seems silly to me for someone to adopt a strategy of opening/closing Atom (instead of reusing an open instance) and then complain about how long it takes to boot. You don't park your car at red lights and turn off the engine, then complain about how long it takes to pull away when the lights turn green.
> Plus, the slugginess extends beyond startup time, into working with large files (were large = puny for other editors' standard) and other activities.
This I totally get. If this is someone's use case, they probably shouldn't be using Atom.
I don't mean to rail on you in particular, I just always found the "oh it takes so long to start" complaint to be a silly one. It's such a minor thing. Atom is really good for a bunch of use cases, it's a shame that people write it off for this stupid reason.
I fetch coffee when I want coffee. I don't plan my schedule around waiting for things that have no reason not to be completely instantaneous. I avoid any tool that takes longer than 100ms or so to start up. Anything slower than that is completely unacceptable at this point in the history of computing.
> It seems silly to me for someone to adopt a strategy of opening/closing Atom (instead of reusing an open instance) and then complain about how long it takes to boot.
That's not what happens. They looked at the tool, stated it doesn't meet their needs, explained why, and then _did not adopt the tool_. The Atom folks can decide they don't want those users or they can address their abominable startup time, but you can't suggest "change how you do everything" and hope to win friends or users.
> You don't park your car at red lights and turn off the engine, then complain about how long it takes to pull away when the lights turn green.
You didn't, until car startup time was optimized enough that modern cars do turn off the engine at red lights to save resources, then turn it back on when you put your foot down.
Because it should open instantly. The fact that it take 5 seconds implies a level of bloat that is unacceptable in well designed software.
Also 5 seconds is enough for my attention to maybe wander. Not every time but often enough to waste minutes of productivity per day. It all adds up. Amazon found that each extra millisecond delay causes customers to navigate away from the page. It isn't laziness just human nature.
Yeah I never resonated with this complaint. I guess if you are constantly opening different directories/files I could see it being annoying, but I end up opening it once in the morning when I get into the office and it is up all day.
Because I don't want multiple editors in my workflow, one for opening projects, another for opening single .txt or .log files (by right click, open with), I don't want to wait 5-10 secs before opening these single files and I don't want Atom opened all the time either, its a RAM guzzler. Sublime fits the bill perfectly, blazing fast and lot of plugins.
Yeah I've been on Sublime for months without looking back.
No reason why a few hundred line markdown file with Atom should bog down an i5 quad core with 16gb of ram to point where typing 1 key takes forever while Sublime operates on it instantly.
I tried to adjust to atom, but the lack of full on kill/yank support with the standard emacs keybindings (ctrl-k/ctrl-y; i should note that these keybindings are also standard almost everywhere in OS X) drove me bonkers.
The fact that the kill command overwrote the standard clipboard just crippled my workflow (i routinely, intentionally keep different things in the kill-ring and the standard clipboard; i just couldn't unlearn that muscle memory).
It should not take an i7 processor to run a text editor. I mean no disrespect, but either something is very wrong with your computer, or something is very wrong with this software.
It's the original Electron[1] app. It's just a JavaScript web application running in a re-branded Chrome window, which is why it uses an absurd amount of computing power compared to a normal text editor (or most other native applications).
I said this elsewhere but vscode's strategy won me over atom's. Vscode was faster and more stable with much less features which they gradually added over time. Atom had all the features, more lag, and has been trying to polish them since.
Texteditors must be fast and predictable. Tab support for vscode was it for me. Also, their ide must add overhead and yet still much faster than atom
Atom may not be as fast as some native editors but I've found it to more than fast enough for 99% of the code editing I do and the plugin ecosystem and overall user experience is better than any other editor I've tried. I use it mostly for Rails & React coding and have been very happy for the productivity boost. I launch it once or twice a day so waiting 5-10 seconds is a small price to pay.
> Atom may not be as fast as some native editors but I've found it to more than fast enough for 99% of the code editing I do and the plugin ecosystem and overall user experience is better than any other editor I've tried.
How big are the projects you are working on? When I was messing around with atom yesterday on a single small file it was great. But when I opened a project I'm working on, about 15,000 lines of C across 50 or so files, atom becomes unusably slow. 15,000 lines is pretty small compared to lot's of other projects and atom couldn't handle that. It's too bad because I like atom, I thought the plugin system was much easier than Sublime's and I liked the overall look and feel better than Sublime.
I've been working on projects around 5k-10kloc without any issues. None of the individual files are more than a few hundred lines though. Atom doesn't handle really long files well but I consider those a sign of a need to refactor anyway.
I didn't realize Atom struggled with long files. But the longest file in my project is about 1200 lines, the rest are a couple hundred lines or so. Your right about the refactoring but there's lot's of other stuff to work on as well so that probably won't be done anytime soon.
Also my computer is due for an upgrade which adds to the unusability, it's a 2010 MBP with a 1TB 840 evo and 16GB ram. The CPU is definitely lacking though, it's a 2.4 GHz Intel Core 2 Duo.
It is, but it is still ~40ms input latency compared to <1ms latency for good editors written in C++ or, serious efforts in Java (see Intellij Zero Latency Mode )
Completely agree, I tried Atom and VSCode but they are nowhere near (in performance) to Sublime. The only thing is it's not open source, but I can live with that.
This! I don't even know how can they name something a text editor in which you CANNOT TYPE letters you know, the most important feature of a text editor to allow typing and Atom can't do that.
This, and the inability to open large text files. You would think a priority for a text editor would be to be able to actually open text files and write correctly on them.
While open-source is nice, if an editor doesn't support my keyboard I would just pick a different editor instead of patching core functionality in. It's not like there's a shortage of editors that let you use non-US keyboards.
"Can" implies both ability (e.g. Javascript programming) and time to delve into the internals to find the issue, go through the procedure of submitting a patch etc, which is not a given the parent has, whether Atom is "collaborative" or not.
> 0.37.8 is actually a 1.0.1 version of Atom so it's not THAT old. The only difference between 0.37.8 and 1.0.0 release is the remove of deprecated API that were not flagged as such in 0.37.8 release. Reason why Atom only incrementally updates electron is to minimize application breakage due to Atom project's size. [0]
> We decide to update to a new version of Electron when there is an enhancement or bug fix that version would enable that would benefit Atom users. Because updating to a new version of Electron is non-trivial, sometimes we skip versions until there is a clear benefit that justifies the cost. [1]
Drag and drop layout management is really a nice addition, you can have the same result on any text editor but doing a drag and drop feels natural.
Atom is still taking too much time to start compared to Sublime but I now use it for everything except large files, the overall UX is better and new features are added regularly.
I moved to atom from sublime and really love it. However, it's s l o w . . . Not only the start up time, but on non trival projects it lags attempting to code color the file and periodically lags up to 5 seconds on save. Nevertheless, even with the warts it's pretty neat.
I don't want to criticise it too much as it is completely free, so I will simply say that it would be hard to convince me to try it for a third time.
Microsoft VSCode is my editor, and it took me a long time to adopt it. They lacked a lot of features, but in the end delivering a few features that worked extremely well and adding the important ones as they could (thanks for tab support) won me over. Shipping a broken kitchen sink just turned me off. It had critical flaws that made either me, or the editor and my sometimes unsaved code, rage quit. I have used it cumulatively about 6 months over thd last 2 years.
Tl;dr at least as far as text editors go, 99% correct with a narrow feature set beats 75% stable witha wide one.
They still don't have a way to build a release without a network connection. Which basically means any secure (builds in sandbox) source-based distro can't package it.
I love atom, I use it daily and it is my editor of choice for web stuff.
But think of how many software abstractions/levels each line of atom code has to go through. I mean, each keypress probably produces in the order of 100 million CPU instructions in the metal (number pulled out of my behind but you get the idea) just to display a single character. Is this what progress looks like?
I guess there's a balance between developer comfort and software efficiency.
I've been developing ReactNative since past few months and hence, I've been using Atom as my default IDE with Nuclide. I agree that Atom is slower than Sublime but once you tweak some settings and get a sanity hold on your plugins then you will get a significant improvement in performance.
I'm looking forward to Guile Emacs, if it ever gets merged into mainline, because emacs will then have a JIT (and maybe we can then land things like real threads)
"The following is a summary of improvements we have been testing on our beta channel and that are finally landing in Atom 1.9.0. :rocket:
- Display Layers, which are going to bring speed improvements as well as new features like free-form folds (via the Fold Selection command) and an improved soft-wrapping algorithm.
- Electron Upgrade (v0.37.8), which features many performance improvements and enables efficient ligatures rendering on all the platforms.
- Drag and Drop Layout Management, that provides a very intuitive way for organizing the workspace.
- Enhanced Reliability When Saving Files, which minimizes the risk of losing files when a hard crash occurs.
- Shell Commands Compatibility On Windows, that makes the atom command compatible with both Cygwin and Msys."
