Not long ago, I made the change from Coda to Atom though I never actually talked about the reasons behind this decision. Then, Bjarni sent me the following tweet a few weeks ago:

I’ll talk about the transition from MAMP to Pressmatic in a future post. In this post, I’m going to focus on the reasons and my thoughts on changing from Coda to Atom as it stands right now.

And for those who love a good software holy war, this is not the post fo rit.

From Coda To Atom

First and foremost, I believe that developers should use the tools they find to make them most productive. If you enjoy using Grunt, Vim, Xdebug, and Firefox, then go for it.

Though some will argue, I’m not one to judge. I do, however, think that a person should have good reasons for using the software they choose to use (rather than “just because” or rather than “this is what someone told me to use.”)

That last excuse works okay up to a point, but once you gain enough experience, it’s time to start picking your tools. But I digress.

On Coda

My switch from Coda to Atom was not a short one. In fact, I tried a wide variety of editors before I even settled on Coda. And when I did, I used it for years.

Terminal in Coda 2

Some developers complain about the major releases being few and far between. This was something that never really bothered me that much because incremental updates were frequent.

And, perhaps more importantly, I think the desire for major updates is symptomatic of our current software culture where we’ve begun to expect major releases to happen very quickly.

Generally speaking, Coda is a robust editor. It features:

  • A built-in S/FTP client (with the ability to publish only updated files),
  • A built-in database front-end,
  • Semi-flexible syntax highlighting,
  • Support for plugins,
  • A built-in terminal,
  • A built-in source control client.

For me, Coda began to feel a bit heavier than I’d like. For many of the tasks above, I’d either found alternative applications which did a better, more focused and/or more lightweight regarding the jobs for which they were responsible.

Furthermore, and perhaps most importantly, the set of plugins for WordPress were not frequently updated and didn’t offer updates corresponding to even semi-current versions of WordPress.

Finally, the editor didn’t offer any features to automatically lint JavaScript or comparing server-side code against the PHP Coding Standards let alone the WordPress Coding Standards. In this case, everything has to be done via the terminal.

This isn’t something that’s inherently wrong, but when you’re working to write code as efficiently as possible, those types of things are important; otherwise, you’re interrupting your workflow to get things done.

As my experience with WordPress began to increase as my desire for productivity, the need for something a bit more streamlined increased.

So I started looking at alternatives.


Although I’d tried Atom upon its announcement, it wasn’t anything that compelled me to use it regularly. It seemed interesting, and I found the architecture and the idea behind the app interesting, but it wasn’t going to be something I could fit into my workflow.

From there, I tried just about every other editor that’s available, and all of them had their shortcomings, at least for me, in one way or another. So I returned to Coda for a bit. Fast forward a year (or a little more) and the Atom economy has boomed with all kinds of neat packages, themes, and so on.


The core application has also gotten a lot stronger. I know people complain about its speed, too. This isn’t something I’ve personally bumped up against, and I plan to do a follow-up post about what I use, why I think it might be slow, and some tweaks I’ve found that can improve its performance.

But because I’ve streamlined so much of my workflow into a particular set of tools, I’m able to let Atom focus on being my IDE and arm it with the fundamental themes and packages I need. This allows me to focus on project management and code. I’ve already shared some the things I use it with it, but because of its speed (again, another topic for another time) and the ability to build in things like support for PHP Coding Standards or WordPress Coding Standards and linters, it’s just that much more powerful.

Sure, you can install plenty of things like debuggers, terminals, source control packages, and ultimately make it just as powerful as you want. Or you can keep it as lean as you’d like and use independent tools for those functions. It’s your call.


I don’t know if Atom will be the last editor I ever use. If history is telling, as it usually is, then there’s a significant change I will change editors eventually.

I don’t see it happening anytime soon, though.

Finally, as I previously mentioned, every person needs to make sure they are working with tools that fit their workflow the best and that maximize their productivity. I know plenty of other developers who swear by Vim, Sublime, PHPStorm, and other editors. All have their strengths; all have their weaknesses.

The best thing you can do is evaluate each of them for, say, at least a week and find the one that fits your workflow and your personality the best.