As is usual with these releases, i'm always more interested in the new Beta's.

1.13 is going to have some pretty big changes. They are removing shadow-dom which is kind of a big deal and i'm really curious for the in-depth post about what didn't work with it later (until then, [0] is the PR that talks a bit about why).

And 1.13 will also include a change [1] that will allow it to better handle large files, which I know is a huge plus for a lot of people (it hasn't been a problem on my machine for a while now, but clearly people are still having issues with it).

It looks like it's going to be a good update.

[0] https://github.com/atom/atom/pull/12903

[1] https://github.com/atom/atom/pull/12898

As much hate as Atom gets in these threads, I'm impressed by the team's (and contributor's) continuous work into making Atom as good as possible.

Though it might just be a small, loud minority: Most devs I meet in real life use Atom with no problem or just have no opinion on it.

I've stopped caring what "HN" says about things.

I'm mainly a javascript/php developer that uses Windows and Atom... I'm used to being told I'm wrong. But at the end of the day, these are the languages, platforms, and operating systems I get the most done with, and I just don't seem to hit the issues everyone keeps saying I will.

I also use Atom, and just can't seem to garner an affinity for VS Code. I came from a .NET background, so I've struggled with Visual Studio and Nuget for years, and it left a bad taste in my mouth. I'm also probably just used to using Atom for my Node development. But aside from finding out very quickly on here that I'm wrong for using it, I don't find anything difficult. I've built many successful projects with it.

Also, Nintendo kicks Sega's ass.

I love VSCode from a technical standpoint. They have clearly picked a better architecture when it comes to performance, and they have done a pretty damn good job at showing that a web-based application doesn't need to be a "slow resource hog", but on the other hand I MUCH more prefer Atom's policy of "plugins are everything" over VSCode's "Core should do everything, and plugins are second class".

But at the end of the day, it's a choice, and i'm glad we have competition to keep everyone on their toes!

I totally agree, I wish there was 50 viable choices. Competition is good, look at our ISP situation.

Same here. I get funny looks for using Emacs at work. I tell people that I've done all of my best work with Emacs for 20 years, and the only way to get me to change is for management to implement a standard, required tool suite.

Your not "hitting the issues" because a lot of them are philosophical, so if you don't care, you just don't care. I also did not care for a long time, now I do care and I get to hold that over your head. The more you know, the bigger jerk you are allowed to be :)

Damn, I gotta learn haskell!

Hate? Does it? I use Atom for Rust development, and so far it's the best I use there. From that I started using it for some JavaScript, and now for other languages which have less IDE support out there.

It's an excellent editor IMO and easier to configure than emacs, gets support for new languages etc faster than the IntelliJ derivatives.

At this point the only thing I really miss (I haven't set it up yet) is a steppable code debugger, and smart code refactoring, like IntelliJ's excellent method renames or variable reordering operations.

> I use Atom for Rust development.

I think that sentence is funny. It also explains the hate. Ideally highly optimized tools would be used to use/create/run more user-facing, less optimized tools.

People are working on that in Rust, but it's taking a little while.

I like it. I'm a Python dev, so there's this gravity pulling me towards Sublime or wanting to like Sublime more. And, while Sublime is faster, I think I just like the way Atom looks more (a bit cleaner IMO), and I've gotten use to the default keybindings.

When I was on Mac and in the earliest versions of atom, I suffered through the slow startup time and keystroke lag for the ease of customization (JS/coffee, JSON/CSON; vs custom DSL, C, Python or whatever). Altogether, I'm not very opinionated about text editors, so the pros and cons were pretty negligible. Upon switching to Linux, the performance were gone. I don't know if it was because I'd been using too old of a version on Mac or if OS X just has a latency penalty for using web views.

I personally don't have any perf issues on Linux or Mac, of which I use both regularly.

I've been using Atom since a fairly early version, upgrading with each release, and it has improved a lot. My guess is that SSD makes the biggest difference, though: startup is near instant on my current MacBook, but can visibly struggle on my older work iMac if there are Windows VMs hitting the (spinning rust) HDD.

My one gripe is how it handles large files. It's definitely an issue because if you fuck up and "accidentally" open one, it's a bitch to get Atom to stop (you basically have to kill the process, which always feels heavy handed) and basically drop to less, which sucks because the whole point of using Atom is to get away from the terminal.

I definitely still use it, though, for python projects smaller than 1,000 loc.

Yeah, now if only they could make it not crash and leave me with a 0 byte file after I've done 3 hours of work on it, I'd really appreciate it.

When was the last time you used it? IIRC it auto saves every so often and I've never list more than like 5 minutes of work.

Just last week this happened. Not sure how, what or where it autosaves, but it sure didn't recover from this.

I haven't gone that long with saving something since I lost 6 hours of work in Photoshop a few years ago.

I was saving constantly, just hadn't committed it as I hadn't finished the task yet.

It wiped the file when I saved the last time before it crashed.

Wow. Pretty much the worst kind of bug you can have in an editor. Did you ever trace it back to a specific bug? I'm a tiny bit concerned now.

Shadow DOM fixes CSS scoping with the caveat that it fixes CSS scoping. If want to allow a 3rd party to style inside of a shadow root CSS variables is the only current way. While this works, it's pretty painful to pass variables for each property you need to style.

We desperately need CSS @apply [1] which gives CSS something similar to sass mixins. So to theme inside of shadow boundaries you would pass @apply rules.

[1] https://tabatkins.github.io/specs/css-apply-rule/

Also, on a minor note for us package creators and maintainers: this version includes the latest version of CoffeeScript, 1.11.1, which will make package development less of a dark ages exercise.

Now I am really tempted to install 1.13... Many of those changes are pretty big deal, and I am really curios to see will there be any (better to say how much) performance improvement.

I feel the same way with most releases, but the Atom team means it when they say it's Beta.

It's easy enough to switch between the 2 releases, but don't do it on a day where you will need to use the editor in any serious way. Bugs will happen, and with this one in particular you are almost guaranteed to hit visual issues.

I liked Atom. But the more I use it the less I like it. Paying 300MB of RAM to edit a 5KB file seems idiotic. And the fact it can't open a file larger then 100K-256k means I can use it to manually inspect logs.

It was a nice distraction, but back to VIM.

I'm the same way. I certainly don't hate it, but it felt slower than other editors, and didn't provide any unique features critical to my workflow. I have plenty of co-workers that use it and seem to like it.

I haven't had another text editor in quite some time. I used to have IntelliJ when I did Java dev... and Visual Studio when I did C# development. But since I've been at my current job, vim has pretty much been it. (I keep emacs around - and recently kept Spacemacs up to date... but I only used it for one day). The past few months, I really had this inkling to play with Atom. I downloaded it, set it up and tried it for a few minutes. Vim has a way of destroying other text editors. So I did the next logical thing. I installed vim-mode for Atom. It mostly works. I still can't bring myself to convert though. Vim is an awfully good vim. I love working in Tmux with a terminal running right next to my editor.

I switched to neovim, because it supports 24-bit color themes. Stock vim is just too limited for me with 256 colors max. With neovim I can have themes that are easier on the eyes.

I did the same thing but now I am using VS Code after trying it because someone said it was faster then Atom. Might be worth a check?

I switched to VS Code last week after using Atom almost since it was released (probably 0.70.0 or so) and I immediately decided I wasn't going to switch back. It's just so much smoother, and the debugger (+ requisite extension for PHP) is really nice. Based on some of the comments here I might try Atom again at 1.13 (I tried VS Code back when it was new as well), but for now I reckon VS Code is miles ahead.

It not gets mentioned often, but the settings pane in Atom is unsatisfactorily complicated. Three subpages ("Packages", "Updates", "Install") to manage packages. Information for packages (name, version, downloads, readme, settings) are mixed together in a chaotic single page.

VS Code has a single sidebar subpane to list extensions. For each package the information (name, version, author, downloads, readme, extension points, changelog) are either always visible or separated clearly into subpages.

You made me curious, how did you configured VS Code with PHP. I have bad experience especially with that language in VSC. In Atom and Sublime there are many various extensions which helps you get better _IDE experience_ (autocomplete. formatters, linters).

Personally, I found Crane for VSC [1] as a very limited tool for autocompletion. It works really bad with frameworks like Laravel or Symfony where developers use various design patterns which implements a lot of abstraction difficult to index (facades, factory, repositories, service providers, @inheritdoc). Using Sublime you may probably use SublimeCodeIntel [2] with PHPIntel [3], as their best feature is I would mention that they work very fast for large codebase and also gives great suggestions for code i.e. suggests paramters or next objects in namespaces (when you are typing backslashes (\) code intel will start guessing what objects are under specified path and it works flawlessly just like in vim or bash when you are pressing tab after `cd`). Atom is not bad either, the atom-autocomplete-php [4] package is really great to improve autocompletion for PHP Code. When I have been using it recently I was really enjoying how many decent features PHPStorm has been implemented in open-source Atom, e.g. if you add a class from not imported namespace it will be automatically added. Such a simple operation, but it is interesting how many editors does not support that.

Hopefully, php devs have some awesome tools to annoy them a whole 9-to-5 which are: `phpcs` (obviously), `php -l` (popular), phpmd (rarely used) and phpcpd (well, most php devs haven't heard about that tool). Since, aforementioned linters are binaries their implementation in editors like VSC, Sublime or Atom is not a problem. There are few differences between editor and their linters - they are mostly the same but each editor have another way to display problems in your code. It is rather matter of taste I would say. Well, I really miss "unused use-namespaces" in phpmd.

Personally, I dislike XDebug. VSC gives a nice user experience when debugging code with it. But all three editors supports XDebug somehow. Maybe Sublime puts a whole stacktrace, breakpoints, local variable into editor viewport as "plain text" but you may got used to like in Atom, where there are additional panes to see Xdebug output. Personally, I would go with Backfire if we speak about profiling, which is very painful in XDebug.

[1]: https://github.com/HvyIndustries/crane

[2]: https://packagecontrol.io/packages/SublimeCodeIntel

[3]: https://packagecontrol.io/packages/PHPIntel

[4]: https://atom.io/packages/atom-autocomplete-php

Give this a try: https://marketplace.visualstudio.com/items?itemName=felixfbe...

I also share the same experience, I really wanted to get into Atom but found the experience clunky, can't quite put a finger on it, but Atom felt more like a web app running on a thin client, whereas VS Code, while I know it's the same deal, feels very much like a desktop IDE.

Yup, definitely not going back unless they fuck it up which I highly doubt, Microsoft of 2016 is very different from 2006.

Are they improving the performance issues?

I love Atom but I've had to switch to Sublime 3 because I can't handle waiting a couple of seconds every time I switch between files (or the several second start up time).

It's small but it completely kills my workflow.

I spent the whole weekend setting it up to look similar to my Atom setup, including implementing the same syntax highlighting. It's not perfect[1] and feels like it could fall apart at any moment (eg I had to do an awkward hack to center text in tabs), but it's worth it for lightning-fast switching between files.

[1] http://i.imgur.com/t1ULTfy.png

Any more details what does Chromium 52 and Electron 1.3.x bring to table?

Is anybody using Atom on Linux? The last time I tried, there was an issue where each time the cursor was moved horizontally, its displayed position and actual position would diverge a bit so that after a minute or two of editing a file you couldn't tell where you were typing. I believe it was a known (upstream?) issue at the time but that was obviously a deal breaker.

I can echo bbrks comment. I've used it on Ubuntu for a year and OS X for 2. I haven't had any problems with it other than slightly different key bindings between the two which can cause some confusion.

I had an issue with blurry fonts on a high DPI display using Linux Mint 17.3. It was easy to fix and now it runs just fine and became my editor of choice next to my IDE.

I've been using Atom for almost a year in Ubuntu and OS X without this problem.

I use Atom on Debian and Arch without any problems

I hope this isn't just placebo, but I can see a noticeable increase in performance compared to 1.11. Less typing/autocomplete lag in general.

PS: how about some hashes or GPG signatures on the download page, Github people?

Any FreeBSD port yet?

Building from source seems to be trivial: https://github.com/atom/atom/blob/master/docs/build-instruct...

I moved to Atom from jEdit (on Linux). I build it from source and it runs well. And SFTP plugin is working well. I've been coding 20+ years and find Atom easy to use and customise.

I'm teaching code too, Atom is pretty easy for beginners as well.

Until Atom or VS handles autoclose tags the way Sublime does out of the box, I'll have a hard time moving over. Sublime beauty packages also work great with a simple command to keep all my code nice and tidy.

Impressive to see so many contributions from the unpaid rabble. vjeux's PRs are mentioned twice in that blog post.

Even if GitHub gets bored, hopefully Atom has the momentum to keep going.

Adding a project folder with approx. 50 000 files took 2-3 seconds, but the search-in-project functionality broke down, even UI response (when entering the search string). Takes several seconds per character to appear, as I try to input a search string.

Ctrl-f macro support, no results. Sigh.

Until it's in core, are you using one of the macro plugins?

I'm not. What do you recommend?

The only "innovation" I am waiting for in every release is humane performance. Didn't happen so far :-(

Great editor. One of the best.

"International Keyboard Support"

And it only took them two and a half years!

They wrote a blog post about this:

http://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboa...

i18n is really difficult.

If you have an issue with it, maybe you should have contributed sooner.

I'm incredibly sick of seeing this argument. Just because someone uses a piece of open source software does not mean that they A) Are obligated to contribute to it B) Are disallowed to want features or complain about the lack thereof for not doing A and C) Are even capable of contributing to it.

e- analogy was weak and unneeded.

Complaining about the lack of a feature in a FOSS project that you haven't contributed to is kind of a dick move, though, and it's extremely discouraging to developers. If they violate community standards or put users at risk (breaking semver, insecure elements, malware, etc.) then you have the right to complain, but otherwise you really ought to remain civil and positive.

Politely requesting features is fine, but complaining about a lack of features in software that you don't contribute to with effort or money is extremely rude and pretty much a slap to the face for the developers who work on the project.

Atom is developed by paid professionals at github, it isn't really a community led project like emacs.

Not that that matters, because nothing is immune from criticism, free or otherwise. It is a useful service to provide criticism, in fact, it can be useful to the developers and also useful to potential users - although it doesn't have to be.

There is a difference between providing useful, constructive criticism and rude complaining.

Pointing out that the technology platform chosen makes features simple elsewhere into multi-year odysseys seems fine to me. I think maybe atom users are too close to it, so have heard such things before and react very negatively to it. For me it was interesting to learn it took significant work to provide this support.

yes but "look at how long it took them to add X feature!" isn't useful critisim, it's a put-down.

The product isn't going to improve because the developers felt worse about finally getting a requested feature in.

A lot of FOSS work is done by "paid professionals", that does not change the fact that you get the software for free.

It also doesn't give them the right to complain that their feature took however long to land.

This is like being able to vote and abstaining because you didn't like the candidates, then complaining that the candidate you didn't like was elected.

Are we still using that godawful argument?

* Not contributing and complaining about issues

* Not voting and complaining about the candidate elected

* Not making movies and complaining about the special effects

* Not writing books and complaining about the story

* Not building cars and complaining yours broke down

* Not having prepared food and complaining someone served you burnt pasta and uncooked chicked

* ...

Common point in all of those: they're all stupid arguments. That argument has never been, is never and never will be valid. Contributing takes time. Maybe said person complaining is fixing bugs in software that you're using. Or maybe said person doesn't contribute at all to any OSS. And that's still perfectly fine, because when you put out software and present it as the second coming of the Christ (or Stallman, depending of your deity of choice), yep, you have a responsibility to fix it. Or to not fix it and to tell the users to sod off. Users have absolutely every right to complain. As a maintainer, you have every right to ignore them.

You have some valid points but president analogy is not very accurate. People are paying president's salary, while majority of people using OS projects are definitely not paying the salary of the devs.

FWIW, what I understand from the release notes is that it seems to have been an upstream issue with Chrome 52, not atom itself

The problem was that they used Ctrl + Alt for shortcuts, which is something you simply not do on Windows. Ctrl + Alt is the same as AltGr and there are keyboards without a right Alt key. AltGr + X looks like Ctrl + Alt + X, because that's what some people have to press. They are meant to be the same thing.

Chrome merely happened to implement that part of the UI Events spec (it's still a draft) which lets you differentiate between Ctrl + Alt and AltGr.

https://www.w3.org/TR/uievents/#code-examples

The Atom team simply could have changed their default shortcuts 2.5 years ago. Those shortcuts were the actual bug.

So the real issue is building a text editor on top of a browser?

there were workarounds...

Most didn't work until 1.12. For example, keybindings featuring {