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:
Interested to hear why you moved away from MAMP to @pressmaticwp and are you still using coda @tommcfarlin
— Bjarni Wark (@Bjarni) July 26, 2016
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.
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.
Atom
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.
Conclusion
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.
Hey Tom,
Hehe, I swear, I’m not here to start a software holy war!
I want to point out, though, that you seem to be missing a very important distinction. I never made that distinction myself in the past, and I had to recognize that this has pretty far-reaching consequences.
I have, for a long time, used Sublime Text exclusively as my editor of choice. I was very happy using it, and could not imagine what else I could want from my editor (Atom is pretty much a web-version of Sublime Text).
After getting more and more recommendations, I cracked at one point and tried PHPStorm. At first, it was frustrating. The editing experience was not quite as snappy as in Sublime Text, colors and fonts were horrible, it was consuming lots of CPU and memory, …
But I kept at it, and after a while, it became apparent what it was that I misunderstood.
There it is: PHPStorm is not an editor, like the rest of the bunch, Sublime Text and Atom included. It is an IDE, an Integrated Development Environment.
The actual editor in PHPStorm is really good in and of itself (and colors and fonts can be adapted to make them less painful ;) ), but it is not where the real value of such an IDE lies. PHPStorm does not manipulate letters and words, it manipulates classes, interfaces, tests, manifests, databases, version control systems, etc… as entities it understands and can relate to each other. As an example, you rename a class, and its references get renamed across all of your 1000 source files, including imports, typehints and even comments.
So, without exaggeration, I can honestly tell you that “working in a text editor” was holding me back without me realizing it, and using PHPStorm has doubled or even tripled both my productivity and my code quality. Its benefits go so far that most of the time I don’t need any external code quality tools, as PHPStorm just does it all in near real-time. And the better your code quality is (and OOP is indeed an advantage there), the more performant the autocompletion gets, up to the point where you can write entire class files with a few dozen keystrokes.
I don’t write this to convince you to change (again), I just want to make the distinction clear for everyone between a text editor and an IDE. The best text editor in the world is just a very simplistic toy compared to a real IDE. Yes, using an IDE comes with a lot more upfront investment. But, once you’ve managed to get accustomed, you’ll feel like walking in the dark when using a normal text editor again…
I’m still using Sublime Text regularly, btw. But I use it when I want to quickly edit some text. When working on anything remotely complex, there’s no way around PHPStorm for me.
I’ve had a very similar experience Alain. I was a big time Sublime Text user. The day I decided to switch over to PhpStorm (and it took me quite some time) is the day I started to understand the difference between IDE and text editor.
With that being said, I also use Sublime and Atom for quick edits on files that aren’t part of a project.
I did give Atom a try when it was released but was disappointed by its capacities. Compared to Sublime it was extremely limited.
But then I tried it again a couple of months ago and, just like for you Tom, my perspective on it changed completely. Even though I spend most of my time in PhpStorm, I did setup Atom with a handful of nice plugins and I’m happy to use it once in a while for quick edits.
The interface is nice (I actually changed my PhpStorm theme after using Atom because the one built-in Atom is just so good looking), and the amount of plugins available it now very acceptable.
One thing, though. As you brought up in your article, the performance is what make me prefer Sublime over Atom, still. I’m really curious to see what tricks you found to speed it up. While it is not enormous, I find Atom definitely slower than Sublime.
I’m surprised because you strike me as that kind of person! /s
:)
I’ll take this distinction. You’re right. I’m using IDE and editor interchangeably in the post and I shouldn’t be.
One thing that I should point out though is that I have experience with other IDEs (Eclipse, Aptana, NetBeans, PHPStorm, Visual Studio, etc.) and with other editors.
I’ve deliberately settled on Atom right now for a number of reasons (the least of which aren’t about the packages and third-party tools I’ve opted to use).
This is true. This is a definitive luxury of an IDE (versus an editor) and it’s a tradeoff. Is it one that I like? Eh, not really. But it’s one I’m willing to live with for now given the nature of the size of my team and projects on which I work.
I believe it — at least in the former case. The latter case is one of those where, though I do grant IDEs can do things that improve certain aspects of code, I think advanced packages and wiring the editor up to things like PHPCS and debuggers and the terminal (or installing packages that run in the context of the editor) can help, too.
No worries – and I appreciate it! :)
I am always looking for a “better” text editor or IDE. I am using Sublime Text for my personal projects and PHPStorm at work. I think Alain makes some very good points about PHPStorm. The biggest problem I have is the same problem I had with Coda – that I would find individual applications that did a piece of what Coda did but much better. And then it seemed like a waste to have the built-in functionality if I wasn’t using it. For example, iTerm 2 is amazing for terminal tasks and Navicat is a great tool for working with MySQL.
I find the terminal in PHPStorm to be decent and the SQL tool to be fairly lacking and it makes the application seem so much heavier to me since I am not using them. But the functions it offers are wonderful and I haven’t played around with its WordPress support. I intend to explore that more.
One of the things that bugged me about Atom is that it seemed to have some graphical glitches from time-to-time and, yes, the speed. I also had a really cool plug-in but then it started popping up alerts all over the place and I didn’t have time to troubleshoot. So, at the moment, I am using Sublime Text. But I plan to try PHPStorm more with WordPress projects and I might dig into the packages Tom uses in Atom to see what that experience is like.
In PHPStorm, all of the components like the Terminal, or the Database Integration are just plugins that you can disable if you don’t use them, to save memory and CPU.
Agreed – each IDE has it’s tradeoffs, though I will say if you’re purely comparing an IDE to an IDE, I think PHPStorm is more advanced than Coda.
This is where I start to prefer third-party applications that modules that exist in the context of an IDE. For example, I like a different debugger, database tool, and so on more so than what many editors or IDEs provide.
I’ve not really experienced any graphical glitches. I guess there have been some speed issues but not generally speaking and there are some minor tweaks I’ve made to try to resolve anything that was bugging me.
Eventually, I plan to write a post to address ‘em but I have a backlog of other posts to discuss, too :).
I’ve too belive I’m the “use the tool that works for you” mantra, but don’t be blind to possibly better tools… What Julien and Alain say above goes on an increasingly heavy pile teetering me towards giving PHPStorm yet another, and more dedicated, look.
For a few years now I’ve used ST and find it amazing. It certainly improves my productivity tover Coda, which is what I used before. I remember it taking a few false starts with ST and quite a bit of configuration before I felt “ah, yeah… This is better!”. When I first started using ST I felt Coda formatted code better, and ST didn’t really add anything but over time I found better ways to work with ST.
I’ve looked at Atom, but I have yet to see any reason to switch from ST. It really just seems very similar, without any key differences. Actually the only one I noticed was that I didn’t readily see a way to configure a project workspace (defined folders and ignored folders) the way I can with a ST project file.
I’ve played with PHPStorm a few times over the years and the hurdle has just been too high. I wish there was someone like you, Tom, guiding the way :) as you have with so many dev tools here. Often taking the tool I’ve been playing with, and getting me from “hmm this is interesting, but a PITA and more trouble than it’s worth” to “OMG now I get it, it’s totally useful and not so cumbersome.”
I have one more question for you Tom. I did spend some time in Atom trying to achieve something to no avail.
I use multiple laptops when I work, and I need to keep my IDE/editor in sync. Is it something that you’re doing too, and if so, how do you approach that?
I did find a plugin for syncing settings, but it required a manual intervention that I know I am going to forget from time to time.
See this post and the comments and it should provide exactly what you need :).