[dev] [cvs] commit: imp compose.php contacts.php login.php mailbox.php message.php search.php imp/templates/compose javascript.inc imp/templates/contacts javascript.inc imp/templates/javascript compose.js contacts.js login.js mailbox.js message.js search.js ...

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at bigworm.curecanti.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at curecanti.org>:
>>
>>>   Move all javascript specific files to templates/javascript/src.
>>> Allows us to
>>>   1) compress JS code, 2) keep javascript files separate from presentation
>>>   files.
>>>   Add header comments to all JS files.
>>
>> The problem with compressed files in templates/javascript is that it's
>> getting hard to debug them, which was possible with the js/ files
>> through setting the jsuri parameter in registry.php.
>> I'm not sure if it's really necessary to compress all js files either,
>> the bandwidth gain shouldn't be that huge for most of the files.
>
> Points well taken.  I think we should kind of use IMP HEAD as the
> testing ground for this for awhile to see if it truly is worthwhile.
>
> Arguments for:
> * It makes looking through HTML code _much_ easier, as you don't have
> to wade through 300 lines of javascript between the presentation
> elements.

True, but we actually started to move javascript code *inside* the  
html templates to not require loading another template file or even  
doing another HTTP request which always adds overhead.

> * Not all sites support compression, and not all browsers handle it,
> so this provides an additional way for us to save some bandwidth (not
> to mention js compression is much less resource intensive than
> on-the-fly compression)

True, but if perfomance and bandwidth saving really are important to  
administrators, they will make sure that their servers support on the  
fly compression. And that is always more efficient than js  
compression. Which browsers do we not support with compression? Only  
NS4 iirc?

> * A lot of these javascript files are not able to be cached, since
> they are being output inline.  And if we can save 20-40% of the size
> of this data by compression, that comes out to be quite a bit of
> potential bandwidth savings.  Example: compression of the mailbox
> javascript saves 5K per pageload.  Say a user checks his mailbox 10
> times per session.  This is 50KB of saved bandwidth.  If 20,000 users
> login on a single day, that is 1GB of savings (without page
> compression benefits, of course).

See above, HTTP compression is much more efficient, and if they aren't  
cached, additional request even make less sense. This is different of  
course where we need the same js on different pages.

> If the main argument against not-compressing is debugging, I
> personally think that is a weak argument.  Anwyay, we could just do
> something like defining a 'IMP_JAVASCRIPT' variable that could easily
> be changed by the few people (i.e. the devs) that are actively
> debugging the js code.

The problem are usually not the devs, but people seeing javascript  
errors that we can't reproduce so that we depend on them telling us  
the code from the error line.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/