No hikes this weekend, it’s all node.js all the time. Getting my presentation ready for code camp next weekend. As part of that process, I decided to check out Cloud9 again. I last looked at their online IDE around six month ago, and wasn’t too impressed with it. It felt awkward and left a lot to be desired. I can see myself using their latest version, if for no other reason than being able to write code on something like an Asus Transformer Prime. I cannot, however, justify spending $15 / month for an IDE just to have private repositories without a hosting solution and / or much better IDE features that are not available elsewhere.
Cloud9: The good parts
There are some very nice parts of the Cloud9 environment. One of my favorite part is not having to keep switching between different applications to edit / run / view my application. Perhaps I was just spoiled with Visual Studio, but the integrated part of a good IDE can really improve your efficiency by reducing context switching.
Another very nice feature is GitHub integration. I just started getting into working on GitHub, but Cloud9 pulled a list of my github projects and gave me the option to clone them into Cloud9 for editing. Pushing the changes back to GitHub is as simple as running the commit and push commands in the integrated console.
Integrated Console
What needs work
Based on my still limited experience with node.js, it seems the preferred way of storing sensitive information that you don’t want in your public repo is to use environment variables. From what I could find, Cloud9 still doesn’t support them. So what are my options? Store my mongo / cloud connection string in a plain text file and not commit that back to GitHub? That would work on a local test, but anyone with a Cloud9 account can view your files as you edit them real-time. So as soon as you put in your test connection information, if someone else is looking for that, they will be able to find it. Maybe Public repositories are one thing, I can setup my git ignore file to prevent any sensitive files from being committed, but a public working copy of the project you’re testing is something else altogether. Maybe I’m just being paranoid…
This isn’t a criticism of Cloud9 alone, but no one has a great Javascript editor yet. The static analysis tools are lacking as well as the refactoring and code navigation tools. Surprisingly enough, Visual Studio with Resharper has the best Javascript editing capabilities of any editor I have used. Code completion which mostly works, go to definition which mostly works, and find references which mostly works. It’s still not great, but it’s a start. Cloud9 has some static analysis built in. They can tell me when a local variable is not being used, missing semi-colons, and they throw warnings on the legitimate use of some reserved words, but that is about it. Their refactor (rename) tool doesn’t seem to work at all.
Must be using jslint
In addition to that, you’re also limited to the version of node / npm that they happen to be using. This is true with most PaaS providers, so it’s another scnario where you have to weigh the pros and cons.
I really want to like their solution and I will likely continue to play with it to see how it evolves, but it’s definitely limited when compared to a traditional editor / console combination.