
Atom 1.25 - kylebarron
https://blog.atom.io/2018/03/15/atom-1-25.html
======
jakear
Tree-sitter (intelligent code folding) looks really cool. While I am a big fan
of VSCode, I really do not like their indentation-only approach to folding. It
makes constructs like C switch statements impossible to fold correctly.
Something like:

    
    
      switch( ) {
      case:
         break;
      case: 
         break;
      }
    

won't fold at the braces, but instead will just collapse one case statement,
and it drives me crazy. This is even with the C/C++ language extensions
installed.

Good job Atom.

~~~
lewisl9029
Tree-sitter is not just for code folding, it's a full-on incremental parser
that's fast enough to run on every keystroke. See their expand selection
example for another really compelling use-case.

If you're interested in more details, there's also this talk from the
developer behind tree-sitter
([https://www.youtube.com/watch?v=a1rC79DHpmY](https://www.youtube.com/watch?v=a1rC79DHpmY)),
where he showcases how they could use tree-sitter to quickly parse entire
multi-megabyte minified JS files to provide complete syntax highlighting for
them that updates as you edit, and how the accuracy and usefulness of the
actual syntax highlighting can improve over regex based implementations due to
having access to the fully specified grammar of the language.

I think tree-sitter is also a game changer for extension development once it
stabilizes and the APIs are opened up. Extensions like swackets will no longer
have arbitrary performance constraints that break user experience
([https://atom.io/packages/swackets](https://atom.io/packages/swackets)), and
it opens the door to a whole new set of intelligent extensions that understand
the languages you write at a much deeper level that were previously unfeasible
due to parsing performance, or required some external heavy-weight language
server.

------
batuhanw
I tried really hard to not switch to VS Code. Wasting huge piece of my RAM +
randomly and REPEATEDLY crashes which ends up destroying entire settings,
packages to newly installed state. I'm done with it. I'm cool with VS Code.

I really had hope when they introduced V8 Snapshots on 1.17, then I had exact
same crash couple of days later. And memory management wasn't better. I was
even thinking about to replace my mac, because I was running out of RAM just
by having Atom + Firefox + iTerm with rails server and console running.

It's really annoying to have your editor, where you spend most of your day,
your shortcuts, extensions, settings, theme, all got destroyed in a moment in
the middle of the working day. And you have still have to keep working with
fresh installation settings. Damn. Worse, although I'm aware of sync-settings,
I keep forgetting syncing my settings as they are evolved with time and it
still feels insecure to be in need of syncing stuff because you don't know
when it will crash for the next time.

Looking at the issues, assuring that I did a good decision by moving away from
it.

This one is still open:
[https://github.com/atom/atom/issues/12255](https://github.com/atom/atom/issues/12255)

[https://github.com/atom/atom/issues/14909](https://github.com/atom/atom/issues/14909)
[https://github.com/atom/atom/issues/14922](https://github.com/atom/atom/issues/14922)
[https://github.com/atom/atom/issues/15443](https://github.com/atom/atom/issues/15443)

------
btown
To preempt the inevitable modern-editor performance flamewar, especially with
the introduction of a new parser: Has anyone been compiling statistics on
time-to-editable on app startup, non-trivial-project-with-a-bunch-of-tabs
open, and standalone-file open, for different Atom, VS Code, and Sublime
versions, on freshly-rebooted popular laptop hardware? The closest I can find
is from 2016, and isn't representative of large projects or code you'd find in
the wild: [https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-
atom-...](https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-
performance-dec-2016/)

All joking aside, it would be a fascinating analysis; all the rationales for
browser performance benchmarks apply here as well.

(And also, kudos to the Atom team for the new tree-sitter parser - very cool
stuff!)

~~~
Klathmon
I don't have a comparison that you are looking for, but I will say that I
recently did an experiment.

I timed (by hand using an app on my phone) the total time I spent "waiting"
for Atom to launch over a full work week. It came to about 80 seconds.

80 seconds in chunks of like 10 seconds or so mostly at the start of my day. I
have a shitload of plugins and my Atom instance loads significantly slower
than my coworkers, but even so 80 seconds a week is nothing compared to the
time savings that atom brings me.

Yes, it could be faster, but it won't materially improve my experience.

~~~
setr
Tbf the point of startup time isn't the actual time cost: its _rarely_
significant; even a 5 minute startup is only 5 minutes for an 8-hour workday.

But it _feels_ absolutely awful to have to wait 5 minutes to start doing
something useful. Especially when its not necessary, and when you've got
alternatives that start up _instantaneously_ (ie basic vim install).

The problem is in that transition from 10ms wait to 10s wait; the difference
is immense.

And of course, theres the idea that an order of magnitude difference isn't
_just_ an order of magnitude difference; it can enable entirely different
paradigms and workflows. In the fashion that the shifts in web-capabilities
correspond at least to a degree to the shift in network capabilities.
Streaming doesn't make sense on a 10kb/s connection, but on 10mb/s the whole
world changes

------
ak007
I used Atom for a long time till I encountered VS Code - haven't looked back
since. The startup time and integrated terminal just make VS Code awesome

~~~
kraftman
The debugger clinched it for me.

------
wldcordeiro
Every Atom release post is filled with VS Code fans talking it up, it's like a
law of nature on HN.

~~~
faitswulff
I was surprised at how popular VS Code was in comparison to Atom:
[https://insights.stackoverflow.com/survey/2018/#technology-m...](https://insights.stackoverflow.com/survey/2018/#technology-
most-popular-development-environments)

Is it really that much better than Atom? I quite like Atom, but I started to
use VS Code for Flutter development.

~~~
stouset
IMO, VS Code is everything Atom should have been and/or is trying to be.

It’s the first editor I’ve used since the original TextMate that worked well
straight out of the box, is easily configurable for 95% of customization
needs, and has high-quality extensions that don’t feel like they’re all
conflicting with one-another.

I don’t know if Atom has gotten any better in the past year, but it never
quite felt right to me. Lack of polish and care, I guess. VS Code had me a
convert from day one.

~~~
braderhart
Too many people in here running PR for Microsoft. VS Code is just as terrible,
if not worse, than Atom.. and built using the same bloated framework.

~~~
bdcravens
I haven't had that experience - I've found VS Code to be much smoother than
Atom, but obviously that may vary by platform and the particular set of
plugins any one user has.

------
jonathankoren
Atom is my go to editor now. It’s simple, it’s pluggable, and modern. I really
like it.

I’ve been recently using it with FB’s Nuclide, but that’s such a massive suite
of plugins, it might as well be a considered a derivative of it. I can’t
recommend Nuclide. It’s bloated, and breaks a bunch of behavior from vanilla
Atom, but it is the only thing that seems to get remote editing right. I just
wish someone would get that piece out of put it as it’s own plugin.

~~~
dflock
They are:

\- [http://blog.atom.io/2017/09/12/announcing-atom-
ide.html](http://blog.atom.io/2017/09/12/announcing-atom-ide.html)

\- [http://blog.atom.io/2017/11/15/code-together-in-real-time-
wi...](http://blog.atom.io/2017/11/15/code-together-in-real-time-with-
teletype-for-atom.html)

Still beta, though.

~~~
jonathankoren
Neither of these are remote editing. The first one is a link to IDE cruft, and
the second is collaborative editing with a a second full atom installation
complete with another GUI for you to click "share" with.

Remote editing is logging into a remote machine, and being able to manipulate
the files there just as if they were stored locally. Nuclide gets this right
[https://nuclide.io/docs/features/remote/](https://nuclide.io/docs/features/remote/)

Various sync plugins aren't reasonable because they want code in both places,
which is a complete waste because you'll never run the local code.
Alternatively, many of these require various per project config files which is
just too much overhead.

The rmate-like plugins look interesting until you find out that there's no
integration with the tree view, or any of the project like searching.

Some "solutions" that people point to are simply file transfer UIs, which is
just misunderstanding the problem.

This thread really explains the problems with all of these approaches.
[https://discuss.atom.io/t/working-with-a-remote-server-
throu...](https://discuss.atom.io/t/working-with-a-remote-server-through-ftp-
sftp-in-atom-solved-with-nuclide/28781) Sadly, only Nuclide does it right, but
god is there a lot of shit with it.

I guess I'll have to go with sshfs, but that's also a bit awkward.

~~~
dflock
I'm always a bit puzzled that people seem to want every editor to re-implement
this same feature.

What's wrong with sshfs? That does it at the OS level and it then works for
everything?

~~~
jonathankoren
sshfs is slow on macosx. Also, you have to remember to have a separate
terminal opened on the remote machine if you want to do any git stuff. Using
your local terminal and just cding into the mount point _should_ work, but in
practice it doesn't. The commands are just super laggy.

Also, you have to remember to mount and unmount the drive outside of the
editor, (especially if you close your laptop for a while), whereas if the
editor manages the connection, then it's transparent to your normal workflow.

------
maxharris
Has anything been done to improve speed? I tried running it on my Surface Pro
(dual-core i7 with 16GB of RAM), and it was unusably slow, ate up a lot of
RAM.

I like Atom's interface, but it's such a resource hog. So I will continue to
stick with Sublime.

~~~
jimnotgym
I use Atom on a 2nd gen core I5 laptop with 4gb ram with no issues. I use it
on a mid-gen i5 desktop 8gb on Ubuntu in Virtualbox on Windows aswell. It
would be interesting to know what is causing these horror issues some people
report.

~~~
ahtu123
Could be the size of the files. Atom at least used to just crash when you
opened a file too big.

~~~
jimnotgym
Atom warns you with very large files (like logs) before you try and open and
is not snappy like Vim. However that is yet to trouble me in my pursuit of a
code editor. I don't write code that is 300k lines in one file. When I am
reading logs I tend to use tail and grep anyway.

I don't see how this translates into general slowness for normal use cases

------
hughes
I'm surprised they still suggest to "store your github username and password"
locally when they could just as easily suggest to "store your github username
and auth token".

Even if it's locked in my OS's credential store, do I really want to trust a
text editor with my passwords? Why not suggest the more secure option? How
sure can I be that none of the atom plugins I use will try to steal it?

~~~
jonny_eh
You're trusting Github with your Github credentials. As long as it's secure
locally, I don't see the issue.

~~~
realPubkey
The problem are the many plugins that are not trustable

~~~
dawnerd
They say it's stored in the systems credential store so in theory a plugin
wouldn't have access to it anyways.

------
mavhc
Does it have a proper Windows installer yet? Multi user, Program Files for the
code, Appdata for the config, option to install extensions either for all
users in Program Files, or Appdata for one user. You know, standards, and more
secure when random programs can't alter the files of your editor

~~~
xpaulbettsx
Nah, they use the one I wrote still

------
wordpressdev
I took Atom for a ride, found it slower than VS Code. Not converting for the
time being.

------
jimnotgym
I know how popular Electron is on HN, but once it's on I really like Atom.
From the first install it had sensible defaults for Python, JSON, XML, HTML,
SQL which are my main stays. I even like the default colour scheme. Hopefully
in time it can start a bit faster...but that's all

~~~
ryannevius
Have you tried VS Code? It's also on Electron, but is (or at least _feels_)
significantly faster than Atom, and also has sensible defaults.

~~~
jimnotgym
Not for a long time, but I have no need to try anything else really. Atom does
what I need it to. One slow day I must try VS Code again, for sure.

~~~
namiller2
Today is a slow day.

------
Dowwie
Using Debian 9 and Atom currently. I used VSC for a little while but it became
unstable. It would often refuse stdin. Maybe the issue was the vim extension,
maybe not. Rather than troubleshoot, I went back to Atom and have had no
problems.

I work with about five languages just fine.

------
phaedryx
I've looked at VS Code a couple of times, but the Ruby support wasn't very
good (syntax highlighting didn't even work completely). Is it time to switch
or should I stick with Atom?

~~~
jinder
Yes, it's definitely time to switch away from Ruby...

------
piahoo
(points gun) Say Visual Studio Code again. SAY VSC again! And I dare you, I
double dare you motherfucker! Say Visual Studio Code one more time.

------
toomanybeersies
I use Atom for Rails development, because it has better Ruby on Rails support
than VS Code.

However, I am sick to death of its excessive memory consumption. This morning
it was using 1.5 GB of memory.

It's a text editor for God's sake!

~~~
hartator
I do Rails as well. How Atom is better than VSCode for Rails?

~~~
toomanybeersies
With its defaults, I find Atom a bit nicer to use than VSCode for rails.

It may just be because I'm more familiar with it, or because I'm too lazy to
set up VSCode and get the plugins for Rails dev.

------
hartator
Any reasons to switch back from VSCode?

------
Tehchops
Is 1.25 the number of TB of RAM you need to run it?

I'm afraid my workstation only has room for one Electron-based monster(Slack).

Hopefully the Rust re-write improves things.

~~~
RussianCow
> Hopefully the Rust re-write improves things.

To clarify, I don't think there are any plans to rewrite all of Atom in Rust;
the UI will likely always use Electron. They are just rewriting some of the
more intensive backend libraries in Rust for performance.

(Someone correct me if I'm wrong.)

