Am 29.02.2008 um 22:42 schrieb Ralf Nieuwenhuijsen: > I am wondering a number of things. > > method 1: on-demand loading of certain parts of code > ============================================ > It seems like on-demand loading of certain parts of code may make the > loading fase faster. Something like calling attaching a dependency to > an event. So, objectX when clicked will require 'somefile.js' .. load > it, and _then_ send the events.. (when the code is actually loaded)
This is exactly where the new toolchain could help. It will offer a semi-automatic splitting of a large application and also provides nice callback-based listeners when loading is done. BTW: An early preview of this new part loading system is used by the mail application at GMX.com. > > > method 2: separate initialization code from non-initialization code > =================================================== > Also, how much code do we need to load before the initialization or at > least part of it can be started? If we can do 50% of the > initialization with only 10% of the code loaded, wouldn't it be smart > to split the code up like that? > > partA.js -- code needed to initialize > partB.js -- code needed after initialization > > Why not load PartA .. call for an async request for partB.js and then > start initialization? > > Or am I mistaken? Is it application dependent? Yes, this depends from application to application. But again, this is something the new toolchain would easily make possible. > > > Method 3: Partial Evaluation > ========================== > Would it be possible to partially-evaluate a qooxdoo application on > the server using some javascript-interpreter? This way we could send > the generated html or json-structure of dom-nodes straight to the > browser and then start initialization. > > I wouldn't mind writing a javascript interpreter in Haskell to try > this out, but i have little clue about the dom. Are there tecnical > reasons this could not be done? Like asking the browser to calculate > parts of the layout which might be different among browsers? > > Added benefit is that I could do some real-type-checking using > dependent types. Off course there is always a point in a dynamic > language where the type-checking should be deffered (or otherwise the > type-checking itself could loop forever .. you don't want turing power > there) I don't think this is an option. You cannot transfer DOM nodes except as HTML string and there is no JavaScript interpreter currently which allows you to work on a virtual HTML document without the browser (no, Rhino does not support this). Greeetings, Sebastian > > > Greetings, > Ralf > > > 2008/2/28, Leander Hanwald <[EMAIL PROTECTED]>: >> 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 >> > > ------------------------------------------------------------------------- > 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
