Recollection

The bug report

What was meant to break? The bug report mandated to rewrite Qooxdoo test infrastructure with callback spaghetti of mocha.js. Callback spaghetti?! When most code structure is a callback in callback in callback and so on, with the state expressed in free closure variables spanning across nesting levels, it is a callback spaghetti. And for average JavaScript code out there this structure practice is very common, which is nothing good though, but for Qooxdoo it might have been an awful decision, replacing clean, object-oriented code with that. But since Next is not Qooxdoo it may depend on some factors.

In the report Martin told:

There has been some hard decisions for me to take lately but I’m still convinced that not trying to be the expert for everything gives us the opportunity to focus on our strengths.

And listed some features that supposedly impressed him:

• pretty printing,
• scaffolding over to XML handling,
• Levenshtein distance calculation,
• GUI toolkits.

First is simple, second is needed only for recorded tests (e.g. Selenium), third is already there with qx.util.EditDistance. And forth is quite a thing Qooxdoo was made for. So these features are kind of false argument.

Moreover, mocha.js is 5k SLOC, qx.dev.unit is 4.4k SLOC, testrunner is 3.9k SLOC. Including these numbers and taking into account more expressive Qooxdoo code, either Martin is trading more for less, or it is just an expensive experiment.

Anyway framework consistency is absolutely a strength. Test code is a canonical source of thruth about an API. Test code is required for maintaining a complex application (which most websites are not though). And test infrastructure should not be compared to a disposal widget like qx.ui.embed.HtmlArea which wasn’t quality in first place, required special knowledge to maintain, and most importantly it isn’t hard create a wrapper for TinyMCE implementing qx.ui.form.IStringForm and qx.ui.form.IForm. Since that moment it is transparent and seamlessly integrated. Making test code an alien in a framework, makes it seamful, inconsistent, and what is worst can discourage developers from writing tests. Well, of course unless all the rest code is the spaghetti.

Last note here is how framework consistency from language perspective changes in the course of recent time. Qooxdoo branch_3_0_x roughly has nothing but Qooxdoo JavaScript code for a browser and Python code for generator. Next has Qooxdoo JavaScript code and mocha.js callback spaghetti test code for a browser, CommonJS code for generator that varies being object-oriented prototypal code, procedural code, and Qooxdoo object-oriented code, which also doesn’t exclude some Python code still necessary for new generator to function. So what’s clear, having hard time maintaining this is one of likely outcomes.

Goals

Andreas Ecker wrote in the post [3], that they have been looking into the challenges of a more lightweight, website-oriented approach to web applications. Sounds quite ambiguous and curious at the same time. Lightweight in byte size? Website-oriented in a non-widget UI? At the same time, it sounds as odd as arithmetic approach to differential equations. Then he expanded:

Reasons are two-fold: primarily, we are involved in company-internal projects in that very domain. Secondly, by touching core components of qooxdoo we can experiment with benefits of web technologies and concepts available today.

First thing, considering 1&1’s “very domain”, is probably something like Amazon AWS management UI. A web-application which spans multiple pages, where each page has some HTML from server and complementing JavaScript code. So it may be looked at as a “website-oriented approach”. Second thing again points to an experiment.

qxWeb

Qooxdoo targets websites since 2.0 which was released in June 2012 [5]. Initially I was enthusiastic about qxWeb, I thought it’ll be another virtue of the framework, and I still think the idea to target websites is right as even at mid-scale they benefit from most of Qooxdoo non-UI features. But the design and development of qxWeb seems to me misguided and mostly pointless now.

A year after qxWeb release, the time I was looking at it from various angles, trying to find its strength and way to integrate it in my flow to make it handle infrastructure task I used to handle with Qooxdoo in case of web application, I submitted the bug report [6] that proposes design that enables website development with Qooxdoo (native application type [14]), points qxWeb shortcomings and its possible shortcut-purpose, and the problems to be solved for normal operation. The biggest problem with qxWeb is that it wasn’t designed to be a Qooxdoo thing, but rather be jQuery with API done right. Long story told short: it’s not for writing an application, it’s for scribbling ad hoc per page scripts. And I would prefer qxWeb over jQuery for writing one-off script, but in general jQuery is de facto standard in DOM patching and I don’t see any significant niche for qxWeb as yet another DOM patcher plus this and that. Moreover even for shortcut-purpose in a Qooxdoo application, qxWeb is still an alien, because it needs manual dependency declaration for its “modules”. Qooxdoo way of DOM patching was qx.bom.Collection [7], removed in version 3.0. I think it was a mistake.

Starting with Qooxdoo 3.5 [8], there was an addition to qxWeb. Since then it supported low-level widgets. Such widget expects certain HTML structure and classes, which later is animated on widget instance construction. Basically, qxWeb started to mimic jQueryUI as well, not just jQuery. Not that I want to say it’s useless, but rather it’s reinvention of the wheel, reimplementation of a task that was already implemented long ago, and all who wanted such functionality already have it at hand. What’s worse the reimplementation is being done with outdated technology. DOM binding, MVVM [9], libraries emerged in 2009-2010, and at the moment of Qooxdoo 3.5 release, late 2013, were a commodity, as well as understanding that a lot of manual DOM patching is a chore, that can be automated with a view model. Bug #8101 [10] lead me to working KnockoutJS [11] adapter for Qooxdoo, but at the framework side it didn’t gain traction, except that Martin confirmed importance of the topic, and that also it’s the topic of his master thesis [12].

I want to summarise this section quoting Martin’s focus on our strengths. How the whole thing looks to me now, is that in area of website development Qooxdoo team tries to avoid its strengths at all costs. No build tools, no view model, no application design having great tools, data layer and application design experience. Instead Qooxdoo team is toying a jQuery/jQueryUI.

A Qooxdoo website today

Even though initial changes in Next doesn’t seem anything promising, I’m interested what the experiment may yield. But to address the need of a robust development environment for a website today I want to point again to the bug #7481 [6] and its proof of concept project [13].

Eventually all blocking bugs for #7481 were resolved and a Qooxdoo native application [14] since 3.5.1 was already fine as a basis for a website codebase. From my side I’ve been experimenting with the approach on a few real websites and result are good. When all website’s JavaScript code is centralised, it really starts to feel like an application, thusly significantly improving maintainability. Late autumn 2014 I’ve written documentation for the project, backported minor improvements and made it standalone.

qooxdoo-website-skeleton [13] is a mixture of a tutorial and skeleton. Because initial configuration is tricky, when starting from a scratch with native application, it’s easier to fork and remove a few unused files. Here I would like to tell about two aspects that Andreas pointed to (see above), and for the rest you can follow the link. First, a website approach to UI here is to provide a choice. One can use qxWeb DOM patching facilities or qxWeb widgets. One can use KnockoutJS adapter and use Qooxdoo data models as view models (MVVM). There’s also no restriction for using jQuery or KnockoutJS as is or whatever it makes sense to use.

Second, is being lightweight. Without external libraries Qooxdoo native application build with basic qxWeb modules is over 100 kB gzipped. For example boot part for the project is 361/110 kB (optimised/gzip -6). I would agree it is a little too much for a website yesterday, but today I don’t see this concern reasonable. Here are three hello pages for popular social websites requested from desktop Firefox.

And here are home pages for big e-commerce websites.

These show that having roughly over 100 kB is a norm today. And if further optimisation of Next will go as feature-size trade-off, then it wouldn’t probably make sense.

Epilogue

Before official announcement Next’s bug #8618 was in line with other dubious decisions taken since Qooxdoo 3.5. Before 3.5 I could agree to virtually every decision taken by the team, as there was clear reason, argument and pragmatic approach overall.

Now it’s mixed. There’s still fundamental work like migration to pointer events, but also several other topics that look like a waste of time. Like what? Like rewriting the generator to NodeJS and GruntJS [15]. Surprise! There’s ongoing shift to gulp.js and GruntJS is no longer cool JavaScript thiggie. And I’m curious to see how Qooxdoo team will handle such situations in general. Fancy toys change in the public sandbox fast [17]. Will you try to catch up every new cool replacement or will maintain an unpopular one?

Like, unconditional RESOLVED NEVER [16] set to all old bug. No prioritization, there is no past, the future’s so bright. The team briefly state something about turning to an agile development, and happily turned to developing new features. And of course, no doubt developing features is fun, PR is easier with less open bugs, and resources are always limited. But when new developers stumble the same bugs again and re-report them, it is a failure. I don’t really understand it, so since that change I’m just discouraged to file new bug and I don’t. If no one fixes them, and it takes time to analyse, make it reproducible and propose a solution, I probably shouldn’t, right?

I can whine more, but I want to point to two origins of priorities. It’s understanding the scope and understanding the users. First, is a universal JavaScript framework. How universal? And what is JavaScript here? JavaScript like in Netscape? Or like ECMAScript in NodeJS? Should we expect Qooxdoo approach to URL routing or database connection pooling? In second, I see opposite sides. One commenters in various places complain that Qooxdoo doesn’t play well with JavaScript ecosystem. I don’t think they are Qooxdoo users at all, but ones who couldn’t handle it. You know, you can’t do your Qooxdoo work copy-pasting from StackOverflow, you can do jQuery work this way. On the other side are users, including me, who say:

Dear Qooxdoo, we don’t really give a damn about JavaScript ecosystem, you are our only concern. We come from various established application development platforms, in sense “Swing/qt/Cocoa for the web”. We value design and maintainability. Please, keep on avoiding us from it.

That is to say. I’m an optimist, and there’s nothing parallel to Qooxdoo. So I hope the team won’t forget its strengths and its users, and will keep on the path of solving real problems.