Goodbye Atom, some feedback


#1

Before I came here I was using Sublime Text. It was the perfect editor for me so I had very high expectations. I left ST for two reasons, its future was/is somewhat unclear and its plugins are limited to Python.

So I tried to use Atom for three months as my primary editor. Not everything was going smoothly but I expected to fix that as Atom claims to be A hackable text editor for the 21st Century.

Strangely, Atom excludes a lot of devs by being walled off in CoffeeScript. I don’t want to argue about the language but for me, personally, I see no value in investing my time into CoffeeScript. Apparently I’m not the only one.

The argument that plugins can be developed in plain JS is somewhat true but you’ll be always treated as a second class citizen. I tried to work around that, mostly as a joke, but it’s not a fun experience either.

The final option, reporting bugs/requesting features, isn’t especially rewarding, as with most open source projects. There should be more transparency about what is going on, what will happen and when.

Disclaimer: I think the Atom devs are doing a great job, I just wanted to leave some feedback.


#2

Thanks for the feedback. Sorry to see you leave, but I can understand that we all have a limited amount of free time and we have to be particular about where we spend it. Good luck!


#3

I somewhat agree. I just had a bug that related to switching the dom elements to custom elements. The custom elements are awesome but I had no Idea about this breaking change. There was recently a blog about changing the event framework and that was very useful. I think there should be more communication like this.

I follow this discussion group on every post. I have thought from the beginning there should be a technical package developer topic. The current packages topic covers users asking for packages and other non-technical items. Of course all the core group would need to hang out there at least on occasion.

This is not your usual open-source community. Every such community has a core group of developers. This core group isn’t on any discussion group. No one outside the group gets any votes on architectural changes. I also suspect they work inside github sitting near each other so there is a level of communication that can’t allow volunteers in.

Enough bitching. Let me just ask for more blog posts. At least one for every breaking change like custom elements.


#4

Nope, according to their GitHub profiles, @nathansobo, @benogle, and @kevinsawicki are all located in different cities.

And regarding the transparency, just follow the GitHub repo? Everything is out in the open.


#5

How would you like to see support multiple languages implemented? Or is better support for pure JavaScript good enough?


#6

Atom may be different but I find it hard to chat on issue lists. Coffeescript only used issues for some time and it got ridiculously hard to separate the bug reports from technical discussion. And searching was near impossible. And the issues software sucked compared to real discussion boards like this. (And there was no @leedohm).

So I started a coffeescript google group which was quite successful in the beginning. But the core developers never came over and there weren’t even any release announcements. So it is almost dead now.

Having said all this I will try following the repo.


#7

I just looked at the repo. The first 21 issues were bug reports. Out of the first 75, 65 were bug reports. i personally don’t find bug reports very interesting.

How do you personally follow the issues on the repo?


#8

I went to the home page of the repository (https://github.com/atom/atom) and clicked the Watch button. Then I just read the stream of notifications that show up in my GitHub inbox. It’s true that you’ll occasionally get sidetracked with a bunch of notifications for “+1”, but for the most part I’ve found it to be a good way to keep up on what is changing in the code base.


#9

Sorry about this. Thanks for the feedback.

We could definitely be more clear about this. We do have a roadmap. The absolute specifics of when something will ship is not known, but we have some general deadlines, and tasks for those deadlines.

Sorry @mark_hahn about the breaking change. I wish you guys could just follow our PRs. Nathan and Kevin have had a bunch of PRs related to custom elements and view system changes in general. I suppose you can follow us on github, and our activity should show up in your feed.

Some things I can think of off the top of my head to increase transparency:

  • post the roadmap with general guidelines on here, or on the atom/atom
  • open PRs super early in the process with an explanation of what we’re doing

#10

I’ve been holding back on blogging about things until it’s clear. It’s a tough balance. I don’t want to make a big deal about a change that might end up needing to be reverted. I also don’t want to encourage people to use custom elements until everything is in place to make it a good experience. It should be completely possible to use SpacePen still. If it isn’t, I consider that a bug.


#11

That would be cool. Is there a way to follow those without all the bug reports? If not maybe I could create a gmail filter to show only those.


#12

Just bookmark this (or some such), and check it every morning when you have your morning coffee or whatever beverage is your preference :sunny:


#13

When you report an issue you might get an answer like

  • It’s not high on my priority list.
  • It’s working as expected, use a package to change it.

In either case, the first thing I’d like to do is look at the code (in core) and debug it to figure out what is going on. To make that as easy for everyone, core would have to be pure JS.


#14

If you could make that public that would be great.

Maybe you can add some help on atom.io about what information is already available and where to find it.


#15

Roadmap would be nice, as there are a lot of things like just to note a few:

  • Loading times (regardless of it being plugins – my sublime has hundreds of plugins and startup is immediate, it’s all about how you load them)
  • Pane resizing
  • Error console opening on error…

Or at least a centralized bug/issue tracker


#16

I’m a former Sublime user as well, and I don’t see how it’s better than Atom in any of the ways you mention. For one, it’s closed-source, so there’s no CoffeeScript or X debate. Secondly, plugins have to be developed in Python, and the API documentation is terrible. I have my gripes about Atom, but Sublime doesn’t win here.


#17

I wasn’t comparing the two. I was trying to explain where Atom is lacking IMO.


#18

I want you guys know that transparency is important to me. Surfacing more information will take some time but it will be worth it. It’s something I’d like to focus some attention on once the API freeze is completed in a few weeks.


#19

For some reason sublime 2 on my system took 5 seconds to load. I never understood why. Maybe a bad plugin.


#20

Sublime 2 loaded plugins as part of the main sublime executable. Sublime Text 3 loads plugins as part of the plugin_host(.exe) binary, which gets launched as the editor itself is starting. So while Sublime itself opens up immediately, the plugins will take a couple seconds to load (and is why package control doesn’t rant at you immediately)