Hacker News Reader

Comment by lukev | Hacker News Reader

The people who are complaining that this speedup only applies to 2D canvas are missing the point.

HTML rendering itself is already "fast enough." All of the perceptible delay when loading a webpage is network latency, rendering is already pretty much instantaneous on all modern browsers.

What browsers can't do right now is enable webapps with native speed and experience. And that is what Google is targeting squarely, with this in combination with Native Client.

If HTML5 is ever going to be a real Flash replacement, it's advances like these that will make it happen.

View on HN

HTML rendering itself is already "fast enough." [...] rendering is already pretty much instantaneous on all modern browsers

Strongly disagree. HTML rendering is terribly slow at certain things (especially in Firefox). Unfortunately they're the things our app's usability depends on, so we've had many struggles in this department. Anyone who's ever innocently accessed a DOM element's offsetLeft and wondered why their code got 100x slower will know what I mean.

DOM rendering is so far from instantaneous that it's scandalous. But optimizing Javascript implementations for benchmarks is easier, sexier, and more fun, so that's where the energy has mostly been going. I'd say it's actually the JS's that are "fast enough" at this point, but of course different apps have different needs. Thank goodness Google have been pushing the envelope in every department with Chrome and not just one.

Programmatic manipulation of the DOM does need a lot of work, yes. But that's not "page rendering" per se. Taking HTML and rendering it is pretty quick in most modern browsers. Mucking about with the DOM and having it refresh efficiently is a related but different problem.

html rendering is nowhere near fast enough, when building rich interfaces ensuring the ui is responsive while having to modify it extensively can be really really hard, if we still have to use tricks like optimising css selectors, using fragments to remove and add stuff from the dom and absolutely positioning everything because triggering redraw is still the bottleneck then I dont think rendering is near fast enough yet.

Particularly on mobile browsers.

What about the delay when loading a humongous table?

I occasionally need to load a page with 10,000 (or more) table cells, and those are always slow, and no one seems to test browser speeds on those.

We just addressed this problem at work.

The answer was to provide better tools that allowed users to analyze/interact with the data without having to render 10k rows to the screen.

It's not like they were able to read them all anyway. I'm going to go out on a limb and say unilaterally that anything that's just dumping 10,000 rows to the screen has, a priori, terrible usability.

It's not really a case I feel browser designers ought to spend a lot of time optimizing for.

That's true, but there wasn't time (i.e. money) to design something better.

It started much much much smaller, but they used it so much it grew far beyond it's initial design, and we were never able to come back to it to do something better. (It's an internal tool BTW, so we, i.e. they, just dealt with it.)

How much of that time is spent loading? Have you tried saving & opening locally? Is the data being handled in any way by javascript, which could be inefficient (for instance: tons of table tools use JS hover effects, instead of CSS).

Am actually interested, this is not to say it's not actually slow. Just trying to find out why / how slow it is.

It was local, php generated output from a database. (And the php wasn't slow, saving to a file was almost instant.)

I think it was just a totally barebones table, with tr and td of many rows from a table. I also had another one where it made an editable form from the data (the data had a bit more structure than the first, some css, but no onload javascript (just onclick)).

It was handmade, so no hover effects or other things.

Firefox was really slow and my customer eventually switched to using chrome for that page. But it's still slow, just not as slow.

I remember having my browser freeze totally for about 10 minutes (yes I timed it).

Still give it a try from a static HTML file, it could be different.

The 10 minutes sounds like more of a bug than anything else. I've loaded 20mb heavily-styled "books" in HTML that took ~10 seconds to load, but scrolled like molasses, but I've never seen a large table behave that poorly (though I've only handled 1-2 thousand rows).

Once the 10 min was over, it worked perfectly fine, and scrolled fast too. But memory usage went up a LOT.

So why on earth does AJAX exist? To solve such bottlenecks. Do AJAX calls for 100 cells instead of 10K.

I don't have experience with tables as large as yours, but I have noticed that if you give the browser hints about the columns using the <col>-tag, it loads larger tables faster.

Maybe you could render the cells when they're visible, similar to how UITableView works on iPhone.

Isn't the point that the headline is misleading?

Reply on news.ycombinator.com