Rails spinoffs - Sep 2005 - Load latency, file count, and a proposal

Hey All,

So now that we''re up to 7 files, and hopefully more
coming as the project grows, minimizing load latency
seems much more important. 

Maybe it''s time to consider creating a single file
distribution, much like what prototype.js is (a
concatination of 6 or so other files)?

re: packaging suggestions

*) scriptaculous_only.js
   - all of the scriptaculous components w/o prototype

*) scriptaculous_prototype.js
   - prototype + scriptaculous

(Better names anyone?)

re: caching - let''s avoid forcing it

One can argue that forcing browser caching is a
solution - I''ll counter argue that I''m being forced to
optimize early.  Using scriptaculous shouldn''t force
me to deal with deployment issues until I''m ready to
optimize - it shouldn''t be an all-or-nothing choice,
and now it is.  Equally well it still doesn''t solve
the issue of the initial page load latency which is
getting noticable (especially over distant links).

re: why now?

I think it would be great to get this nailed before
Rails goes 1.0.  Yet another well thought out part of
Rails that''s deployment friendly.

re: benefits? - at least 3

There are three:

*) It lets us make the core scriptaculous files finer
grained.  We can have one file per future control and
not worry about it (slider/tree/tab-pane/etc)

*) Reduced load latency

*) Easier cache management when the time comes (we
only have to manage one file in deployment)

re: javascript compressors - let''s avoid them for now

I know we talked about javascript compressors before,
but let''s not worry about them for now.  Simpler is
better.  Gzip''d http seems to work well enough, and if
someone wants to run a compressor on their own, they
can.

So how about it?  Thoughts?  Thomas, can we add a ''cat
*.js > scriptaculous_only.js'' somewhere in the build
process?

-San



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors'' Choice 2005 
http://mail.yahoo.com

Another option to consider is packaging scriptaculous as a set of  
JSAN packages. Sam is apparently already considering moving prototype  
to this format, and the JSAN guys are actively working on a set of  
deployment options including server-side solutions for dynamically  
bundling sets of packages into a single file on-the-fly, I think.

Moving scriptaculous to JSAN would allow it to easily make use of  
other packages available through JSAN, allow the source files to be  
as fine grained as you want, and allow scriptaculous users to take  
advantage of the flexibility JSAN promises to deliver from a  
deployment perspective.

JSAN is a relatively new project and is still maturing, but I think  
it''s already delivering useful benefits. Both projects could benefit  
from collaborating.

Just a thought :-)

L.

On 24-Sep-05, at 11:30 AM, sanzbox@yahoo.com wrote:
> Hey All,
>
> So now that we''re up to 7 files, and hopefully more
> coming as the project grows, minimizing load latency
> seems much more important.
>
> Maybe it''s time to consider creating a single file
> distribution, much like what prototype.js is (a
> concatination of 6 or so other files)?
>
> re: packaging suggestions
>
> *) scriptaculous_only.js
>    - all of the scriptaculous components w/o prototype
>
> *) scriptaculous_prototype.js
>    - prototype + scriptaculous
>
> (Better names anyone?)
>
> re: caching - let''s avoid forcing it
>
> One can argue that forcing browser caching is a
> solution - I''ll counter argue that I''m being forced to
> optimize early.  Using scriptaculous shouldn''t force
> me to deal with deployment issues until I''m ready to
> optimize - it shouldn''t be an all-or-nothing choice,
> and now it is.  Equally well it still doesn''t solve
> the issue of the initial page load latency which is
> getting noticable (especially over distant links).
>
> re: why now?
>
> I think it would be great to get this nailed before
> Rails goes 1.0.  Yet another well thought out part of
> Rails that''s deployment friendly.
>
> re: benefits? - at least 3
>
> There are three:
>
> *) It lets us make the core scriptaculous files finer
> grained.  We can have one file per future control and
> not worry about it (slider/tree/tab-pane/etc)
>
> *) Reduced load latency
>
> *) Easier cache management when the time comes (we
> only have to manage one file in deployment)
>
> re: javascript compressors - let''s avoid them for now
>
> I know we talked about javascript compressors before,
> but let''s not worry about them for now.  Simpler is
> better.  Gzip''d http seems to work well enough, and if
> someone wants to run a compressor on their own, they
> can.
>
> So how about it?  Thoughts?  Thomas, can we add a ''cat
> *.js > scriptaculous_only.js'' somewhere in the build
> process?
>
> -San
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors'' Choice 2005
> http://mail.yahoo.com
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/

I agree with all your points.
However ,we may want to keep a distribution
where scriptaculous is  still broken down in multiple
files and document dependencies between those files.

So,a user can still concat whatever files he wants
based on his own dependencies.

Rgds-Claude




--- "sanzbox@yahoo.com" <sanzbox@yahoo.com> wrote:
> Hey All,
> 
> So now that we''re up to 7 files, and hopefully more
> coming as the project grows, minimizing load latency
> seems much more important. 
> 
> Maybe it''s time to consider creating a single file
> distribution, much like what prototype.js is (a
> concatination of 6 or so other files)?
> 
> re: packaging suggestions
> 
> *) scriptaculous_only.js
>    - all of the scriptaculous components w/o
> prototype
> 
> *) scriptaculous_prototype.js
>    - prototype + scriptaculous
> 
> (Better names anyone?)
> 
> re: caching - let''s avoid forcing it
> 
> One can argue that forcing browser caching is a
> solution - I''ll counter argue that I''m being forced
> to
> optimize early.  Using scriptaculous shouldn''t force
> me to deal with deployment issues until I''m ready to
> optimize - it shouldn''t be an all-or-nothing choice,
> and now it is.  Equally well it still doesn''t solve
> the issue of the initial page load latency which is
> getting noticable (especially over distant links).
> 
> re: why now?
> 
> I think it would be great to get this nailed before
> Rails goes 1.0.  Yet another well thought out part
> of
> Rails that''s deployment friendly.
> 
> re: benefits? - at least 3
> 
> There are three:
> 
> *) It lets us make the core scriptaculous files
> finer
> grained.  We can have one file per future control
> and
> not worry about it (slider/tree/tab-pane/etc)
> 
> *) Reduced load latency
> 
> *) Easier cache management when the time comes (we
> only have to manage one file in deployment)
> 
> re: javascript compressors - let''s avoid them for
> now
> 
> I know we talked about javascript compressors
> before,
> but let''s not worry about them for now.  Simpler is
> better.  Gzip''d http seems to work well enough, and
> if
> someone wants to run a compressor on their own, they
> can.
> 
> So how about it?  Thoughts?  Thomas, can we add a
> ''cat
> *.js > scriptaculous_only.js'' somewhere in the build
> process?
> 
> -San
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail - PC Magazine Editors'' Choice 2005 
> http://mail.yahoo.com
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
>
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> 

Claude Hussenet
Independent J2EE Architect Consultant
http://claudehussenet.com


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors'' Choice 2005 
http://mail.yahoo.com

Sure, why not?
Have a look at the Rakefile in the SVN trunk. :)

Btw, the dependencies are as follows ATM:

- "core files" are: scriptaculous.js and util.js (scriptaculous.js  
contains only the "loader" at this time,
so it can be omitted)
- dragdrop.js and controls.js require effects.js

Thomas

Am 24.09.2005 um 17:30 schrieb sanzbox@yahoo.com:

>
> So how about it?  Thoughts?  Thomas, can we add a ''cat
> *.js > scriptaculous_only.js'' somewhere in the build
> process?
>
> -San
>

> Sure, why not?
> Have a look at the Rakefile in the SVN trunk. :)
> 
Hi Thomas, just did an ''svn update''.  No changes in
the Rakefile for ver 2332? (Am I pointing at the right
svn repository??).

re: replacing scriptaculous.js

What are your thoughts on replacing ''scriptaculous.js''
with the cat-ed
''dragdrop/effects/controls/slider/utils/etc'' bundle?

Perhaps change the current ''scriptaculous.js'' into
something called ''scriptaculous_loader.js''.  Then have
the Rakefile create ''scriptaculous.js'' from the bundle
of scripts.

''javascript_include_tag :defaults'' would then just
load up prototype.js and scriptaculous.js.

I''m thinking it would be a good goal to have Rails do
the simplest thing by default (minimize the number of
browser requests when they add in scriptaculous).  We
still leave room open for people to customize/trim
later.

-San





--- Thomas Fuchs <thomas@fesch.at> wrote:
> Sure, why not?
> Have a look at the Rakefile in the SVN trunk. :)
> 
> Btw, the dependencies are as follows ATM:
> 
> - "core files" are: scriptaculous.js and util.js
> (scriptaculous.js  
> contains only the "loader" at this time,
> so it can be omitted)
> - dragdrop.js and controls.js require effects.js
> 
> Thomas
> 
> Am 24.09.2005 um 17:30 schrieb sanzbox@yahoo.com:
> 
> 
> >
> > So how about it?  Thoughts?  Thomas, can we add a
> ''cat
> > *.js > scriptaculous_only.js'' somewhere in the
> build
> > process?
> >
> > -San
> >
> 
> 
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs@lists.rubyonrails.org
>
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Am 25.09.2005 um 18:15 schrieb sanzbox@yahoo.com:
> Hi Thomas, just did an ''svn update''.  No changes in
> the Rakefile for ver 2332? (Am I pointing at the right
> svn repository??).
I meant come up with a patch for it. :)
> What are your thoughts on replacing ''scriptaculous.js''
> with the cat-ed
''dragdrop/effects/controls/slider/utils/etc'' bundle?
> Perhaps change the current ''scriptaculous.js'' into
> something called ''scriptaculous_loader.js''.  Then have
> the Rakefile create ''scriptaculous.js'' from the bundle
> of scripts.
I want scriptaculous.js to remain as-is for auto-loading.
I can see the need for a combined version, so a combined
version could be named ''scriptaculous-combined.js'' or
something like that.

Note that I want to make scriptaculous.js take parameters
eventually and decide what dependencies to load in
automagically.
> ''javascript_include_tag :defaults'' would then just
> load up prototype.js and scriptaculous.js.
Yeah, my 1.5 patch[1] does this.
> I''m thinking it would be a good goal to have Rails do
> the simplest thing by default (minimize the number of
> browser requests when they add in scriptaculous).  We
> still leave room open for people to customize/trim
> later.
What I really want to see is a solution that''s backwards
compatible with Rails 0.13.1. That would involve
moving the stuff in utils.js to Prototype or have some
auto-loading of dependencies in effects.js, controls.js
and dragdrop.js (that is autoload utils.js if not already
loaded). That''s for people who just include prototype.js
and say, effects.js and don''t use javascript_include_tag :defaults.

To have that going, we''d need some kind of
''intelligent'' concatenation for the monolithic version, that
strips out the inclusion Javascript parts.

For the reasons I''ve given above (dependencies autoloading),
I think that using the monolithic version by default is not a good
thing, because it will be more difficult to migrate to autoloading
when its available.

I''ll see if I can put something together on this today. :)

Thomas

[1] http://dev.rubyonrails.org/ticket/2247