I don't know the Spry framework at all, but if it's building the table
rows by creating elements through the DOM API (document.createElement,
HTMLElement#appendChild, etc.) or Prototype's wrappers for those [new
Element(...)], that may be part of the problem.

It may be somewhat counter-intuitive, but creating a TR element,
adding a bunch of TD elements to it, and then appending that to a
TBODY, all using the DOM API, is much, much slower on most browsers
than building a string of tags in memory and then adding them via the
non-standard (but common) innerHTML property.  I figure this is
because parsing HTML strings and turning them into displayed elements
is one of the most speed-critical things that browsers do, and so
their native handling of it is extremely optimized, working directly
with their internals.

I did an exercise a while back (here[1]) comparing DOM methods vs.
Prototype's wrappers for DOM methods vs. concatenating a string and
setting innerHTML.  The last method, innerHTML, wins on every browser
I tried, hands down, usually by at least one order of magnitude.
(Prototype's wrappers aren't very costly, but going through the DOM
methods is, and so they inherit that cost.)  The smallest discrepancy,
IIRC, is on Chrome ("only" about four times faster rathe than 10x or
100x faster) -- but then, Chrome is freakishly fast at nearly
everything. :-)

So when I need to do this sort of thing, I build up a string (perhaps
using Prototype's template stuff) and then apply it via Prototype's
Element#update method[2] (which uses innerHTML under-the-covers but
also handles some edge cases for you).

If you're doing 1,800 rows, even with innerHTML, I really like
emitch's suggestion of breaking it into chunks and periodically giving
the browser a chance to display what's been done so far.  You can use
setTimeout, or Prototype's convenient wrappers for it Function#defer
[3] and Function#delay[4].

[1] http://pastie.org/521342
[2] http://prototypejs.org/api/element/update
[3] http://prototypejs.org/api/function/defer
[4] http://prototypejs.org/api/function/delay

T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available

On Jun 23, 4:41 am, pedz <pedz...@gmail.com> wrote:
> I spent last weekend adding Spry to one of my web sites.  I'm using
> Ruby On Rails and prototype with perhaps a bit of script.aculo.us in
> this web site.
> What attracted me to Spry is the region and repeat features.  Lets us
> a table as an example.  The basic idea is the page that is sent out
> has only the header and a single row.  You have to put a div around
> the table to define the region.  And the data row in the table has a
> "repeat" attribute in it.  Somewhere you hook a data souce up to the
> region.  In my case, I went back to my Rails server with a json
> request which sprewed out the selected items in a javascript array,
> each element being an item.
> The initial row has macros like {name} that get expanded to fields in
> the items.  In my particular case, while a row only has 8 elements
> across, there are a lot of things in each td like hidden drop down
> lists, links, etc.  The work to create a json row is small compared to
> the work to create the equivalent html row.  What I see attractive
> with Spry is it moves the work of creating the html to the browser and
> offloads the server.  There is just no reason for the server to be
> doing that work.
> My belief is that ultimately, moving the creation of the html to the
> browser is the way of the future.  The server serves data.  The view
> processing will eventually be done in the browser.  There is no need
> for the server to do hard labor for the view processing.
> But I found Spry to be less than stellar.  The main biggest issue is
> when I have a page with 1800 rows, it takes my Firefox about a half a
> minute of dead time to create the page and render it -- during that
> time, my whole laptop is dead pretty much with the dreaded spinning
> beachball.  This half minute is divided into two parts I'm sure.  Part
> of the time is Spry running creating the 1800 rows.  I'll use the term
> "fill out" to refer to that process.  Then there is the time for
> Firefox to actually render the page.
> I also found the package to not be very flexible and configurable.  It
> has a sort feature but it has far fewer features than the tablesort.js
> file found on the net.
> So, it put me back to "can I do this myself" mode.
> A small side trace: I have seen the Rails cast where Ryan creates an
> "endless page".  My issue with that approach is that instead of one
> query, he makes N queries -- one for each page.  That seems like it
> would add load to the server while I'm trying to take load away from
> the server.
> It seems like I could leverage prototypes template feature for most of
> the work.  The main thing I would do different is make one request
> (like Spry) but I would only render the first page or two of rows.
> Then as the user scrolled,  more data would be filled out hopefully
> before the user actually got to it.
> There are lots of problems to all this.  How do you make the scroll
> bar act "right"?  What do you do when the user does a search within
> the page?  How do you handle a sort?  As you add rows, the width of
> the columns may grow which is not expected.  etc.
> But the essential concept is that all the data would be held as a
> javascript object and then the page filled out as it was needed.
> So, the question is, has anyone done something like this starting with
> Prototype?  I sure don't want to recreate the wheel here.  Is there
> any suggestion of other work that I can look at and build from?  Is
> there any interest by any of the readers to help out?
> Thank you,
> pedz
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to