Tool Chain: The Next Step

qooxdoo’s tool chain, the set of command line tools most prominently exposed through the Generator (what you invoke with “generate.py”), is about 8 years old in its current conception. When it was started it was an excellent way of providing some niffty tooling to the qooxdoo application developer, like automatic dependency analysis, code selection, optimization and compression. Things that weren’t easily found elsewhere, or were even novel at that time.

JavaScript is taking over the world

But things have changed. Chrome happened, and with it V8, and then after a while, Node. Node brought a general purpose, V8-based, cross-platform JavaScript runtime that opened the landscape for generic, server-side and command-line based JS development outside the browser, and doing so with a performance that easily blew away other dynamic languages. Then came NPM and the whole thing exploded, bringing us where we are.

Today we have a deep and broad ecosystem of Node modules which is growing almost daily both in depth and richness. Part of this storm is the proliferation of JS-based build tools, for JS projects, implemented in JS, with JS plug-ins, customizable through JS. It has become a JavaScript wonderland for tool smiths.

Retain the good, embrace the new

This evolution brought us to question our own approach since some while. We followed the development of Node/NPM with enthusiasm, seeing it mature in a very short time in some aspects, and are now at the point where we want to jump boat and embrace this new wold in our tooling. We want to introduce a new infrastructure which is JavaScript-based and provides us with a platform to interact and integrate with the functionality that we already have.

So we have started to introduce a Grunt-based layer in our repo to experiement and evaluate such a build layer. The old build system stays untouched for the time being, so you don’t have to worry. The aim is to make existing functionality available through the Grunt frontend, and see which parts of the tool chain can be replaced by Grunt plugins, be they from NPM or self-written. For everything else the existing Python-based tool chain will be utilized.

The eventual goal is to have a qooxdoo tool chain that builds on a generic JS layer, is as powerful and sophisticated as before, but allows easier integration with and extension through third-party code, to make it easier for users to customize the tool chain in their applications, and to allow us to focus more on the qooxdoo-specific functionality and less on generic infrastructure and commodity tasks.

So, this is the beginning. We’ll be back with more as we progress.

qooxdoo 3.0.1 released

A new patch release of the framework is available.

qooxdoo 3.0.1 includes more than 60 bugfixes over the previous qooxdoo 3.0 release.

As a patch release qooxdoo 3.0.1 is fully backwards-compatible to the previous version. Nothing needs to be changed in your existing apps if they are based on qooxdoo 3.0. When upgrading from an older version you can migrate directly to 3.0.1.

Download qooxdoo 3.0.1, checkout the detailed release notes and the manual.

Many thanks from the core developers to the community, particularly for reporting issues and your help in improving the framework.

Compiler Hints in qooxdoo 3

tl;dr

When migrating compiler hints from their “#” form to the new “@” form, make sure to start the surrounding comment with “/**“.

The Details

qooxdoo 3 introduced the new compiler hints which are integrated with JSDoc comments. Basically, this is a straight-forward migration, but many people struggle when they do it. They find that after rewriting their hints they stop working, as if not there. This has to do with the structure of JSDoc comments in general.

When changing the compiler hints many start by replacing a compiler hint like #asset(custom/*) with @asset(custom/*). But you have to make sure that it is actually embedded in a valid JSDoc comment. So for the old hints

/* ****************************
#asset(custom/*)
**************************** */

was a suitable block comment, but just replacing “#” with “@”

/* ****************************
@asset(custom/*)  // doesn't work!
**************************** */

for the new hints it is NOT!

That’s because JSDoc comments absolutely positively have to start with “/**” (that is  slash-star-star). Otherwise, the comment will not be recognized as a JSDoc comment, intentionally to allow hiding comments from the JSDoc system.

So a correct form of the above compiler hint would be

/** ***************************
@asset(custom/*)  // works!
**************************** */

(mind the start of the comment!), and a more standards-conform formatting of the same comment would be

/**
 * @asset(custom/*)  // works too
 */

Please keep an eye on that when migrating the compiler hints in your code.

The week in qooxdoo (2013-08-30)

For the past week, incubating and ground work were going on, but nothing ready for prime time. So for now this issue report says it all.

JSConf.eu

For another thing, this is to let you know that JSConf Europe will commence in about 2 weeks, and a couple of us are going, and are already all excited because it’s going to be the most awesome event of the year for us (except releasing a new qooxdoo version, of course ;-) ). If you happen to attend or are around Berlin at that time, get in touch.