Hi Alexander, Thanks for taking the time to answer. As of now it appears that I have to take the 715KB hit.
I was wondering if the Qooxdoo community, as the framework is starting to cater to mobile devices, is working on reducing the size of the minified script. On desktops and laptops with decent bandwidth 715KB is not a huge deal but it's probably a large chunk for a mobile phone to bite off. I have run Google's Closure Compiler on a couple of my build script and it shaved off only about 100KB. It appears that the compiler will only work so long as the scripts use the prototype inheritance model heavily and so doesn't seem to have too much effect on Qooxdoo scripts which are heavily OO in the classical sense. -deech On Wed, Aug 10, 2011 at 1:57 AM, Alexander Steitz <[email protected]> wrote: > Hi deech, > > On Tuesday 09 August 2011 15:29:12 aditya siram wrote: >> I have looked at the Partloader but there is a warning on the page >> telling me not to use it to load framework classes. However this is >> what I want to do. So for instance, all my apps use a table and I'd >> like to have that code cached in browser memory. > The warning does describe that you should use the application classes which > use the table widget (in your case) and put them in parts. You always have an > application class which is using a framework widget and this class should be > the starting point for parts. > The generator will automatically resolve the dependencies of your application > classes and put the neeeded framework classes in the parts where there need to > be. > >> I've been trying to understand "variants" [1]. The documentation says >> it does dead code elimination, but I don't understand how to use it to >> help me. > Suppose you have the following snippet of code (this is used throughout the > framework) > > --snip-- > // "qx.debug" returns a boolean value > if (qx.core.Environment.get("qx.debug")) > { > // some debugging code which should be present in the "build" version > } > --snip-- > > The application skeletons have built-in the configuration to remove the > "qx.debug" variant out of the build version. > > --snip- > "environment" : > { > "qx.debug" : false > } > --snip-- > > See at > http://manual.qooxdoo.org/1.5.x/pages/tool/generator_config_ref.html#environment > > This (and the setting of the "OPTIMIZE" macro) tells the generator to remove > this "dead code". You can define environment keys for your application and use > these environment keys to remove "dead code" if you need to. There is a nice > write-up about the environment feature in the manual. Worth a reading :) > > -> http://manual.qooxdoo.org/1.5.x/pages/core/environment.html > >> Also maybe I'm doing something wrong, but I put together a small demo >> application in which I have one class that uses the following >> framework classes: >> qx.ui.container.Composite, >> qx.ui.layout.HBox >> qx.ui.layout.VBox >> qx.ui.form.Button >> qx.ui.form.Textfield >> qx.ui.tree.Tree >> qx.data.controller.Tree >> qx.data.marshal.Json (statically) >> qx.ui.groupbox.Groupbox >> >> The build step creates a 715KB Javascript file. Is this normal? Can >> this be reduced somehow? > If these widgets are used at the same time and you can't divide them into > parts you won't get any smaller since you need classes for layouting, UI core > subsystem, event layer, etc. > > If you have e.g. an action which is triggered by the user which shows another > UI (e.g. another tab) you can slice your application in parts and load the > widgets only if the user e.g. presses a button (like a button which shows a > dialog). > Another possible solution would be to load a small "core" packages which > creates the UI without the necessary widgets and shows a waiting cursor as > long as the parts are loading, which contain the widgets. This way you might > get quicker startup and the application appears faster. > > Regards, > Alex > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
