<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">

Adventures in Editors

Text editors are strange when you’re a developer. At first glance, it seems like they should be some of the simplest applications on your machine; but as a developer it also most likely your most used. This, coupled with the fact that “good programmers are lazy” and want to get things done as easily as possible, means text editors have been the focus of a lot of time by a lot of motivated people. This of course, leads to editors that are constantly changing, whether it be updated versions, new features, new plugins, or entirely different editors. This also means that everyone has their own preference, with some being much more enthusiastic about their choice than others. For those that don’t start religions based on pieces of software, your preferences likely change over time, and this is how that happened for me.

My Story

As many who grew up in the Windows world do, my first experience editing code was in Windows Notepad. Notepad is bad. Forgetting syntax highlighting, formatting, regex search, and everything else; Notepad would be immensely more usable if it simply had an undo stack. How is it that in 2018 Microsoft doesn’t ship a default text editor that can undo more than one change? And yes, if you couldn’t tell, I was stupid and lost some work because of this like 10 years ago and still haven’t gotten over it.

Adventures in Editors Image One Kevin Brey

Obviously, I needed an upgrade. The free text editor hotness on Windows at the time was Notepad++ so I gave that a shot. Coming from Notepad, it was everything I ever wanted. I used it to varying degrees, supplementing specific IDEs through high school, first few semesters at college, and my first internship. I followed its release notes, played with plugins, and even contributed an embarrassingly small contribution on GitHub.

Once I started to do a lot of work on Linux for classes and my home server, I was without Notepad++. I briefly tried both Vim and Emacs since after all, that’s what “real programmers” use. After getting through the first level of Vim adventures and deciding I didn’t want to have to worry about learning an editor while learning new programming languages I looked for something more familiar. At the time, the “in” GUI Linux editor was Sublime Text. I was immediately impressed with how much better looking it was and how intuitive things like simultaneous editing and quick navigation were. The JSON settings files, package manager, command pallet, and cross-platform compatibility were all also notable improvements. The downside of Sublime Text was it wasn’t “Free as in beer” and being a poor, starving, college student doing this in his free time I neglected to buy a license and just lived with the nag screens. It was fine.

Adventures in Editors Image Two Kevin Brey

In 2014, GitHub released Atom. It was basically hailed as a more extensible, “free as in speech” and “free as in beer” version of Sublime Text. Having still not paid for Sublime, I was sold. Well I guess not “sold”; it being free and all...anyway, Atom was great. The plugin community took off quickly, partially due to plugins being written in JavaScript which virtually every developer has experience with, and because of that, there were plugins for every kind of development. I noticed a few annoying bugs, like crashing while opening any moderately large text file, and integration with Git was just okay, but it worked for what I used it for and I was content.

After using Atom for AngularJS development for about a year, I see Microsoft announces its new Visual Studio Code editor. Initial reading seems to suggest it’s just a Microsoft branded Atom clone and a multiplatform editor using JavaScript plugins written on a Node.js fork. I rolled my eyes and installed it. I used it for a couple hours to say I tried it and went back Atom, confirming my initial assumptions. I heard a bit about it here and there, but for the most part it sat unused on my machine.

About a year later, I was participating in the Angular Attack hackathon with two other Omni employees and was using Typescript and Angular for the first time. Working side by side with other developers in a pizza shop, you get to see a bit more about how people work than you normally do alone at your desk. I noticed the native Typescript support of VS Code but thought, “oh well, Atom has a plugin for that and it’s almost as good.” Then for some reason I was formatting a large JSON file and Atom crashed. Eh, whatever…things happen. Then I see the integrated diffing tools and shell of VS Code and decide I may have dismissed it too quickly. VS Code became my editor of choice for web development and for everything else shortly after.

Some Data

Out of curiosity, when writing this blog, I looked at a couple sets of editor usage data to see how it compares to my experience. I charted the results of the Stack Overflow Developer Survey question “Most Popular Development Environments,” as well as Google search trends for some of the editors mentioned above.

As of this year, Visual Studio Code was the most popular editor among developers; however, that isn’t the entire picture. Unfortunately, The Stack Overflow survey has too few data points to show the full story, but the popularity of Notepad++, followed by the rise of Sublime, then Atom, then VS Code is clear. The data is also a bit skewed by the change in question and answer options from year to year.  One interesting point made in the full survey results from 2018 is that while Visual Studio Code is the most popular overall in 2018, Vim is still the most popular among sysadmins.

Adventures in Editors Image Three Kevin Brey

The other data I looked at was Google Trends. This graph seems to mimic the vague trend I experienced, with VS Code quickly taking a lot of interest away from Sublime and Atom. The obvious problem with looking at Google Trends however, is that it corresponds to web searches and not necessarily number of users or usage time. Also, certain topics can’t be miscategorized and inflate numbers for something unrelated. This is apparent with Atom, since it was initially released in February of 2014; but, according to Google, had a significant amount of traffic well before that. So, it clearly is getting some help from search results not related to text editors.

Adventures in Editors Image Four Kevin Brey

Conclusion

In the end, the take away shouldn’t be that Visual Studio Code is better than Atom or Sublime; but rather, it is what works the best for me and my workflow right now. Each of these editors has built on the strengths of those that came before it and has introduced concepts that will live on long after the editor fades in popularity. Sublime popularized cross-platform editors, along with the command palette and simultaneous editing. Atom gave us JS based plugins and Electron, famously used by Slack, Discord, and many other memory hungry cross platform apps. VS Code is essentially just a refinement of these concepts that works well. Sometime soon, something else will come out that builds on lessons learned from VS Code and fixes some problem in my workflow that I didn’t know I had and when I get over my resistance to change, I will probably switch to that.Adventures in Editors Image Five Kevin Brey

 

Share:
Kevin Brey

About Author Kevin Brey

Kevin Brey is a Software Engineer at Omni. He is a full stack developer, experienced in AngularJS, Typescript, C#, and Docker. Kevin graduated from the University of Wisconsin–Platteville with a B.S. in Software Engineering. In his free time, he enjoys contributing to open-source software and tinkering with embedded IoT systems as well as less constructive activities such as playing disc golf, ultimate Frisbee, paintball, fantasy football, and classic video games.



Disclaimer:

Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.