Atom 1.9 and 1.10 beta | Hacker News Reader

Atom 1.9 and 1.10 beta

blog.atom.io

139 pointsseanwilson92 comments

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?

Seems like no one is giving love! I enjoy Atom and I use it daily (I do website at some webagency).

It is fast, even with Photoshop, Indesign, and multiple Chrome tabs opened.

Pros: its handy and has so many addons. Not crippled with useless toolbars like Eclips-y editors.

Cons: Sadly, it's still missing a "go-to-method-declaration" feature (did I miss something? ), and is awfuly buggy when editing over FTP.

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.

Terminal plus is pretty sweet, works well for me!

GoToMethod is not perfect. However there are various auto completion plugins that are language specific and sometimes do a better job.

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.

Tabs are already there, since version 1.3

> 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.

Maybe Hacker News readers appreciate hearing different perspectives on issues? This leads them to up-vote quality counter points to articles.

Not today. It's a real joy slogging through these gratuitously negative comments. Feels just like any thread about Google on HN.

> 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."

Emacs, heathen

I have participated a bit in the Atom.io open source repository, but now I am back to Sublime. It's so fast and reliable compared to Atom.io.

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)).

5-10 seconds seems slow. Atom for me launches in 3ish seconds. VSCode marginally faster than Atom to launch. Sublime around .5 of a second.

None of those are deal breakers for me.

> This new version takes 5-10 seconds before I can start coding, that's far too slow.

Last time I had to launch Atom was when 1.8 was released. In the use case where you leave the editor running this startup time isn't a problem.

I would love to see how many petabytes of RAM your installation is using.

I've never even seen Atom get into the top 20. Two windows, 5 panes, about 50 open files of Erlang and C#.

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).

Why is waiting 5-10 seconds for your editor to open such a problem?

For the same reason waiting 1-2 minutes for your laptop to boot is.

Also because people often open/close tons of small files during the day instead of opening a project and working on it for hours.

Plus, the slugginess extends beyond startup time, into working with large files (were large = puny for other editors' standard) and other activities.

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.

The analogy to boot times reminds me of this story: http://www.folklore.org/StoryView.py?story=Saving_Lives.txt

It is a shame people don't value users time like this any more.

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.

Time is the stuff life is made of.

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).

Yeah my PC is not fast enough to run atom without lag, but it runs sublime perfectly. Maybe when I get the latest i7 I will try out Atom again.

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).

[1] http://electron.atom.io/

Do they at least render natively, or do they rely on Blink + (I'm assuming) some crazy JS text rendering & syntax coloring to get it usable?

The latter.

In this case, you can blame the software without any doubt

For years and years it took a very powerful computer to get decent performance out of Emacs.

Emacs only seems speedy now because computers have finally caught up.

Either Atom will get faster, or it will add so much value it's okay being slow.

And then computers will eventually catch up, just like they did with Emacs.

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

Is Atom the perfect example of "it's 2016 and my computer has multiple cores but stuff is still slow!"?

Well, JavaScript is single threaded...

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.

What about VSCode? It feels less laggy than Atom, at least for me.

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 )

Yes it is, but automatic indentation is awful. I switched back to Atom just because of that.

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.

I've been very happy with Brackets. It seems to perform a bit better than Atom.

Also, its instant search across all files is quite amazing actually. Faster and more useful than any other editor I have tried

Each time there's an Atom release announcement, I check if they've finally fixed AltGr.

They didn't. Most non-US keyboard layouts are still broken.

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.

If V8 can't handle it, there is no way Atom will handle it. Some would assess this as major software design issue (yeah I mean me).

VS Code (which is also built on top of Electron) can handle large files just fine.

Why can't V8 handle it? Too many pointers on the heap?

V8 has some limits on memory allocation. I don't know why. I guess the engine allocators are not optimized to handle very large allocations.

AltGr works fine for me on Linux, and has since the first time I tried Atom ages ago.

They? Atom is a collaborative effort, you can fix that yourself.

> you can fix that yourself

I can't and neither can you.

You can't go back in time and tell them that they shouldn't use Alt+Ctrl for any of the built-in shortcuts.

You also can't get rid of those shortcuts.

You also can't finalize that UI Events spec and just land those features in Chromium.

They could have gotten rid of those shortcuts, but they decided against it.

Anyhow, Chrome 51+ (current stable is 52) does support the required part of the spec now.

https://jsfiddle.net/1zhcpj8a/

I do get:

  Alt AltLeft
  AltGraph AltRight

Which means you can now easily and accurately tell if AltGr was pressed. This release of Atom could have fixed it.

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.

> Electron upgraded to v0.37.8

The official website of electron [1] says that the current version is 1.3.1

Can someone explain why atom uses a 3 months old version ? [2]

[1] http://electron.atom.io

[2] https://github.com/electron/electron/releases/tag/v0.37.8

Found some info on this:

> 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]

[0] https://github.com/atom/atom/issues/11967#issuecomment-22550...

[1] https://github.com/atom/design-decisions/blob/master/electro...

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 switch to vscode, better support for debuggers, fast compared to atom, and extensions available are great

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.

What plugins have you got installed? And what OS?

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.

Well now it loads pretty fast for me! I use Atom for Elixir and Elm as their plugins are better than those for Sublime.

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.

Does it still use A Terabyte Of Memory ?

Yes. I bought a new workstation to run Atom.

Why, doesn't everyone in their startup's SF office have a terabyte of memory? Why would someone have a computer less than $5000?

Unless they start using native code it will always be like that.

VSCode from Microsoft is also wrapped in electron and uses a fraction of what Atom is consuming. Not being native has nothing to do here.

The memory consumption is a magnitude larger in JavaScript than native.

http://benchmarksgame.alioth.debian.org/u64/compare.php?lang...

So what?

There are javascript editors that don't use as much memory as atom. What you're saying is irrelevant.

So if this is hard to understand, the conclusion, in simple words:

the memory consumption for a javascript editor will be a magnitude bigger than native.

In my example 66Mb Sublime vs 620MB VS Code (no plugins)

halokonrad isn't talking about sublime. He's talking about Atom vs VS Code.

I went back to (non-native) emacs, partially due to this problem.

Emacs has tons of C code. And the display (and core text manipulation stuff IIRC) is not written in elisp.

In contrast, Atom just uses native code as the JIT, and then not only does (almost) everything in JS but also renders it with slow DOM.

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)

Blog post about the release: http://blog.atom.io/2016/08/01/atom-1-9-and-1-10-beta.html

"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."

You see, people would have traded happily all those improvements for only this one:

"It is super fast!"

Thanks, we've updated the submission from https://github.com/atom/atom/releases/tag/v1.9.0.

Atom would be way cooler if it was a projection editor like projectured.org. Or was available online.

Reply on news.ycombinator.com