Friday, December 18th, 2009

The Maturation of a Framework; qooxdoo reaches 1.0

Category: Qooxdoo


From the moment I saw qooxdoo, I felt they had an excellent & very polished set of functionality as well as insanely rich UI controls but I never took the time to look at the commitment that the team had put into this project. So when qooxdoo project lead Andreas Ecker buzzed me to tell me that the framework had reached 1.0, I decided to take a peak at the history of the project (at least in terms of first available downloads). I looked at the QooxDoo download repo and was surprised by how mature this project is. When you consider that the project was first registered on SourceForge in January, 2005 and made their first available version of qooxdoo on May 9th, 2005, it shows that an incredible amount of effort & dedication has gone into cultivating the project and framework.

The results are very obvious as qooxdoo v1.0 sports one of the richest feature sets of any JavaScript framework. Apart from the standard JavaScript syntactical sugar and DOM traversal/manipulation capabilities found in all JS libs, qooxdoo’s suite of UI controls are outstanding and are comparable to any of the best UI libs available. Looking at their showcase of demo apps, you can see how appealing the controls & layout capabilities are.


And it really does focus on the “framework” aspect of things with support for internationalization, dependency resolution, integrated unit & functional testing, build management and more.

There is much more offered in qooxdoo, however, than just a large set of widgets, powerful layout managers and virtually unlimited theming capabilities. As a full-fledged application framework, it comes with an integrated, platform-independent tool chain that covers the entire range of app development and deployment – code validation, JS compiling and linking, compression and optimization, just to name a few. Other built-in tools allow for easy unit testing, automated GUI testing, searchable API reference, or cross-browser debugging a la Firebug. Mastering large-scale JavaScript applications is greatly facilitated by build process features such as automatically combined images (“sprites”) or transparently breaking up an app into various parts that are loaded on-demand.

So congratulations to the qooxdoo for reaching a major milestone in your project. The methodical approach for your releases has certainly paid off as qooxdoo v1.0 looks great!

Posted by Rey Bango at 8:27 pm

4 rating from 65 votes


Comments feed TrackBack URI

It’s interesting but isn’t extjs far beyond this has too offer?

Comment by berend — December 18, 2009

From a cursory look I’d say ExtJS is more feature complete. Especially Drag and Drop wise.

They are very different animals though. ExtJS code is mostly written with JSON syntax. This is all straight javascript. From reading the examples and the API docs I find the qooxdoo API cleaner, with less obvious quirks, but it’s missing useful features as well.

My experience is mostly with Ext Trees, and the qooxdoo tree is far less sophisticated. That said the tree api is structured very differently. In ExtJS the expand button is part of the treenode ui. In qooxdoo there is a separate sub widget, which is cleaner IMHO. I find parts of Ext functionalty to be annoyingly convoluted at times.

YMMV. I like what I see in terms of design and cleanliness. Needs more work of course. So does ExtJS.

Comment by Deadmeat — December 19, 2009

Qooxdoo is LGPL. ExtJS is GPL.

Qooxdoo looks great!

Comment by zachleat — December 19, 2009

The design looks great, but I think they’ve gone too far, look at the demo browser. You don’t have to implement HTML markup, which is not clearly a disadvantage, but I don’t like it. It may be fun to create everything from the code, but as time goes by, it will be harder to read and understand what belongs where. In HTML that would be very simple.

BTW I really like that ExtJS has an alternative with an LGPL license. This stuff will rock.

Comment by kow — December 19, 2009

Just wish frameworks like these supply widgets with proper semantic html instead of all tables or all divs. It makes it more irritating to test with for example Selenium and does not play nice with Semantic HTML + Progressive enhancement.
Putting a harsh statement out there, “you might as well use flash” and have better perfomance + stability. JS Widgets that rely 100% on JS and have no semantic structure are not accessible either.
Don’t get me wrong, I have the utmost respect for library builders and this framework looks brilliant in achieving purely cosmetical functionality. But apart from licences, this is already available and by quick comparison, also available with better performance (Qooxdoo drag and drop is sluggish for me).
Dont stop developing, keep going, but think more outside the box, otherwise yer just competing with 5 year old ideas.

Comment by BenGerrissen — December 19, 2009

*purely cosmetical functionality* is not really what I meant and actually a bit demeaning, sorry. Websites are becomming more then something an ideal user interfaces and paranoia demands more robust failsafe solutions and non-js alternatives for functionality.
Our company has to build enteprise websites that work even without javascript and they still want the progresive enhancement. This is becomming a trend and slowly some JS players are hooking into this trend.

Comment by BenGerrissen — December 19, 2009

There are plenty of solutions that cater to the progressive enhancement crowd. Why bum out on the few that don’t?

Comment by Joeri — December 19, 2009

Ext JS is a bit more feature-rich, but also, I think in regard to performance, way more responsive and faster-loading.

Comment by davidkaneda — December 19, 2009

@BenGerrissen Testing qooxdoo applications with Selenium is no problem at all since the generated mark-up is well defined. We even provide a custom Selenium plugin, which lets you define your tests in terms of the qooxdoo widget hierarchy.

Comment by fjakobs — December 20, 2009

We used qooxdoo to build, very rapidly, a sophisticated UI.
Whoop! this is fantastic news…
Diogo Shaw

Comment by diogoshaw — December 20, 2009

My appologies, didn’t mean to bum out on qooxdoo. My frustrations are offtopic ;)
Just wish our Java developers would stop trying to force me to use these “out of the box” frameworks for websites/applications where progressive enhancement, semantic html and accessibility are mandatory. Or stop complaining about the many layers I have to develop in order to use their choices…
I am still convinced we can have best of both world, though it’s an ugly beast to tackle.

Comment by BenGerrissen — December 21, 2009

Progressive enhancement should not avoid using any open technology like the browser client side javascript : the easier is not to care about not javascript available clients(including crawler bots), then write a “server side browser proxy” (you may use htmlunit, selenium, etc. I’ve seen some website using such a wonderful strategy), like a mini opera does for non javascript unable mobiles.

The open source world is really lacking of a server side javascript proxy right now, but it’s a must havein order to reach the next step in web user experience while not being stuck by things available or not in the client browser

Comment by temsa — December 21, 2009

Progressive enhancement is a tool like another. Sometimes it makes sense, sometimes it doesn’t. Google tends not to use it for their apps (they just build multiple front-ends). I’m sure they have good reasons for that.

Also off-topic: still no post on ExtJS 3.1, which was released at the same time. Hmm, I wonder why that is…

Comment by Joeri — December 21, 2009

I wonder what the intersection is between users who use the web without JS turned on, and users who use the web wearing tin-foil hats…hmmm

Comment by csuwldcat — December 21, 2009

Leave a comment

You must be logged in to post a comment.