Well, I guess this is a feature you would not care to implement if your users are not asking for it. Right now there are trends geared towards reducing page loading times from a resource loading perspective, wich state that you should reduce both the size and number of HTTP requests to load said resources. AJAX apps are great in that there are less full page refreshes, but hav the downside of loading lots more javascript, which affect the time required to actually load pages when a refresh does happen. Java developers are less aware of this, probably because many of us work on intranet apps where page loading times are less affected by this issue, but for public access sites tackling this issue can make a noticeable difference. And customers will be happier if their application loads quickly rather than having users wait 5-10 seconds before being able to interact with it. This, and allowing for easy modular javascript/CSS development is what Jawr is about. >From this standpoint, it does make sense that libraries bundled with their own static resources allow developers to choose the way to serve them, so they can apply minification, gzipping and other bundling schemes. >From this standpint, I'l try to answer your questions:
* Wouldn't such an option just cause errors unless people really knew what they were doing? If the option is properly documented, users will know what they are doing, and when to avoid using it. In fact, if a user needs such option it means he/she has in mind a specific scheme for distributing the resources and thus will take care not to break things up. By making it a non default option, regular users wouldn't even notice. This doesn't only affect Jawr users, some people for instance use a dedicated server for static resources, others might be using a different compression library (such as pack:tag), and some simply compress and combine ther scripts at build time. * I'm also still questioning why we would need Jawr to load our javascripts in the first place. Many reasons. Jawr minifies and selectively gzips scripts when the browser making the request supports it, so they will have a much smaller footprint on loading times. The scripts are referenced by a dynamically generated URL that will change when the contents of the script changes, so a new version will never face the problem of users using an older, cached version. Jawr includes caching headers to ensure the browser keeps the script and never requests it again. Also, Jawr users can combine your scripts with their own, so there is 1-2 requests as opposed to a whole bunch (I've seen well over 20!). There are studies (check out the YUI blog) that prove that this really takes down page loading times. Finally, with Jawr a bundle can be set as 'global', meaning it is always imported into pages so there is less chance of not including a required script (which is the concern of your first question). Despite all this, like I said at the beginning, if your users are not asking for this your efforts are best placed elsewhere (unless implementation is trivial). I am not a Trinidad user at the time, but since someone asked about the possibility of using Jawr I though I should clear the issue. I hope this did. Kind regards, Jordi Hernandez. Scott O'Bryan wrote: > > I think Matthias misunderstood. <trh:script> is a replacement for the > <script> tag in html. :) I believe you are asking why we don't have an > option to disable loading our scripts automatically. > > I guess my answer to that question would be why? Wouldn't such an > option just cause errors unless people really knew what they were > doing? I mean the trinidad components REQUIRE the script to be there. > So make users even know about it? I'm also still questioning why we > would need Jawr to load our javascripts in the first place. > > That said, I wouldn't mind supporting a plugable "script loader" in > Trinidad if people were really wanting to plug in Jawr, but we should > still ask what it gains us. > > Scott > > Jordi Hernandez wrote: >> Well, actually I know nothing about Trinidad. Scott said "currently there >> is >> no way to >> have trinidad NOT link to the common js". I imagined that it means that >> some >> files will be always linked automatically. So you could not link the >> common >> js with Jawr. Maybe I misunderstood? >> >> >> Regards, Jordi. >> >> >> Mathias Walter wrote: >> >>> Hi, >>> >>> >>>> I hope I'm not too pretentious by saying this, but maybe >>>> Trinidad should >>>> offer an option to let users load the scripts themselves. Not >>>> >>> Indeed, Trinidad has such an option: <trh:script> >>> >>> -- >>> Kind regards, >>> Mathias >>> >>> >>> >>> >> >> > > > -- View this message in context: http://www.nabble.com/-Facelets--Trinidad--Re%3A-Announcement%3A-Open-Source-Jawr-library-available-for-Facelets-users-tp16883599p17204010.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
