Introduction
The Khan Academy coding environment was launched in the summer of 2012. It's an interactive Javascript environment that uses Processing.js to draw to a canvas. The environment is constantly updating, so the canvas updates as you write your code. It also uses JSLint and JSHint to detect errors and bad style in your code.
Whilst the environment was designed to teach beginners Javascript, many users have built some pretty advanced games and images with it. I have now created over 1000 programs in the environment. This includes many programs I made for the partnerships with NASA and Pixar.
One of the first things users learn to draw is Winston, an icon of the KA environment.
The good
No set-up. If you want to quickly test an idea, just start typing JS and see the results. You don't have to create any HTML or any files or anything. I often use it if I want to test out a bit of JS that requires more than a line or two (which could be done in the browser console).
Visual. As well as being quick to start up, the environment also makes it easy to create visuals. I have often used the environment to prototype an idea that I might write in another language later. For example, before writing code to analyse arrangement of boxes on pallets for a logistics company, I used the KA environment to see what my code did step by step, creating images along the way.
Number scrubbers. You can click and drag any number in the code to make it bigger or smaller. Combined with the immediate visual update, this makes it easy to quickly tweak values, for example shifting elements when designing a layout.
JSHint and JSLint. The environment constantly tells you if it's found an error (these days it waits until you've stopped typing). While these aren't always useful (see below), they can quickly spot a typo and make you very good at remembering semicolons. Some of the hints are not things I would have thoughts of (like avoiding defining functions inside a loop).
The bad
No access to the DOM. A lot of the programs I've made, especially for Pixar, have needed a user interface with tabs, sliders, buttons etc.. So I've had to create all these elements from scratch, including all the event handling. I think the biggest thing I've learnt from the Pixar work has been how to build graphical interfaces at a low level.
Inability to import code. This biggest drawback when creating multiple programs. It means all the code for creating graphical interfaces had to be copied and pasted into each new program. If I changed how something worked or looked, I would have to update all the individual programs manually. It also meant that I had to, for example, write my own code for generating Voronoi diagrams (or at least update someone else's code to work in the KA environment.
Slow. When you update part of the code, your program updates, but without starting your code from scratch, so it needs to know the current state of all the variables. It also runs all the code through JSHint and JSLint, which makes it slower than normal JS.
On top of that, because the code is always running as you type, it needs to avoid getting stuck in an infinite loop. It's surprisingly easy to accidentally write an infinite loop, when in the middle of editing the conditions in a for or while loop. To avoid crashing the browser, the environment times how long each block of code is taking to run. If it takes too long, the it throws an error. So you have to make sure all parts of your code run always below the threshold time.
Unhelpful error messages. While the error messages are often helpful, as programs get more complex, particularly when creating objects, they can become obtuse. There was a time, when an error might simply be "undefined". Even now, you can often get a message: "Cannot read property x of undefined" with no line number to help you out. In these cases I find the only real solution is to copy the code offline where you can use the developer tools to find the offending line.
Overly prescriptive JSHint. I don't really mind this, but some people don't like how it requires semicolons. It also doesn't let you define named functions, i.e. with function myFunction() {}.
The ugly
Initially I didn't think to include these two aspects of the environment, as my focus was more on what it's like to code in the environment. But I think I they are an important part of the environment and probably have caused more discussion and heartache than anything else.
Voting. When the environment was first launched there was no voting (back when KA shared a couple of my programs on their Facebook page alas). Then voting was introduced, and people could vote programs up or down. Down-voting was later removed because it was discouraging, particularly when beginners would have their programs down-voted for being simple or badly written.
The current system is still problematic as voting is often not related to how good a program is, but on who made it, or the content of the program (for example, simple programs just showing a religious quote would often attract votes until such program were banned). Overall, voting is probably a good thing as it does provide motivation for a lot of people (I'm not immune to its lure). On the other hand, many students focus on it too much.
The Hot List. Hand in hand with voting is the Hot List, a list of the most voted programs from the last few days. The point of the Hot List is so users can discover other people's programs and as motivation to make quality programs. Unfortunately, it is the only significant way for people to get their programs noticed and so there is a lot of competition. It also means that if someone can get a few votes from their friends to get on the Hot List, they can then accumulate way more votes than they otherwise would.
Conclusions
The KA coding environment is great for quickly prototyping ideas and making simple visualisations. It's less good if you want to create more complex programs, or a series of related programs. But then that wasn't what it was designed for. It was designed to teach kids (and grown ups) to code and we co-opted it to make interactive programs for lessons. When the programs get too big it's better to make them offline, where they won't be constantly updating, but will be faster and have better debugging tools.