Tank you for the reply Sebastian. It's clear that we talk only about the init transfer time (network transport), but it's an important part of the feeling an application.
Often I see JS Libs like Qooxdoo, ExtJS and other with loading times like this at the init time 2-3 Seconds network transport 1-3 Seconds initialization time (middle of stopped time and "feeled" time) 1-3 Sec. data loading (init lists with data and so on). At worth it took up to 6-8 to start working with an application. Nobody dies in this timeframe, but it doesn't feel fast. And from my point of view, qooxdoo often feels a little bit slower then other. At most, this is pure illusion, but illusion works. For example, Extjs seems to build the comps one after another, the display "flickers" more then in qooxdoo. Doesn't make a big difference, and not what I meaned in my first mail, but it's part if the "feeling". What I now mean, and what you answered in parts, is the network loading time. The splitting of the application sounds, even if I don't understand (even with the docs) how the applicaton will find the correct way to split it off. Could you explain this in more detail? And does it means that qooxdoo is part of all of the splitted parts? I think the splitting of qooxdo from the app code (if the app code is one or more files isn't what I mean, but sounds nice) is very important. If the user keeps a stable qooxdoo version (and who won't in a live app?), the user doesn't need to reload it when only the app code is changed. I don't see that point in your mail :) Also the JS result code client side cache optimizing seems not part of the new build system, but I think some small optional server side logic could improve it alot, together with pre-gziped js files (that can be delivered correctly by the server side scripts without mod_gzip on the server). And last but not least; I really think that the versioning is a good think to improve handling of the code. With differen js code filenames we could activate absolutly every freaking client side / proxy side caching system and can thrust on the delivery of the most up to date version at the same time. An never under 150 KB+images qx app should allways try to be loaden as rarely as possible. At a normal webpage 150 KB (gziped) files are not a big problem, but qooxdoo (and other js libs) need to do some rendering after that, and this is slowered at start then pure html code. So we should reduze the loading situations of the base files as often as possible. And I really think that creating a solid design for the delivery of the qx apps should be part of qooxdoo. I know that everythink I talked about can allready be done. I allready tried to build my own small separate qooxdoo file, try to exclude qooxdoo from my app code, gzip the js files, have PHP code on serverside for client side caching and so on, but why not put these in qooxdoo? Seems to be problems that others have, too. Please, correct me if I'm wrong, and more then that write who others do it. (The caching of the files in build process sound very nice, I hated the building in the past, every improvements is wonderful :) ) So be absolute clear, my three main situations I see ways to optimize: 1. When the app code is changed, but qooxdoo not (possible that 2. Idiot save client side caching (with server side logic and file names with version number attached), that make it also easy for the browser/proxy to find only changed files (in my example only 2, but if I understand you right then more in the future with generator2) 3. And improve gzip handling by adding it the the build process. And again the mail is longer then I hoped ;) Greetings, Leander Sebastian Werner schrieb: > Hi Leander, > > one thing to differenciate is the loading time (network transport) and > the other the initialization time (creating classes, properties, > objects). After this there is the runtime (e.g. reactions on mouse > clicks). > > Two split the resulting compiled file into multiple files does not > reduce the complete size and this way not the initialisation time. > What exactly needs to be done is, to split the file according to the > usage in the application. I will try to explain in one example: Your > application may have a preferences window which uses widgets which are > nowhere used, but there. In a normal qooxdoo build all classes, even > the ones from your preferences window a bundled into one big file. > Following this example the basic idea must be to split an application > into the logical parts (main window, preferences, accuout-manager, > etc.) not in the source groups (e.g. qx and application code). > > It is possible to solve this in 0.7.x by using custom generator calls > but it is some work to find the ideal groupings. (Documentation: > http://qooxdoo.org/documentation/0.7/custom_builds) > > In 0.8 we will introduce a new build system (if all went well). As if > our list for 0.8 isn't already long enough, we add another major > improvement: Semi automatic packaging. Each dialog and part of a > application simply gets registered in the build configuration file and > the system automatically manages the loading of these parts. Commonly > used classes are automatically grouped together as well. > > The new system also use a new caching system and other major > improvements. Rebuilds of already build software (just a few classes > modified) are done in seconds, not minutes. > > Both of your suggestions are doable with the new system easily. > However in my opinion there are better ways. > > Preliminary documentation is available here: > http://qooxdoo.org/documentation/general/generator2 > (trunk only at the moment). > > Regards, > > Sebastian > > > > > > Am 27.02.2008 um 15:21 schrieb Leander Hanwald: > > >> Hi all, >> >> I'm currently think about who to speed up qooxdoo load time. One of >> the >> main problems for most (I think ;) ) is the big JS file itself, not >> the >> runtime. >> Beside the option that you could use gzip I see other ways to speed up >> the loading. >> >> The most "annoying" part of a build process for me is that qooxdoo >> builds everything again and joins it again. But why exactly produce >> qooxdoo ONE big file, instead of 2? >> I mean, why is qooxdoo and the project linked together? From my >> point of >> view it's not very usefull. When a Project is changed (and most >> project >> will do this more often then they change qooxdoo), the qooxdoo part is >> reloaden by the client as well. >> I understand that loading 100 files is slower then 1 file, but loading >> two files instead of one file shouldn't be a great difference. Also >> other projects like ExtJS load up to 5 files for itself, and they >> still >> loading faster then qooxdoo (the the online demos). >> >> My idea would be the following: >> >> Source >> qooxdoo.js : This file contains all classes of qooxdoo and is >> generated only one time, or when user requested >> [project].js : This file includes the qooxdoo.js and the single >> classes >> of the user >> -> I think that would speed up the load time of the source version, >> now >> he loads hunderts of files which is often slowered (when I tested it) >> then loading all classes. >> >> Build: >> qooxdoo_[version].js : Like above, but if the uses selected it only >> with >> the needed classes. Regenerated only if needed >> [project]_[version].js : Combined and optimized Project files >> loader.js : This file is included the files above. The version >> number is >> to show the browser definitly when a js file is changed. >> -> If php/perl... is involed then the loader.js would load the script >> adove through the php/perl... scripts . >> -> The loader.js could be skipped if the index.html is autogenerated. >> >> There is one big advantage of the build version splittet these files: >> The Browser can now check if the files are changed separatly, and load >> only the changed one. If qooxdoo is not changed -> don't reload it. >> For >> most projects this would be a speed up on change by at least 50%, in >> smaler projects much more. >> >> Version number: The idea behind them is that you could set the client >> side cache to nearly unlimited, so the browser doesn't looks often >> (never? <- is that right?) if a file is changed and uses the cached >> one, >> until he sees the request for a file he doesn't now by name. >> >> Also it would be nice if qooxdoo could generate the gzip Version in >> the >> build process as well, and also produce php/perl/ruby/python loading >> scripts to choose the right JS Version and set the browser caching as >> well. I could write some PHP Scripts that helps here. >> >> I know that this is nothing for qooxdoo 7.x, but for 8.x it seems >> "sexy" >> for me. >> >> What did the rest thinks about that? >> >> Greetings, >> Leander >> >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
