
Atom 1.34 - tosh
https://blog.atom.io/2019/01/08/atom-1-34.html
======
maxyme
These features are all great but Atom has some big issues to fix that have
been around for years. Things like the finder reindexing files every time the
window loses focus: [https://github.com/atom/fuzzy-
finder/issues/88](https://github.com/atom/fuzzy-finder/issues/88)

Additionally the Atom-IDE packages and what will happen with them, many of
them have PRs that have been merged in to fix bugs but never published to the
package (for about a year now). Although Facebook dropped support for Atom-IDE
it still has nearly 1 million downloads and largely works well but can no
longer be contributed to since the repo is archived and the packages aren't up
to date.

------
justapassenger
I’m old school vim person, so don’t have much clue. Is atom still relevant or
is vscode taking over everything?

~~~
pjmlp
VSCode is the only Electron app that I care to have on my computer, mostly due
to TypeScript and Rust.

Interesting how Microsoft manages to do in TypeScript stuff that Github not
even with C++ managed to (according to the interwebs), regarding performance.

Now that they are also part of Microsoft, maybe they could share some
information among them.

~~~
quaunaut
At the same time, on a giant project, I'm finding VSCode's performance starts
to fall apart completely where Atom performs the exact same as before.

For example- it's not uncommon for Vim mode in VSCode to just stop functioning
for 5-10 seconds on large projects while other addons continue operating.

I keep switching back and forth, primarily because VSCode's performance wins
are so deceptive- it will feel amazing and look cool on some things, then in
completely unexpected places just absolutely shit the bed. So I hop back and
forth, and have even started working on building my own plugins for VSCode to
do the things no one's added to it yet that Atom has addons for.

~~~
jgalt212
Got To Symbol is basically non-working in non-trivial sized Python projects
and doesn't seem to have anything to do with whether or not ctags is
installed.

[https://code.visualstudio.com/docs/editor/editingevolved#_go...](https://code.visualstudio.com/docs/editor/editingevolved#_go-
to-symbol)

------
brad0
I know this is not a popular opinion but I feel that atom never had the right
priorities for a project.

A text editor’s primary goal is to be fast and responsive.

Atom uses a rendering layer that makes no sense in the context of a text
editor.

Using a DOM introduces all this cruft that takes away from actually editing
text files.

~~~
Klathmon
But your wants and needs aren't universal.

My perfect editor needs to be as configurable and customizable as possible,
and I couldn't give a rats ass about startup performance or large file
rendering performance.

For me, an editor where I can't display inline images alongside text which is
in multiple languages (including some RTL languages) while linting and
providing IDE level features all while displaying inline test coverage results
is worse than an editor that starts instantly.

From that perspective, a browser is the perfect abstraction.

It's okay if Atoms priorities aren't for you, but saying they are wrong is
like saying trains are wrong because they can't do 0 to 60 in 4 seconds.

~~~
zozbot123
> For me, an editor where I can't display inline images alongside text which
> is in multiple languages (including some RTL languages) while linting and
> providing IDE level features all while displaying inline test coverage
> results is worse than an editor that starts instantly.

Emacs does provide these features, and it's not too slow at startup either.
It's a really nice operating system "abstraction"... too bad that they haven't
gotten around to making a good editor for it.

~~~
Klathmon
A big problem I have with emacs, and I fully acknowledge that it's shallow and
superficial, is that it looks bad.

I stare at this thing for hours a day, I like it to look nice.

That combined with the fact that I'm in JavaScript all day long, so it's super
easy to extend and modify Atom, means that it just wins out.

Atom is also a LOT easier to pickup than emacs ever was for me, and I tried a
few times.

~~~
m45t3r
Spacemacs looks beautiful tough, and has some pretty nice defaults (for
example, it automatically adds a layer for each language you're using, so you
have good IDE-like features without fuzzing with packages).

------
alexandernst
I was a big fan of Atom, but it's constant performance problems combined with
the fact that even after Atom's team rewriting huge parts of the project in
C++, doing witchcraft and what not, made me switch to VSCode.

I'm still really not sure how/why VSCode feels so responsive and performant
compared to Atom, which, according to Atom's devs lengthy blog posts, went
through a pile of refactoring, focused exclusively on performance.

Edit: Also, staying with Atom isn't really viable at this point, since
development was pretty much halted, in favor of X-Ray (aka Atom 2.0?). The
only significant changes that are being made are the GitHub-integration
related features.

~~~
Klathmon
Do you have any more info on active development stopping on Atom?

~~~
alexandernst
I'm saying this based on the decrease of activity in Atom's repo (publicly
visible in the "Insights" tab in their repo) and the fact that the last few
releases haven't had any significant changes, expect the GitHub integration.

~~~
apple4ever
Interesting...

I’ve been using Atom for the past 3 years. I’ve tried VSCode but it just
doesn’t work for my needs (I’m more DevOps than a developer). Not sure what
I’ll do if Atom is EOL’d.

~~~
9935c101ab17a66
I'm curious what atom does that VScode doesn't? I can see why someone wouldn't
want to use either Atom or VSCode for devops, but I really can't imagine a
situation where I'd choose Atom OVER VSCode or vim/nvim or even emacs?

~~~
Klathmon
For me it's that VSCode has targeted a slightly different market.

In Atom, plugins/extensions are king, and they can do EVERYTHING. Most of what
you see in the UI is a plugin. Tabs, the file-listing sidebar, syntax
highlighting, etc... If you want, you can replace the file tree with another
package, or you can replace tabs across the top with another plugin that does
tree style tabs along the side, or you can make a plugin that embeds the site
you are working on in a pane in the editor, or one that gives a full image
editor in the editor, or more. There is no limit, because plugins pretty much
make up the entire editor.

VSCode on the other hand is designed to try and handle most of that on it's
own, and plugins are much more limited by design. Many involved with Atom
attribute much of it's "poor performance" on the fact that plugins are so
powerful. All it takes is one poorly written plugin to break the ability for
the editor to handle large files (because that plugin was written in a way
that it reads and analyzes the whole file when loaded), and the API surface
needed to support that power limits the optimizations that can be done. VSCode
tried to stop that, but by design it ended up with a much more limited set of
things that plugins can do.

For most, it seems VSCode's trade offs are better. Most people don't need
crazy plugins and anything special can be rolled into the editor itself if
needed. But I personally like Atom's ability to swap out even core elements
and make my own plugins which have the ability to do ANYTHING in the editor.
And every time I've tried VSCode I became annoyed at the limitations that were
imposed, and I felt I was constrained in how much I could customize and modify
the editor to my liking, so that's why I don't use it and I stick with Atom.

------
haolez
I was an Atom user until 1.30 or so and I really like its UI, but sometimes it
would just max the CPU usage in my Linux box until I closed it and opened it
up again. I don't like VSCode as much, especially its clunky Git interface,
but it is more stable than Atom and I'm sticking with it for now.

------
bhhaskin
It seems like all of these changes are related to being able to use git inside
of atom, but I use the terminal for that and have zero desire to use clunky
GUI. The last few release haven't addressed any of the issues or really
progressed the editor forward.

------
h1d
Will Electron's development slow down when Atom has other strong competitors
and lose traction?

------
tosh
commit previews:
[https://github.com/atom/github/pull/1767](https://github.com/atom/github/pull/1767)

