Coding qooxdoo on the Cloud9 IDE

Long time no write! I was finishing a big project that has been on my back the last couple of years. But now I hope to have some spare time again for coding… and here we go.

The Cloud9 IDE (c9) has caught my eyes right some time ago. I think it is a brilliant idea to have a full development environment for web applications in the cloud, so I can log in whereever I am, on whatever machine I happen to work with, and  continue coding  without having to install and maintain an IDE plus all of the dependencies. To be sure, C9 cannot offer the same feature set as, for example, Eclipse, but then, Eclipse has given me so many headaches (speed, memory problems, incompatibilities bla bla bla), that I am very happy to let go. Also, it has to be said that C9 still has a LOT of problems. Be prepared to reload the application when things seem stuck, which happens quite a bit and this can be frustrating. But I happily accept that as long as things work more or less and I can work decently, and I am sure they’ll manage to fix the remaining problems. You can sync with your git repositories very easily, which makes it an ideal editor to work on your projects hosted on git (bitbucket is also supported). You can run and debug your node programs inside the virtual machine C9 gives you,  access the VM from outside during development, and even deploy the finished app to a production server of your choice. Very nice. No more need to run and maintain a development server yourself, which has always been a nuisance for me. And you can work on your code on a weak netbook with a meager internet connection.

I am a big fan of  qooxdoo (qx) and have written my main project with it. Qx is a very well written JavaScript framework with a very active community and a dedicated developer team that provides excellent support. Qooxdoo has received relatively little attention compared to its competitors such as jQuery, dojo or YUI. In part, this is due to the lack of marketing. Qx is sponsored by a big internet firm (1&1) and used for their internal needs, so there is no real need of gaining market share (and widgets 1&1 doesn’t need won’t be developed, unfortunately). Another reason that works as a disincentive to newcomers is that the library cannot be just plugged in into website in order to put nice shiny widgets on your page, like for example dojo allows you to do. You need to have access to a python interpreter, in order to call a “generator”. The purpose of this generator is to “compile” your code into a bundle (the “built” code that can be deployed) or – for purposes of development – creates a code which loads in the required files in the right order. This has obvious advantages. You don’t have to worry about dependencies, and you’ll get optimized, compressed files that contain only the necessary code. The downside is, as noted, that you have to do a little more work that you’re used to compared to the other libraries, some of which  don’t even have to be hosted on your server (if you include them from a CDN).

Because of the Python dependecy, until recently, it has been relatively cumbersome to bring qooxdoo and Cloud9 together. It wasn’t possible to do the “compile” step inside C9, so I had to sync to git, sync to my Mac, do the compilation, sync back to git, and back to C9. Not ideal. That is why I was really pleased to hear that my C9 VM now supports python! Unfortunately, you have to buy a subscription ($12/month) to be able to call python scripts from the command line (necessary for the qooxdoo tools). [Update: it seems like it works in the free plan, too. Hooray!]

Today I finally found some time to test this out and am happy to report that the qooxdoo development workflow seems to work in C9 as well. Since my time is short,  I just document the basic steps.

1. Create a C9 project

Either create from scratch or by cloning a project from git.

2. Include qooxdoo as a submodule

For example, to use the master branch:

git submodule add qooxdoo

(If nothing happens, reload the page, it should have created the submodule nonetheless)

3. Install the necessary npm module(s)

We’ll need a server to send the static files to the client. For our purposes, a connect server will be sufficient. When creating more sophisticated backends for the qooxdoo application, you’ll probably want to use express or even a full backend solution. In the command line on the bottom, execute

npm install connect

4. Create a qooxdoo application

In the command bar on the bottom, type

python ./qooxdoo/tool/bin/create-application -n testapp

5. Compile the qooxdoo app

Go into the newly created directory and run the generator:

cd testapp
python ./ --no-progress-indicator build

The console output of the script isn’t very pretty, because the C9 console doesn’t support the Backspace character, so that the spinning animation doesn’t work. [Update: you can avoid this problem using the –no-progress-indicator, see Daniels comment below].

You can also tell that the VM isn’t very powerful, because compiling even the small sample application takes quite some time (6 minutes). I’ll have to see if that will end up as a fatal bottleneck for development. [Update: I was told that C9 plans to have more powerful VMs as part of the paid plans.]

6. Setup the server

We now write a minimal server. On the top level (although it doesn’t really matter where it is placed), create a file “server.js” with the following content:

var connect = require("connect");
var app = connect().use(connect.static('./testapp'));
app.listen( process.env.PORT, process.env.IP);
console.log("Server running...");

Save the file, and, while having it open, start the server by clicking on “Run” (the button with the green arrow. If you see “Debug” with a red arrow, uncheck “Run in debug mode” in the associated menu).

That was easy, wasn’t it, compared with configuring an Apache server?

7. Access your qooxdoo application

You can of course directly call your newly generated application by using access to the workspace that C9 allows by opening (replace USER with your username and PROJECT with the project’s name):

However, this way you can only debug a static qooxdoo application without being able to integrate a data backend. Instead, you want to use the connect server you have put in place to serve the static content. When you started  the server, you should have seen a message saying “Tip: you can access long running processes, like a server, at ‘’.” To open the qooxdoo application this way, you need to open this path:

8. [Update] Accessing the development version (“source”)

After finishing the first version of this post, I found out that the above code really only works with the fully compiled application (“build” version). This is because the development (“source”) version of a qooxdoo app needs to access the qooxdoo source tree, which is outside of the testapp directory and thus not available to the Connect server. In order to start the source version, line 2 in the server script needs to be

var app = connect().use(connect.static(__dirname));

and the corresponding URL would be

You can also start your “build” version with this setup, by replacing “…/source/…” with “…/build/…”. Please note, however, that you shouldn’t do this for a production setup, since the http server should be locked into a subfolder without access to the code that is accessible through the root folder.

That’s it. Now you can code away on your new qooxdoo project. Of course, the really interesting stuff starts when you integrate a nodejs-based data backend, using realtime connectivity, such as that provided by More on this in a later post.


5 thoughts on “Coding qooxdoo on the Cloud9 IDE

  1. Very nice tutorial! BTW, you can use the “–no-progress-indicator” option for the qooxdoo generator to get prettier console output.

    1. Thanks Daniel, I didn’t know that. I’ll update the tutorial because the console output is otherwise quite unreadable.

  2. Re step #5: I’ve been playing around with the various compile jobs a bit and found that once the qooxdoo generator’s cache is filled, compilation time decreases dramatically (as expected). A bigger problem is that (re)loading the source version of the app with its many .js files takes forever. It looks like the server can’t handle many simultaneous requests. The source-hybrid version loads much faster but still takes almost a minute.

  3. My prefered setup/process: symlink the source version under tomcat’s webapps dir, and debug on source-hybdrid. IME it’s acceptably fast for debugging, and lets you test with whatever backend you use as well (provided you run it off the same tomcat instance).

    It too has bugged me forever why qooxdoo is so little known, when compared to other frameworks, given its feature richness and quality. Even if 1&1 doesn’t care about marketing, I’d definitely like to see some more buzz around qooxdoo – it’s extremely difficult to persuade people to do projects with qooxdoo as long as it isn’t better known, even if it’s better suited for real applications than anything else out there.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s