For most developers, text editors are just as sacred as discussing the proper way to say “gif.” Sublime Text has been the heavy hitter for some time and for good reason. As an avid Sublime user I decided to see where Atom stood since I last looked; the time of early beta stages. What follows is my experience during a period of five days using the Open Source code editor from GitHub told through the perspective of a seasoned Sublime user.
I’d like to begin by addressing a few general points concerning my time with Atom before discussing particular facets. During my brief visit I had a bit of trouble finding syntax highlighting that worked right for dot files and bash. I’m sure if I hunted this down a bit longer I may have been able to solve that dilemma, but again it was only for a short period of time. Image previews for PNG, JPEG, ICO assets were wonderful to view directly in the editor, although I didn’t always need this (see the Homer Simpson car).
When previewing via the sidebar’s file tree, a file selected would remain open if a click didn’t occur thus requiring another action on the user’s part to close the file. As you can see in the screen captures above, Sublime handles this the best.
The first bits you’ll want to address when making the crossover are what I term “creature comforts.” In my case, I had five days to find the one’s I used the most and what follows is a short list; although there are plenty out there like color pickers for example.
- atom-beautify by Glavin001
- autoclose-html by mattberkowitz
- bezier-curve-editor by abe3
- emmet by emmetio
Make Emmet Understand Custom Grammar
I typically write in Handlebars for my static site generator projects and Atom picks these files up as Mustache grammar. Since Emmet will not work correctly in Handlebars files you can get your Emmet’s mojo back with expanding abbreviations by adding the line below to your Keymap:
console.log wasn’t working as I expected. Abbreviations like
Markdown preview was truly amazing, but also a bit touchy at times in terms of performance; especially when opened for a prolonged period of time. The preview results match up perfectly with GitHub’s markdown rendering although it’s a GitHub product so we shouldn’t expect any less.
I find many text editor’s live preview for markdown like Mou never seem to gauge markdown code blocks quite right or even fail to display embedded items like pens from CodePen; something I do quite often as a writer and a feature not many allow for.
Coding started out rough when I tried to find my creature comforts such as splitting panels and closing them. Ultimately I figured out a solution, but the feeling of being severely lost was remnant for a period of time. There are ways to decipher quick key combinations if you go to Atom > Preferences > Settings. I highly suggest visiting this part first if you plan on trying Atom or making the switch from another editor.
Here’s a few useful quick key commands I discovered during my use and found quite helpful with my particular workflow…
- splitting panels :
(cmd+k)then a directional arrow of your choosing
← ↑ ↓ →
- Closing panels :
(cmd + k)then
(cmd + w)
Finally here are some quick key commands you already know in Sublime that work in Atom too!
command + k + b for sidebar
command + shift + p for package manager
command + p for file search
Theme & UI
I was truly pleased by the default themes that are bundled with Atom. The sidebar by default and file tree are super slick and the overall UI for Atom is really polished. The theme combo that follows I really enjoyed, but I didn’t spend enough time trying others; there are many that do exist.
- UI Theme: One Dark
- Syntax Theme: Solarized Dark
If you desire to become a die hard Atom user and addict, you can dive deeper by reading more about customizing at this link https://atom.io/docs/v0.80.0/customizing-atom that contains well done documentation that’s easy to read.
Performance was off with modals that display with file search (
cmd + p) for example. The file search modal was at times sluggish during initial rendering. Tasks such as opening a single recent project with 2 split windows (each window contained on average two opened files) was slightly less than par in terms of speed. On average startup times were roughly 2-3 seconds from a fresh boot; even with Chrome and iTerm idling.
I don’t really need to make much of a case for Sublime except it operates faster (startup times and overall functionality) plus works wonderfully on multiple OS’ (Windows for example). It’s still customizable, easy to work with, works great with emmet plus there are awesome books available such as Wes Bos’ books. Wes is writing great tutorials and tips for Sublime and iTerm users making this another reason to stick with Sublime; a great community of users and teachers. I still desire that Sublime Text make the official documentation for the product more robust and user-friendly. Maybe Sublime Text 3 will bring a new frontier for us.
I’ve been complaining quite a bit on Twitter as well in regards to the stable release of Sublime Text 3, since it’s beta period grows ever so longer each day (Beta Released July 2013). The majority of developers using ST3 shout with rejoice that ST3 works perfectly! I think it’s time to release the hounds and ship it as they say in the boating business.
Sublime does have it’s quirks don’t get me wrong, but the quirks are far less compared to the benefits Sublime lends to developers.
The Editor I Picked
Regardless of what you choose I decided to go back to Sublime. I urge everyone to find the editor you like the most and stick with it. It’s nice that Atom is Open Source and I’m sure it will become even more amazing as time passes; I don’t see it fading away any time soon. I will however keep a close eye on Atom, but I’ve decided to stick it out with Sublime. So in the end when it came down to Atom or Sublime…well…Sublime FTW!