qooxdoo is slow to run when developing with source-all - qooxdoo

Question

When running:
python generate.py source-all
I get all the libraries in my application. This is all good.
When running the application qooxdoo is loading all classes separatly.
I want to use qooxdoo as an online development tool where only the build should be run in the end. Also when running both the server and client in dev mode it runs slow when loading each class of qooxdoo separately.
Can I instead include http://cdnjs.cloudflare.com/ajax/libs/qooxdoo/4.1/q.min.js or a local copy from the server software library folder and for development only run:
python generate.py source

Answer 1

First I'd like to clarify the terms, because I felt some ambiguity in question's.
Terms
Qooxdoo generator's execution unit is a job, e.g. info job is invoked as ./generator.py info. Jobs that are involved in dependency management (finding how an application class depends on other classes from the application, the framework and 3rd party libraries) produce a target. Target may include original classes as-is (by full path), build parts (set of concatenated classes, which may be optimised, plus some meta data and data optionally), or mix of the two. Target is loaded by a web browser via loader.
Source target
Source target jobs are means of dependency management for development (writing code). There are three of such.
source
With the source job all the classes of the application are in their original source form, and their files are directly loaded from their original paths on the file system.
The target includes only actual dependency from the application, the framework and libraries. All classes loaded as-is (hundreds of requests). You may have loading issues even loading it from file:// in some browsers (e.g. in test runner that waits for AUT to load not long enough).
source-all
source-all will include all known classes, be they part of your application, the qooxdoo framework, or any other qooxdoo library or contribution you might be using.
The target includes all existsing classes from the application, the framework and declared libraries. All classes loaded as-is (hundreds of requests, more than for source job). More loading issues than with source job.
source-hybrid (which is default default-job)
The source-hybrid job concatenates the contents of the classes that make up the application into a few files parts, only leaving your own application classes separate. Having the other class files (framework, libraries, contribs) chunked together you get the loading speed of nearly the build version, while at the same time retaining the accessibility of your own application files for debugging.
The target includes only actual dependency from the application, the framework and libraries. All non-application classes are concatenated into parts (dozen or two). Application classes loaded as-is, the rest is loaded from parts. Gives best loading performance.
Build target
There's only one build target job, build. However depending on configuration it can produce a single-file build or partial (multi-file, usually several files) build. Unlike source targets, build target's files are optimised (minified) and intended for production deployment.
Online development
There's example application for online development, playground (application/playground in SDK). Let's look at relevant jobs from its config.json.
"playground-compile" :
{
"extend" : [ "libraries" ],
//...
"include" :
[
"${APPLICATION}.*",
"qx.*"
],
"exclude" :
[
"qx.test.*",
"qx.dev.unit.*",
//..
],
//...
},
"build-script" :
{
"extend" : [ "playground-compile" ],
//...
},
"source" :
{
"extend" : [ "playground-compile" ],
//...
}
As you can see above, for both targets all qooxdoo classes (except tests and development classes) are included so you can use them in playground snippets. Generally it is your case. The rest depends on sort of the online development you have and your requirements to it. You may base it on source-hybrid (easier to debug) or on build target (faster to load). You may mix up some custom configuration, basing it on playground's config.
One important thing that needs to be noted is that if you plan to have significantly more complex code than it is the case for playground snippets, implemented in number of classes that depend on each other, you will need to handle dependency management yourself (i.e. load classes in proper order). If your "online" code deals with a subset of the framework, working with tabular data for instance, it makes sense to include only the subset (e.g. qx.ui.table.* instead of qx.*). For you information, playground's single-file build target is 2.1MB (~550kB gzipped).
Misc
q.min.js is qxWeb. It is jQuery/jQueryUI-like library. Basically, from application development point of view qxWeb has noting to do with normal Qooxdoo flow.

Answer 2

A build created with source-all loads each class, framework and application classes alike, individually - i.e. it loads the hundreds of framework classes one by one (last time I checked, it also loads framework classes which are not used by the application code).
As a workaround, the framework devs have created the job source-hybrid. This one works just as source-all, but creates and loads a concatenation of all framework classes, instead of each class individually (and I think it minifies the framework classes too). Using source-hybrid instead of source-all should improve loading speed significantly.
(What would be great would be the framework devs to add an option to the build* jobs to also generate source maps. But that's not in the generator so far.)