Re: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Jordi Hernandez <jo...@hotmail.com>]

Hi Scott, 

I looked at Trinidad and found out the scripts are inside a jar file. Jawr
does not yet support reading js files off a jar so unless you extracted them
to a dir in your war you would not be able to map them. reading from jar is
planned for a future version though. 

As for fragmenting or not the scripts, I'm not sure if I fully understand
your point on granularity. Unless you are talking of seriously low level
stuff, I guess by block you means separate requests, i.e. defining separate
groups of files which are bundled together under one request. Jawr is all
about doing that, so how blocks are served is up to you, you can configure
as many bundles as you want very easily. An added benefit is that if the
client supports it, gzipping will be used for much smaller file sizes. 
That said, I think that while granularity should not be disregarded, the
fact is that more separate requests end up making a single page load slower.
Normally you'd want to join all your commonly used scripts, plus whichever
libraries you use in a single file and load less commonly used stuff (large
scripts you only use in a few pages or page-specific scripts) in separate
bundles. The page I recommended in my original post and the performance
tests by the yui team seem to suggest this. 

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 (just) for the
sake of Jawr users, but think this: if a project uses several libraries that
each import their own scripts at will, it might end up with pages which load
say, 15 scripts. That can really be a big performance hit in page loading
times...

Jawr also uses aggressive caching techniques (expires and etag headers,
empty body response to if-modified-since head requests and urls that change
only when a resource changes). So once a client has downloaded one of your
bundles, it should stay cached. 

Finally, I am not sure wether Jawr will work in a portlet application. You
do need to add a servlet to the web app configuration which in my limited
knowledge of the portlet technology means that it won't make any difference
to its runtime. Same for JSPs, Jawr uses a standard JSP taglib so I guess it
should work. 
That said, I don't know if addinng a servlet alongside a portlet app is
desirable or has unwanted side effects. Also, to load scripts using Jawr you
need to use the taglib, meaning that pages for each portlet that require
scripts to be loaded would need to be modified. 
On the bright side, Jawr keeps track of which scripts were already loaded,
so no duplicate script tags are generated (and these would cause an extra
HTTP request, so that's a good thing to avoid). 
Another nice thing is that, if portlet foo needs 'foo.js' and portlet bar
needs 'bar.js', the Jawr tags can be explicit about it even if you have
foo.js and bar.js joined in a bundle (i.e. foo.jsp has a tag pointing to
'foo.js', not some bundle name). Later, you remove the foo portlet from your
app and add bar.js to a new, different bundle: no problem, it keeps working
fine with no changes to the portlet. 
My company uses Liferay for its internal portal. The main page loads 5
portlets which results in well over 20 js requests. Not counting the inlined
javascript. Even from the intranet, it takes really long to load it. So I
guess we could really benefit from using Jawr. 

Ok, all that said, I have not tested Jawr with a portlet app yet. Do you
know of a sample app that I could quickly deploy to Jetty or Tomcat to make
some tests? 

Regards,
Jordi. 


Scott O'Bryan wrote:
> 
> The files do all exist in the jars, so it's possible you can configure 
> Jawr to do this if you wanted too.  But currently there is no way to 
> have trinidad NOT link to the common js.
> 
> Truthfully though, Trinidad is pretty light on the javascript and 
> library segmentation (unless it's done intelligently) may actually cause 
> performance loss.  Why?  In the case of the Trinidad JS, once the 
> library is loaded, it's cached.  This would mean that Jawr should not 
> simply aggregate the JS for components displayed, but would have to load 
> the library in well defined *blocks* so that they could be cached as 
> well.  I have seen solutions like this work, and work very well, for 
> large javascript libraries provided things are loaded in blocks - the 
> real key is granularity.
> 
> Also, do you guys have any ideas if Jawr would work in a portlet 
> environment?
> 
> Scott
> 
> Renzo Tomaselli wrote:
>> Looks really good.
>> For Trinidad users - a rather obvious question: since Trinidad appears 
>> to do more or less the same - is there any chance to wire things so 
>> that single files (js and css) are rendered ?
>> I know that Trinidad does merging on the fly - so that we are not 
>> allowed to configure Jawr with Trinidad files (such as 
>> /adf/jsLibs/Common1_0_7.js and the filtered out skin css file).
>>
>> -- Renzo
>>
>> Jordi Sellés wrote:
>>> Hi to everyone on the list, this is my first posting announcing the 
>>> availability of a new Facelets related tool.
>>>
>>> Jawr <https:%5C%5Cjawr.dev.java.net> is an Open Source library which 
>>> offers two complementary uses for java and Facelets web applications 
>>> in which javascript is heavily used:
>>>
>>>     * First, it's a productivity tool, since it allows to develop
>>>       javascript components in separate files, each representing a
>>>       module, as opposed to having all the code in one or two files
>>>       for performance reasons. Working with separate files makes
>>>       development, maintenance and version control a lot easier.
>>>
>>>     * On the other hand, Jawr is a performance tool which will
>>>       perceivably improve page loading times. When in production
>>>       mode, all the modules which were split in separate files are
>>>       bundled together (into one or several files, as per
>>>       configuration), then minified, then compressed and sent to the
>>>       client using aggressive caching headers. This reduces the
>>>       number of HTTP requests required to load a full page and also
>>>       the size in kilobytes that a user must download. Jawr
>>>       implements many of the good practices defined in this very
>>>       interesting article which I recommend everyone to read: serving
>>>       javascript fast
>>>      
>>> <http://www.thinkvitamin.com/features/webapps/serving-javascript-fast>.
>>>
>>> Jawr is configured by adding a servlet to our application and 
>>> creating a simple .properties file to configure the way components 
>>> are to be bundled. CSS files can also benefit from bundling and 
>>> compression. Once configured, a Facelets tag library is used to 
>>> reference the bundles previously defined.
>>>
>>> These tags will work differently in development and production modes 
>>> (which are set by a flag in the properties file). When in development 
>>> mode, links to the separate, uncompressed modules are generated so 
>>> that we can debug them using, say, Firebug. Each links gets a random 
>>> parameter added to the URL so that upon every refresh of our page the 
>>> browser is force to reload the script. On the other hand, in 
>>> production mode links to the bundled, minified and compressed version 
>>> of the scripts are generated. There is no need to change anything in 
>>> the pages for this to happen, only a flag switch in the properties 
>>> file is needed.
>>>
>>> Other interesting features are traditional and Grails web apps 
>>> support, the ability to define custom postprocessors to change 
>>> dynamically the contents of bundled scripts, the ability to define 
>>> global bundles that are always imported into pages automatically, 
>>> defining bundles which are included within a defined conditional 
>>> comment for MSIE, obfuscating the scripts, etc...
>>>
>>> Jawr has an Apache 2.0 license, and can be configured to use JSmin or 
>>> the YUI Compressor under the hood, both with a BSD style license.
>>> The full project documentation is at https:\\jawr.dev.java.net 
>>> <https:%5C%5Cjawr.dev.java.net>. You can find about the specifics for 
>>> using Jawr with Facelets here 
>>> <https://jawr.dev.java.net/docs/facelets.html>.
>>>
>>> regards,
>>> Jordi Hernandez Selles
>>>
>>> ------------------------------------------------------------------------
>>> Sigue de cerca las últimas tendencias y lo que más rompe MSN Vídeo 
>>> <http://video.msn.com/video.aspx?mkt=es-es>
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-Facelets--Trinidad--Re%3A-Announcement%3A-Open-Source-Jawr-library-available-for-Facelets-users-tp16883599p17124847.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Jordi Hernandez <jo...@hotmail.com>]

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.

Re: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Jordi Hernandez <jo...@hotmail.com>]

Hi again. I just released a new version of Jawr which allows to bundle
javascript and CSS from jar files (or from anywhere in the classpath). So
Now it would be technically feasible to use Jawr with Trinidad if an option
was available to disable its automatic linking to scripts. 

Regards, Jordi. 

-- 
View this message in context: http://www.nabble.com/-Facelets--Trinidad--Re%3A-Announcement%3A-Open-Source-Jawr-library-available-for-Facelets-users-tp16883599p17596090.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Renzo Tomaselli <re...@tecnotp.it>]

Scott, I raised this issue first under the assumption that complex 
applications load Trinidad scripts, Tomahawk scripts, their own scripts, 
and so on.
If every library says "I need my scrips, thus I load them on my own", 
that application ends up in overall loading scripts multiple times.
This affects performance AFAIK, so a centralized - independent script 
loader would solve this issue for *all*. I guess Jaws covers exactly 
this role.
Otherwise in the above scenario we would need at least three atomic 
loadings, assuming private scripts are packed by Jaws.

-- Renzo

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
>>>
>>>
>>>
>>>     
>>
>>   
>
>

Re: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Scott O'Bryan <da...@gmail.com>]

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
>>
>>
>>
>>     
>
>   

RE: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Jordi Hernandez <jo...@hotmail.com>]

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-tp16883599p17130143.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

RE: [Facelets][Trinidad] Re: Announcement: Open Source Jawr library available for Facelets users

[Mathias Walter <ma...@gmx.net>]

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