This doesn't answer the question about re-initializing the qooxdoo system from page to page. If you go from one HTM page to another, the qooxdoo system will have to re-initialize/re-load. At that point you are loosing any benefit you might gain by having a smaller file with additional initialization for each page. If the library stayed resident then loading it with everything you are going to need for all pages and initializing it once would be faster for all pages. I just see creating a lot of different JS files and loading them seperately for each page sounds like a lot of work that will not have a benefit to the user. Perhaps there is a piece of the puzzle that I am not aware of, is there a way with qooxdoo to load an HTM page without unloading the qooxdoo stuff from memory?
In my tests, when you have qooxdoo on seperate pages, when you go from one to the other qooxdoo unloads, then re-loads and re-initializes. This is a lot of overhead for each page. Why not have one page that has a large HtmlEmbed and stuff new pages into it. This would be a lot faster for the user then exiting one page and loading a new one. Am I missing something here? I would think that the whole idea of creating a "Web Application" is to not have many pages that unload/load all of the time, too much overhead.

Just my $.02

Jim

On 9/8/06, Sebastian Werner <[EMAIL PROTECTED]> wrote:
Jim Hunter schrieb:
> One more thing to think about, if you include the same JS file on every
> page (IE: the full build version with everything), you only get a load
> hit on the first page. Every other page will use the cached file on the
> browser. So by using the full JS file on every page you actually make
> the subsequent pages run faster then if you try to include a unique JS
> file for each page (one that only has the stuff you need for that page).
> So in the long run, it's better to have one single file used on all
> pages and let the browser assist you by caching that file locally.
>

But it's possible that your application does not use some of the
included widgets at all. In my opinion it's better to build a core
module which contains the basic stuff (which is already quite big) and
than special modules for pages of the same type. As explained before
maybe a package which contains all toolbar and menu classes.

This means you have the same positive effect of caching the files, but
you also reduce the initialization time. If you include less classes the
application initialization is much faster in general. This time
otherwise affects all you pages. Better to load a small feature module
and have some modules with duplicated classes, than load too many
classes in every single page.

Cheers,

Sebastian

> Another thing to think about too is that there might be a startup hit on
> every page if you are in fact using different HTM files for each page. I
> am not sure how qooxdoo handles this since I would think that the
> library would get removed from memory going from one HTM file to
> another. You might want to think about simply using one 'page' and
> replacing the contents with new contents when you need a new page. This
> might increase the perceived speed of your application. If qooxdoo has
> to re-initialize for every page that is loaded that could slow down your
> app.
>
> Jim
>
>
> On 9/8/06, *Sebastian Werner* <[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> wrote:
>
>     Hi Jose,
>
>     I want to try to help you to understand the material a bit better. Maybe
>     it's possible for you to enhance the documentation afterwards to make it
>     even clearer for new qooxdoo users.
>
>     The build is better than the source. Especially for the final
>     release of
>     the product. The reason is maybe more the latency than the real network
>     speed. To handle 200 single requests is much slower than one with a
>     larger file. The "compiled" files also have no optional white spaces
>     and
>     comments. They only contains the functional parts of the class files.
>     This makes them smaller.
>
>     The performance difference is definitely noticeable. It's not the
>     execution speed which slows down using the "source". It's the loading
>     time as explained above. The loading time is about 3-4x higher
>     (depending on your connection) than using the built version.
>
>     If you use one of the skeletons you need not to check which classes are
>     you using. This is done automatically for you then.
>
>     Loading classes afterwards is maybe a good idea to reduce the initial
>     load time. But it's not a good idea to load each class separately.
>     Better is to build packages from the available classes e.g. a core
>     package, a tree & listview package, a toolbar & menu package, ...
>
>     Hope this clears the things a bit.
>
>     Cheers,
>
>     Sebastian
>
>
>
>     Jose Leon schrieb:
>      > Hello,
>      > On 9/7/06, Sebastian Werner < [EMAIL PROTECTED]
>     <mailto: [EMAIL PROTECTED]>> wrote:
>      >>> The problem I have is that I don't want to include a 900Kb .js
>     file on
>      >>> a page that has a single button, so I don't want to use the build
>      >>> system, and the alternative seems to be to include the separate
>     source
>      >>> files, but in the manual says using the built library improves
>      >>> performance and that's what I'm worried about.
>      >> If there are manuals no one seems to read them ;)
>      >>
>      >> Please take a look here:
>      >> http://qooxdoo.org/documentation/user_manual/custom_builds
>     <http://qooxdoo.org/documentation/user_manual/custom_builds>
>      > I have already read that documentation, in fact I have read the whole
>      > manual, and I told that I read all that pages on the first message on
>      > this thread, what I'm asking is this:
>      >
>      > -In the manual you say that using the prebuilt system it's better
>      > because a higher performance of the components. My question is if
>     this
>      > performance it's noticeable by the end user or not.
>      >
>      > -And the other question is that you say, to reduce the size of the
>      > qx.js, you must first check which components are you using on your
>      > application and then build a custom build, and that it's exactly what
>      > I'm trying not to do, what I want it's to load dynamically all the
>      > sources required and in your manual you say that this was the method
>      > used before the build system was included. So the question is if
>     there
>      > is a common rule or a standard method to know which .js source files
>      > to include to use a component. For example:
>      >
>      > To use a Button:
>      > -include A.js
>      > -Include B.js
>      > -Include C.js
>      >
>      > I hope this time it's clearer.
>      >
>      > Also I would like to know if it's not possible to create a dynamic
>      > system to load the required sources depending on the class you are
>      > using, for example:
>      >
>      > -Create a common array in the form of:
>      >
>      > Button=>"a.js","b.js"," c.js"
>      > TextField=>" a.js","b.js","c.js"
>      >
>      > That way you can write a simple function which includes all the
>      > required source files if you are using a class.
>      >
>      > Regards
>
>
>     -------------------------------------------------------------------------
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >
>     _______________________________________________
>     qooxdoo-devel mailing list
>     qooxdoo-devel@lists.sourceforge.net
>     <mailto: qooxdoo-devel@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to