tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-769) Combination of JavaScript is flawed
Date Thu, 09 Jul 2009 15:46:15 GMT

    [ https://issues.apache.org/jira/browse/TAP5-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729303#action_12729303
] 

Howard M. Lewis Ship commented on TAP5-769:
-------------------------------------------

I'm not sure if there's an issue for this, but a suggestion was floating around that the core
JS stack be combined separately from the per-page JS. Thus you'd have one request for prototype/scripaculous/events/tapestry/etc.
and a second request anything specific per-page.  An advantage here is that the core stack
could have a shorter url, something like:

/assets/virtual/x.y.z/core.js

Since the core JS library paths would not need to be encoded into the name, the per-page virtual
script would also be shorter.

I can also see an easy way to extend the base stack to include additional JS files; this would
pre-emptively include the JS library as part of the core; so if you are using, say, Modalbox
across many pages, it would be in core (even for pages that don't actually use it).

5.1 introduces a service responsible for encoding binary streams into MIME (for inclusion
in the URL); that's where your 919 characters come from. The intent is that the service could
be overridden to store the data on the server side (in the main database, or some kind of
embedded database) and send just a token or id to the client side. That has a lot of implications
for a clustered application, which is why the default behavior is to encode the data into
the MIME stream and let it live on the client.

> Combination of JavaScript is flawed
> -----------------------------------
>
>                 Key: TAP5-769
>                 URL: https://issues.apache.org/jira/browse/TAP5-769
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: Andy Blower
>
> I think Tapestry's JavaScript combination functionality is flawed. Each page & component
specifies which JS files it needs, which means that JS can be split into functional units
(good for development & maintenance) and only the JS that's actually needed for that page
is added for the client to download. The consequence of this is that pages can have lots of
JS files to download, all of which has to be downloaded before the page is loaded/rendered
now that the script link tags are enforced to be back in the head section. Our search results
page has 34 JS files for instance.
> Yahoo's YSlow tool recommends that these files are combined and minified, and Tapestry
includes functionality to do the first (minifying is on the TODO list I believe) probably
as a response to this recommendation which is good. Unfortunately the implementation based
on only having the JS files required for a page means that the combined JS can easily be unique
for most pages of a site. This means that the client browser has to download & cache lots
of large JS multiple times (prototype, scriptaculous, tapestry etc) as part of bigger combined
files, which I think is probably worse than requesting them separately, but only downloading
stuff once and using that for all pages.
> To solve this issue, Tapestry script combination could combine all of the scripts needed
for the site, and not just the unique set for each page. That way only a single JS file needs
to be downloaded and cached by the client browser. I'm aware that this may not be that easy
given the existing way only scripts needed for the page are put on it, so an alternative solution
that may be easier to implement would be to combine scripts into two files for each page.
The first file would contain all of the commonly Tapestry provided JS such as prototype.js,
scriptaculous.js, effects.js, tapestry.js, etc in one file that's the same for every page,
and have the rest in a second file that is unique for the page but that is not likely to include
very large JS files, just many little ones.
> A second flaw that the combination has is that if an external JS file is requested, script
combination is aborted rather than just excluding the external file from the combination.
> One other thing that surprised me about Tapestry's script combination is the length of
the generated filename, for example it's 919 characters long for a page on our site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message