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:

  • Hosted externally, no installation needed
    • Glitch, Codepen, repl.it, Khan Academy
    • Range from simple snippet editors to full IDEs
    • This is the most common choice for educational tools
    • Hosted tools are best able to support collaboration between developers, like Glitch
  • Web app which requires installation
  • Desktop GUI using a web browser
    • VSCode, Atom
    • New tools are using web views to handle text editing

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:

  • Ace (since 2010)
    • Used in Cloud9, RStudio, Khan Academy
    • Supports syntax highlighting, themes, and extensions
  • CodeMirror (since 2011)
    • Used in Chrome, Firefox, and Safari dev tools, Glitch, Jupyter Notebooks
    • Supports syntax highlighting, themes, and extensions
  • Monaco (since 2016)
    • Used in VSCode, repl.it, Theia IDE
    • Supports syntax highlighting, themes, and extensions
    • Built-in support for language intelligence and IDE features with extensibility

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.


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 common APIs that would let them support the diversity of users that are working with web-based coding environments, including professional teams, students, researchers, and non-technical users. In the future, I expect to see these tools be more tailored to the kind of code and the individual needs of the user, which will need a common set of APIs.

Advanced Tips for Using the Google Maps API

May 10, 2017

I wrote a blog post for Compass about best practices for using the Google Maps API, including where it’s a good idea to add functionality using the API, and where it’s a good idea to keep your code separate.

The code samples are oriented towards teams using angular.js, but are showing patterns that are easy to translate to other frameworks.

Read the post on the Compass blog

Setting up a deploy system for Python apps on Ubuntu using Supervisor, Upstart and git

August 21, 2013

In the past, I’ve always deployed web apps and side projects to Heroku. But after being bitten by it one too many times, I decided to get a server on DigitalOcean and do it myself. It was surprisingly easy.


First, I created a user called www-data and gave it a home directory of /var/www/. Inside there, I created this directory structure:


The .virtualenvs folder is used by virtualenvwrapper to manage my environments.

myproject.git is a bare repository that I set up by following these instructions for git deployment from Jeff Hoefs. You can customize the post-receive hook, for example to restart your web process. But first let’s get our process daemonized, so it’ll keep running if it crashes or the server restarts.


Supervisord is a Python-based process management system. It’s similar to Upstart, which is more generic. In fact, I use Upstart to make sure Supervisord starts on boot.

Upstart now ships with Ubuntu, so you just need to install Supervisord. You can install a pre-built package, or use easy_install like I did. I prefer easy_install, because the code generated by the package is hard to modify.

$ easy_install supervisor

Here’s an example program specified in /etc/supervisord.conf. By default, supervisord will start all your programs when it launches.

user = www-data
directory = /var/www/myproject
command = /var/www/.virtualenvs/myproject/bin/python main.py
numprocs = 1
stdout_logfile = /var/www/bus.log
redirect_stderr = true

I also created a small Upstart script called supervisor (without the d). This lives in /etc/init/supervisor.conf

description "supervisor"
start on runlevel [2345]
stop on runlevel [!2345]

exec /usr/local/bin/supervisord --nodaemon -c /etc/supervisord.conf

That leads us to the last part, which is the modified post-receive hook which will run your newly pushed code:

GIT_WORK_TREE=/var/www/myproject git checkout -f
supervisorctl restart myproject

Running it

Start running your supervisor as a service, if it’s not running:

$ start supervisor

Then check the status of your project:

$ supervisorctl status myproject

You can also use supervisorctl to start, stop, or restart your web process manually.

And that’s it! My app is more reliable now, and deploying is still just a git push.

iOS Camera GUI PSD

August 23, 2012

While waiting for Backspaces to be reviewed by Apple, we decided to build and open source a component popularized by Instagram: live camera filters. If you’re curious, you can read about some of the motivation behind that decision in Dmitri’s post.

Open source projects aren’t usually praised for good design, and our initial versions looked like it. But I knew that we were going to launch this component very publicly, and decided to make some improvements.

As it turns out, I couldn’t find any resources online to make a mockup of the iOS camera. Even the excellent Teehan & Lax resources didn’t have a camera!

In the spirit of open source, I’ve created my own camera PSDs and released them into the public domain.

Download the files here

Included are the default iOS camera and the Instagram-like design for our open source camera, in retina and regular resolutions:

Default iOS camera Open source iOS camera]

Why Hackathons?

May 23, 2012

You should go to a hackathon. You’ll find out quickly if it’s something you enjoy. But if you do, I’d like to help make your experience awesome.

A typical hackathon looks like this: Form a team, come up with an idea, work all night, and finally, present your project. Most last 24 hours. Your goal is to build the best thing you possibly can, starting at the same level as everyone else.

My first hackathon was a year ago. I had no idea what I was doing, but I showed up, met some people, and built something fun. I had a similar experience this past weekend. In between, there were a lot of hackathons, but none as exciting.

What makes these two experience stand out from all the others?

First, the team. The ideal team has a person covering every role. I think four people is best. This past weekend those four people were two developers and two designers. At my first hackathon it was two developers, one person figuring out gameplay, and one person doing sound. The trick is to find a way to work in parallel. You will fail if you don’t.

Second, the idea. Somehow you should find an idea that you’re all excited about. With these two hackathons, we spent a couple hours talking over the possibilities before we found one that we couldn’t stop talking about. Then we spent more time planning out all the features that we needed to build, that would be nice to have, and that we definitely shouldn’t build.

Fake everything except what you need. Every unsuccesful hack I’ve made failed because we tried to do too much. No, don’t implement that registration system. No, don’t implement a RESTful API. No, don’t build your app with tools you’ve never used before. Your audience won’t care about those things, so don’t spend time on them.

I always focus on what a teammate once described as “the happy path.” What path would someone take to solve their problem? Build that, and the demo is easy. Last weekend we used the example of Ken, a potential user we talked to while coming up with the idea. Every part of the app makes Ken’s life easier, so we just had to explain how.

Everyone has a different reason they go to hackathons. Some go for competition, or to build something cool. I go for the people. It’s an opportunity to spend time really getting to know someone, to figure out what motivates them. It’s a community of people that inspires me to be better. I’m still friends with the team from that first hackathon, who have since started a company and moved in together. A hackathon is an opportunity, and it’s up to you to make the most of it.

See the discussion on HN