Sublime Text or Atom?

Hello, my name’s Domi and I’m a extensive Sublime Text abuser. I’m also on Twitter and I saw the uprising of GitHub’s Atom lately, so I decided to give it a chance. This is my story about switching from Sublime Text to Atom for a couple of days.

I’m biased

I used to work with Sublime Text for ages and my cerebellum is perfectly trained for it. I just load my config and I’m ready to work as productive as possible. If you want to stick a label on me then it might be something between “Pro User” and “In Love With Sublime Text“. So I’m a bit biased because I’m completely happy with my current choice of editor and I’m not ready to change my complete behaviour just because of a new trending editor.

However, I’m also a techie guy and I don’t want to miss anything special and awesome out there and therefore I’ve to give Atom another chance. I used to play around with Atom one year ago but I wasn’t very pleased then. I always thought it was a nice editor, but not as mature as Sublime Text. Let’s see how time changed Atom.

Installing Atom

Installing Atom is quite simple and straight forward. You’ll browse to the Atom’s website, hit the download button, unpack the image, copy Atom to the applications folder and start it. A typical Mac OS X application.

When I wrote this blog post I was testing the latest stable Atom (version 1.8) on Mac OS X.

Look and Feel

As mentioned before, I had a look at Atom over a year ago and I never used again since. So this is my second time using Atom as my daily development editor.

The look and feel of Atom changed quite a bit. I really like the default theme of Atom. There’s nothing like a dark skin, especially if you’re used to work at night and in dark environments – most nerds love dark rooms for coding 😉 Though, I didn’t want to stick with the default theme / skin and therefore I had to find an alternative. I already knew exactly which theme I’m interested in, because I’ve a SublimeText port of it as well – the seti-ui dark colored UI theme. There’s also a seti-syntax theme, but I didn’t like the colors so eventually I switched to the Monokai Seti syntax theme.

With the Seti UI theme and the Monokai Seti syntax theme I’m quite happy. To be honest, it looks pretty awesome – YAY! Atom clearly scores with it’s first impressions of the look and feel, especially with the available 3rd-party themes.

Settings

If you’re familiar with Sublime Text then you’ll find yourself smiling pretty fast. There are a lot of familiar key bindings well known from Sublime Text. For example Ctrl-D, Ctrl-Cmd-<Up> or <Down> or Shift-Cmd-P. Well done Atom, I already feel really comfy and this makes switching from Sublime Text to Atom really easy.  However, I didn’t want to play around with all the default settings and I wanted to customise my editor to match my coding style and my behaviour. So I started to have a look at the settings.

For those who doesn’t know Sublime Text: SublimeText has no graphical settings window or alike, because it’s all handled in JSON files. Key bindings, mouse settings and general settings – all are handled in JSON files. There’s always a JSON file with defaults (will be overwritten on an update) and a JSON file for user definitions (overwrites defaults). There are global settings and there are package specific settings files.

Atom changed this behaviour a bit. Instead of JSON files you’ll get CSON (CoffeeScript) files. In my opinion, they’re more readable and they “feel” a bit nicer than their counterpart. However, Atom won’t throw CSON files at you in the first place, because Atom has a built in settings UI where you can overwrite the defaults for “Core Settings” and “Editor Settings“. To my surprise, every changed setting is automatically stored in a config on the filesystem (i.e. ~/.atom/config.cson), so you can easily backup and/or deploy your config file later (e.g. via Ansible role). At first I really liked the idea of the settings UI but I started the get annoyed by it really soon. There’s no search or filter function, so you’ve to scroll through all the settings by yourself and read them line by line.

My conclusion for the settings: The UI is a nice touch but I prefer Sublime’s default JSON which is perfectly searchable. There are approximately 50 settings available and I think more are coming. Unfortunately the settings UI doesn’t look very “clean” and it feels a bit chaotic – much like the settings on an Android or latest iOS devices. I would prefer a simple searchable “key-value” list for the settings over the shiny wanna-be UI, but that’s just my two cents. Though, it’s nice to have explanations next to the settings and I really like the idea of having a (let’s say compiled) config file with the customised values.

Key Bindings

Sublime Text is well known as fully customisable editor. Key bindings are the perfect example of customisation. We remember, all key bindings in Sublime Text are stored in JSON files.

GitHub did a pretty decent job implementing key bindings in their editor. To be honest, the UI for browsing the available key bindings really rocks! Each list item will show you a key binding, command, source (e.g. core, package name) and selector (when / where the key binding is active). Unlike the settings view, the key bindings have a search field which can be used to search for key strokes and/or commands.

Of course most of us don’t settle with the default key strokes and want to have their own key strokes – or is it just me? Atom also has a really neat solution for this problem. On each key stroke item you’ll see a Copy-To-Clipboard-Icon-Thingy. You can click on it and paste the content into your own keymap file (i.e. ~/.atom/keymap.cson). Pretty straight forward and dead simple – I love it! Of course you can overwrite key strokes or even unset them by defining a value of unset!.

Sounds all really nice, but the one thing I miss from Sublime Text is the “Go-To-Anything” feature. Atom decided to split the Go-To commands up and I don’t like that, but that’s just personal preference.

So my conclusion for key bindings: Atom did everything right there, except for the Go-To-Anything command!

Packages

Of course Atom also supports 3rd-party packages. The installation of those packages is pretty straight forward and is made via a nice UI. Here’s a list of packages I installed so far:

• atom-beautify – beautifies code (e.g. make Python code PEP8-compliant)
• atomic-chrome – use Atom to edit text in Chrome (e.g. text fields)
• autocomplete-python – auto completion support for Python (e.g. vars, methods)
• git-commit – simple git commit plugin
• git-control – complete git UI
• git-log – rendering of the git log / history
• git-plus – git on steroids
• git-time-machine – visual time travel for your git repo
• linter – well, a linter with plugin support
• linter-pep8 – PEP8 plugin for the linter
• markdown-preview-opener – opens markdown preview automatically
• markdown-scroll-sync – scrolls markdown preview with source code
• pigments – shows colors in CSS and HTML
• project-view – show project state in tree view
• rst-preview – reST previewer
• tree-view-git-staus – shows git state in tree view
• vim-mode – enabled VIM mode

There are a lot of great packages available and the ones I tested are well made (documentation, functionality, stability). The rendering of the read me inside Atom is also a really nice feature. Here’s what I’ve learned so far:

VIM mode in Atom can be enabled via the vim-mode package. It works really well and is a nice as the Vintage mode in Sublime Text.

I like my Python code to be PEP8-compliant and therefore I was using the Python PEP8 Autoformat Sublime Text package. If you want to have the same features in Atom you should use 3 different packages. You want to use linter and linter-pep8 to display warnings and errors. If you want to auto-format your code then I recommend the atom-beautify package. A really nice combo, well done guys!

Because I write a lot a markdown and reST/RST I also was looking for a replacement for Sublime’s OmniMarkupPreviewer. To my surprise Atom has a built in preview package and it works really well for Markdown. Together with markdown-preview-opener and markdown-scroll-sync you’ll have a markdown preview on steroids. The preview will automatically open when you edit a Markdown file and it will scroll along with your source code. Really neat packages, however not compatible with reST. If you want reST support, you need to install rst-preview.

One heck of a plugin is the pigments package. It’s a perfect, when not better replacement for Sublime’s Color Highlighter.

So far so good and installing packages is straight-forward. However, uninstalling packages is currently a PITA because I ran into a well-known bug which didn’t allow me to uninstall packages. This was quite annoying, but it’s already fixed in 1.9-beta. So my conclusion for the package manager of atom: It rocks.

By the way, you can also use apm, the Atom Package Manager on the command line to install and uninstall packages.

I also had a quick look into developing packages for Atom. If I’m not completely wrong then you’ve to do that in JavaScript compared to Python in Sublime Text. Guys, I don’t like JavaScript because it’s an ugly and completely retarded language – at least my opinion 🙂

Git integration

One big advantage of Atom is the git integration – at least this is what Atom claims to be good at and what you’re expecting from GitHub. However, reality kicks in pretty fast.

I opened one of my git projects and started to work on it with Atom. I thought with having git integration in Atom this is going to be an easy topic, but I had to learn my lesson. First of all, the stock git integration of Atom is rubbish compared to other products. So I started to look for alternatives like the excellent SublimeGit. Here’s what I came up with:

First of all I gave git-plus a try. It’s a vim-fugitive like package for atom. You should be able to do a lot of git things within atom and without a terminal. Long story, short: Yes you can do a lot of things with it and some of it works pretty nice. For example, if you want to commit a single file or all of your files, then it perfectly works. There’s also a git status built in which works “OK”. But more on that later.

I also tried git-control which is a complete git UI integrated in Atom. It’s well made but a bit annoying because you need a lot of mouse movements and I’m a keyboard guy. The diff functionality is also a bit “weird looking”.

There are more plugins available like git-commit which allows you to commit only some of the modified files and git-log which renders a shiny history of your commits. However…

If you’re used to git and you “know” how git works you start banging your head against the table. The git integration in Atom is anything else than properly done and is rubbish compared to other editors and IDE’s. It lacks of the most important features and you’ll end up jumping between files and hitting weird key strokes just to do the basic things. But let me explain that:

Let’s say you work in a project and you’ve a clean repo state (i.e. everything is checked in). Now you want to add another feature called Feature-B and for simplicity let’s say you do that on your current branch (e.g. develop). Let’s say you already have a Feature-A in your project and you can reuse parts of it (e.g. a JavaScript snippet). So the thing you want to do is take this JavaScript snippet out of Feature-A, put it in a separate “library” and update Feature-A to use the new dedicated library. This is called refactoring and is made pretty often in the development process. Now you’re able to add Feature-B and point it to the dedicated library as well. After everything works you want to commit your changes. You will now have something like this:

• Feature-A was modified
• Feature-B is new
• dedicated library is new

It doesn’t matter if I forgot to commit Feature-A and the library or if I did it on purpose. Fact is, I don’t want to commit all these 3 files with one commit because I want to have 2 separate commits. One commit for the refactor and one for Feature-B. Let’s do that on Atom.

With the stock git integration I’ve no chance and I’m completely lost. If I use git-plus I’ve to add all files manually, which means I’ve to open each file separately and add it – which is already PITA. If I want to make a diff in advance then it’s even a step more. Of course I can also stage all files for the first commit and then unstage Feature-B, which is possible via git-plus. However, the git-plus stage/unstage commands are a PITA because I’ve to open the command window, enter stage/unstage files, select a single file by mouse (!!!) and manually click on the stage/unstage button. No keyboard support there and I’ve to repeat this step for each single file – dunno if it’s a bug or works as designed. Of course I can use git-commit for that, but again no keyboard support!

Now let’s talk about file statuses (is this a real word?!?) in git. A file in git can have a status of added/new, modified, deleted or renamed/moved. Atom will display the file status in several ways which is nice. However, there’s a big difference of a modified unstaged and modified staged file and Atom won’t display you these differences clearly. Yes, you can hit Shift-Cmd-B the have a status and you see the difference of staged on unstaged files but you need to buy a pair of binoculars to see the mm difference of the M (modified) flag. The M flag will move 1mm left as soon as the file is staged.

On the contrary in SublimeGit you’ll have a proper git status with all your staged and unstaged files. You can move between the files (hitting n), diff (hitting d), stage/unstage (hitting s or d) and commit (hitting c) them. This is how you work with git! You want to have a status of your files and you want to diff/stage them separately without opening every file and hitting a bazillion key strokes just to do some basic things.

So my conclusion for git integration in Atom: You can’t use Atom for all your git operations and you always need to have a terminal open for your git commands. If you watch Youtube clips on Atom & git you’ll recognise that most of the users switch to the terminal for git commands. This is not what I call integration – not at all! If you want to commit one single file or all your files at once then you’re fine! Though, if you’re used to work properly with git then you’ll get a headache after banging your head against the table. Git is a big no-no in Atom!

Performance

Atom is a fast editor and it works pretty well, at least in most cases. Though it seems to have some issues with bigger files. I also had some glitches in my settings tab which made Atom unresponsive, especially when you’re about to install / uninstall packages. Atom also felt a bit sluggish sometimes, but nothing compared to other editors like Eclipse or alike.

Though from a performance point of view, Sublime Text will leave Atom in the dust.

Conclusion

I like our new rising star, I really do. Atom has some neat features built-in and if you’re new to fully customisable editors then you like it for sure, presumably you don’t need to edit big files. Atom is a young editor and it’s impressive what GitHub and all the contributors did so far with the editor. However it’s not as mature as SublimeText and it still needs some time to grow up.

Compared to Sublime Text, IMHO Atom has no chance because of 3 big issues:

• the performance is worse compared to Sublime Text
• the git integration is rubbish, even with 3rd-party packages
• the missing Go-To-Anything feature

The one thing which annoyed and “shocked” me the most was the rubbish git integration. I don’t know how GitHub can call it a git integration and I honestly don’t know how developers are working with this so called “integration” and without the git command on the terminal. It’s sad because git belongs to GitHub’s bread-and-butter lines and this is what they came up with.

There are also a few packages only working properly with US keyboard layouts and you need to tinker around that by installing the keyboard-localization package. I didn’t had any issues with my UK keyboard layout and I never installed the workaround.

The good news are, there’s a replacement for everything else I used in Sublime Text. Some of them are better (e.g. pigments) and some of them are worse.

So call me old-schooled or foolish, but I’m loyal and stay with Sublime Text – even if it’s proprietary and not open-source. I don’t miss anything in Sublime Text and it is definitely more stable and mature. I’m thinking about switching to Atom as soon as the upper topics are fixed – or when I find time to write a proper git package (already having bracket nightmares when I think about JavaScript – ugly little script language).