javascript performance inquiry, myDiv.innerHTML = content;

[sonic]

Hello,
I am experimenting with various ways of passing content between
javascript and server.

Originally i was performing xsl transformation with javascript, but I
noticed some performance issues when the size of the xml document was
growing too large (1000+ rows).

Now i am doing everything on the server, and passing xsl formatted
content back to javascript.

problem:

var myContent = server.getFormattedContent();
myContent.length = 400100; // etc
***************************************
myContentDiv.innerHTML = myContent;
***************************************

the brwoser will freeze for a second while that last line executes.

Is there any way to make it async ? or any way at all to get rid of
that browser freeze ?

I am also including pagination to decrease the size of document per
page, but really curious in available remedies to the problem described
above ( setting innerHTML with large content variable )
TIA

[Jc]

sonic wrote:

problem:

var myContent = server.getFormattedContent();
myContent.length = 400100; // etc
***************************************
myContentDiv.innerHTML = myContent;
***************************************

the brwoser will freeze for a second while that last line executes.

Is there any way to make it async ? or any way at all to get rid of
that browser freeze ?

AFAIK, you can't make that call async. Also, be aware that innerHTML is
not part of the official DOM. Now, I realize you are probably trying to
make the user experience richer by avoiding a page refresh, but
displaying formatted HTML from a server is what the browser itself is
designed/optimized for, by setting the page location to the appropriate
URL.

Using a scripting language to bypass this is going to be slower, and
there is going to be a delay, just like there is a delay as the browser
parses and displays a webpage when the browser navigates to a new page.
Taking a large string of HTML and parsing/rendering it isn't a trivial
task, and you're going to see that code perform even worse for users
with slower machines.

Perhaps the task you are trying to accomplish would better be suited to
a page reload of either the entire page or perhaps one of the frames of
a frameset. A feature such as a site that acts like a frameset without
actually using a frameset (and avoiding framing issues, such as
bookmark problems) using AJAX is not going to be as scalable if
implemented in a scripting language.

Another idea is to use a page reload/frameset for content that exceeds
a certain size, and only use the scripted version for content that has
acceptable performance.