wylie

Comparing Web-based Code Editing Tools

November 13, 2018

Text editors and IDEs are no longer the only place to write code. The notebook metaphor has become a dominant way of writing code for understanding data, online snippet editors are an easy way to try new web technologies and file bug reports, and online environments can support collaboration with other people, which can be used equally by software teams or students. These tools mainly fall into a few categories:

Why do the tools used to teach code look the same as the tools used to analyze data, or to work on a large project? Why do so few online development tools have integrations with language documentation, test running, or version control? What I found surprised me, which is that each of these editing environments is using one of three libraries, and that no other libraries are yet being used at a large scale:

Of these three, the CodeMirror editor is the most widely deployed, though the Monaco editor is quickly growing in popularity. CodeMirror and Ace are small and fast single-document editors. Monaco is the text editor from VSCode, which is a larger library with support for more IDE features like language intelligence and refactorings. Each of these libraries is currently optimized for use on desktop computers, with minimal support for accessibility, although Codemirror 6 will include mobile and accessibility support. While all of these libraries can support plugins, CodeMirror has the largest selection of existing addons, compared to Ace addons. It seems like both CodeMirror and Ace are harder to extend than Monaco, as when Mozilla wanted to use the Brackets editor, an IDE built on CodeMirror, it forked the project, which is now used in the Thimble teaching environment. On the other hand, the Monaco editor was able to be directly embedded by the Theia IDE, which was in turn embedded in Eclipse Che. This suggests that the Monaco editor has a well-designed API, but is less suited for diverse use cases like data science tools.

So what kind of APIs would be needed to support diverse kinds of uses, like better integration with documentation, testing, and version control? Taking inspiration from the good parts of the Monaco API, these features could be split into behaviors and presentation. Tool-makers could control both the behaviors and presentation which their tool would use. This API could be built by a third party, wrapping the libraries in a common API. Having a set of shared presentational and behavioral components for Ace, CodeMirror, and Monaco would be the first step towards a world where tool-makers could tailor their tools to the kinds of users they have.

Conclusion

Web-based coding environments have taken off over the last few years with support from the open source community and large backers like Microsoft, Red Hat, Adobe, and IBM. These tools are all based off a set of three libraries which don’t have have an API that would support the diversity of users that are working with them, including professional teams, students, researchers, and non-technical users. In the future, I expect to see coding environments which are as diverse as the kind of code and users that work with them, and I expect that a common API would accelerate that diversity.