This link has some interesting benchmarks(various browsers including mobile)
on how innerHtml stacks up against document fragments
http://jsperf.com/innerhtml-vs-document-fragment.
Just thought, this would be a relevant addition to this thread.
--
http://groups.google.com/group/Google-Web-To
On Mon, Jul 11, 2011 at 2:07 PM, Jens wrote:
> John,
>
> have you seen:
> http://blog.stevenlevithan.com/archives/faster-than-innerhtml ? I found it
> pretty interesting that you can speed up innerHTML by combining it with a
> DOM operation. Although the website uses a nowadays pretty old browser
John,
have you seen: http://blog.stevenlevithan.com/archives/faster-than-innerhtml
? I found it pretty interesting that you can speed up innerHTML by combining
it with a DOM operation. Although the website uses a nowadays pretty old
browser (Firefox 2) you can still get a 2x performance boost o
> In conclusion, I'm still optimizing to improve performance.
That's really interesting; thanks for taking the time to write it up.
> Eventually, we will likely integrate ElementBuilder into Cells. If
> you extend AbstractCell, then we can provide a default
> render(ElementBuilder) method that
Updates:
We'll continue to support and optimize Cell Widgets as the ideal for
rendering large data sets with maximum performance. That's why I'm
integrating ElementBuilder into CellTable, as opposed to creating a new
widget. As browsers evolve, we'll have to keep Cell Widgets up to date to
achie
> Could you elaborate a bit more on this statement and also how it
> impacts the direction future enhancements for cell widgets in general.
I agree that is a good question.
Even more pessimistically/cynically (so take it with a grain of salt),
is whether modern browsers will eventually be faste
John/GWT Team
As I understand, one of the important assumptions behind cell
widgets(CellTable, CellTree etc) is that innerHTML is fundamentally faster
than DOM manipulation.
*"
We've found that on some browsers, DOM manipulation is getting faster than
innerHTML (due to the cost of actually b
This sounds great to me. Are you sure that this will be the only breaking
change?
Lets look at the common use case of creating groups within a CellTable, and
I want to enable clicking on a group to collapse/expand the rows inside the
group.
A group within a CellTable shouldn't be associated
