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

Reply via email to