Why do (all) code editors look the same?
Let’s get this started with a quiz — attention please *DRUMROLL*:
Which editor do you see in the following picture?
To help you with your answer, here is a list of code editors (sorted alphabetically):
Personally, I could imagine all the listed editors to match the wire picture. (Yes, vim and emacs doesn’t come with a sidebar by default. But otherwise they could match the picture as well.) If you look at the images in the editor comparison here, you will get the same feeling: the code editors come with an optional sidebar, the coding area takes up the rest of the space and the editors are aligned in columns. Looking up the date of birth for vi and emacs, both were introduced in the mid ‘70. That means, the basic shape of most code editors out there has not changed over the last 40 years. 40 years is a long time, roughly two generations without any signification change.
There must be a reason to it, right?
Same by evolution
What’s the reason for all code editors end up with the same basic shape? I tried to find an answer to this, but I failed. So I am left alone with a guess: the younger editors copied the basic behavior from the ancestors — a generalization of Darwin’s evolution theory for code editors if you want ;).
Both vim and emacs origin from the terminal ages, where there was no GUI but only plain text. Imagine you design a code editor that can only use text. Well, the most obvious idea is to display all the text in the console. Want to edit multiple files side by side? Well, split the console space in half and keep going. This idea is very simple and powerful. Also it maximizes the used space on your terminal — every pixel is used to show file content. Sounds convincing and practical. So every editor afterwards took over the same design and added a bunch of cool new features (auto completion, linting support, faster UI, language integration…) to set them apart from the other editors on the market already.
In terms of answering the question raised by this blog post, it is good enough to stop now. The question is answered. But there is still no good answer “why” they all look the same. Just because “the old folks” did it this way, that doesn’t mean there isn’t a better way to do it, right?
Should we stop evolving editors here?
Short answer: No, I think code editors can be more useful and supportive when developing code. Developing code is made up of three steps for me:
- Understanding existing code
- Brainstorm and discuss about possible solutions to your problem
- Implementing the solution (which also includes debugging, writing tests, documentation, …)
In my opinion, most features added to editors over the last 40 years fall into the last section (like auto-completion, refactoring tools, integrated debugger). But depending on which source you pick, the first two tasks (which I entitle “research”) make up of 70% of the time spend by developers. Here are a few examples what this “research” include: browsing the source code, try to understand how things are connected, build a mental model how things work, figure out the constraints you work in and then come up with a possible solution. These things take a lot of time.
In a sense coding is similar to writing an essay: you need a set of tools to write down your answer (your favorite pen, a curved ruler maybe, sheets of paper) but before you use them, you need to look up background material and organize your thoughts for the essay. The writing tools provided by editors these days are great (scratch that: awesome), but I think the support for the other part of the work could be better.
How “code editing” works in real life
Let’s stick with the picture of writing an essay for a little longer. Laying out the code editors side by side is not very natural. Imagine a library in your town has the best books on your essay’s topic, the books are not available on the internet, so you pack your stuff and go to the library (which might look like the title picture). The library is old school, so no electronic equipment is allowed and you sit down on a nice desk, equipped with books, papers, pencil and sheet of papers to write down your essay. Let’s say the desk corresponds to your editor view. How would you place your material on the desk? I doubt you would put all these material on two stacks, aligned perfectly and then switch between them (that’s roughly what code editors let you do). Instead, you would lay out your support material around you and have a few sheets of paper floating right in front of you. If you need some more information, you grab for a book and put it over your current handwritten notes, try to understand your current problem, get the idea, move the book a little bit away and continue writing on your sheets.
Actually this workflow is great. You can go back to your editing “context” (when you put the book away and start writing again) very easily and everything is still in the same state you have left it. You also make use of your local brain memory — you remember where you have put the book before, so grabbing it again to continue work is easy. And as you keep the book opened, you can resume the research from the point you left easily as well. Because the equipment you work with is “physical”, you can also overlay them: maybe there is one important drawing in the book that you need to look at, so you have it opened in front of you all the time, but you can still cover the rest of the books with other materials.
Back to code editing
Now imagine your code editor is designed around the workflow just imagined in the library. What would it look like? Maybe like this:
You see a lot of smaller editors, the main part in the middle and a lot of views supporting your current work. Because the views are floating around, it’s also possible to visualize how they are related (as indicated by the dots): e.g. you are working on a piece of code that needs to call a server function. So you place the server code on the left, such that you can see what the call pattern looks like. If you need space, just close the panel on the top left, the connection is still visible in the code editor and therefore opening up the corresponding server code is just a click away.
This has been thought through before
While working on this blog Kevin Dangoor pointed out Code Bubbles, which exactly follows the ideas of floating editor panels mentioned before (guess what, they call them bubbles). Checkout their webpage or have a look at the demonstration here:
The video is definitely mind blowing.
Own prototype: Hello vEdit
Before writing this blog post (and get to know about CodeBubbles…), I wanted to ensure the new editor idea actually makes sense, so I build a prototype, which I call vEdit.
The editor has only very limited feature support. Creating a code editor from scratch again turns out to be a huge pile of work, so I plan to reuse code from another code editor (like Atom, Brackets or Zed) as a foundation and then put the new editor view on top. If you are very brave, you can checkout the code on GitHub. Here is a video if vEdit editing vEdit:
The feature set is small, but the experience looks promising. Moving the panels around give a feeling of “touching” the code (you can easily move the panels by pressing Cmd while moving the mouse over the panel), forking the current panel using Ctrl+F is a game changer, as you don’t have to scroll away from your current code location when looking up something at a different place in the same file. Your current coding location stays fixed and therefore there is no mental context switch/scrolling back again, which turns out to be very relaxing. Closing a panel is as simple as pressing the Esc key.
Wrapping up
I think there is huge potential to make coding editors more supportive (and therefore productive) in the tasks developer spend most of their time on. There is more on my mind, on how this can be achieved - mostly drawn from my experience when working on large code bases (like the Google source tree or Mozilla Firefox) and the missing support form tools I experienced during that time. But that is source for a blog post to follow. If you have opinions about this post, please get in touch with me (you find me on Twitter and G+).
Thanks for reading!
PS: And thanks to Kevin Dangoor for reading a first draft of this post and providing valuable feedback!
