22 ms·

Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current w

by ux-app 13y ago

Not sure I agree with this. Very few web applications are CPU bound to the point of locking the UI. Web Workers are extremely useful, however very few current web apps benefit from them. Given they cannot interact with the DOM they are limited to pure number crunching. Great if you're ray tracing or encoding/decoding sound or video, not much use to the other 99% of web apps. My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise.

daeken 13y ago
> My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.
- ux-app 13y ago
  > The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layout. Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width, height etc). This would presumably greatly reduce the impact of the parse/dom traversal/paint cycle of CSS.
  - untog 13y ago
    In this mode rules that affect style (bold, font etc) But bold and font would affect the width of the text which would affect text flow and possibly affect whether the container ought to grow and shrink or whether it ought to provide scroll bars... No change is simple, in that sense.
  - _greim_ 13y ago
    > In that case it seems that we need something new to replace CSS for layout There's so much that CSS (and browsers in general) do that we take for granted, which is good in one sense but bad since you can't dip below those abstractions and grapple with the layout engine (or garbage collector, or HTML parser, or selector engine) at a low level. You get the whole ball of wax and all that stuff runs all the time, even if you don't actually need it. In my view this is essentially what separates HTML apps from native ones.
  - spyder 13y ago
    So we need asm.css? :)
  - wwweston 13y ago
    I totally think CSS layout could use some improvements, but isn't the separation you're talking about here already pretty strong? I'm struggling to think of an example of a situation where text styles affect layout on containers where dimensions are anything other than 'auto'. And any situation at all where text styles affect positioning.
pcwalton 13y ago
The browser vendors definitely do micro-optimize these. DOM binding performance is measured in nanoseconds these days.
- MatthewPhillips 13y ago
  Then what is it?
  - ricardobeat 13y ago
    Repaints/reflow. DOM+CSS+JS is a complex system. Watch this: http://www.paulirish.com/2011/dom-html5-css3-performance/ http://www.paulirish.com/2011/dom-html5-css3-performance/
  - wyck 13y ago
    To add to ricardobeat, it's all repaints and recalculations. Web devs have become overzealous with smashing JS into every nook and cranny to manipulate the dom, it seems to be a battle Google is trying to educate people about, and good on them. Open dev tools in chrome, the click network/frames, hit record and refresh the page. Do this on a sluggish site that uses tons of js and you will see the problem.
  - bzbarsky 13y ago
    The most commons causes of slowness I've seen are: 1) Interleaving changes to style and requests for layout information: this causes lots of relayouts instead of just one. 2) Using libraries that under the hood helpfully end up doing item #1 for you. 3) Using complex graphical effects (blurred shadows are a common one, as are certain gradients) that are actually very expensive to implement and may not be amenable to being GPU-accelerated.
untog 13y ago
An example from my experience- auto-complete filtering. Loading a list of the user's Facebook friends (which can number into the thousands) and filter as they type. When that's on the main UI thread it's hideous- the page stops responding to typing, so people hit the key twice, the whole page feels like it's hanging. It's not constant CPU usage, but it's CPU usage at the exact moment the user expects the site to react immediately. Same goes for calculations when a user is swiping, or something like that.
vidarh 13y ago
> Very few web applications are CPU bound to the point of locking the UI. It comes up regularly around here. We've had to resort to all kinds of ugly workarounds (such, as, e.g. chunking work and running small pieces off setTimeout() or requestAnimationFrame). A simple thing like changing fonts on the Canvas more than a couple of things can kill any hope of a responsive UI unless you very carefully manage your rendering, depending on browser (Canvas font handling is ok on Chrome, and ridiculously slow on Firefox, for example).

by ux-app 13y ago

daeken 13y ago

> My understanding is that parsing CSS rules and updating the DOM are incredibly costly operations which none of the browser vendors have yet decided to optimise. These operations are extremely well-optimized. The reason they're slow is that they're also extremely complex and slow operations. It's not something you can hack around.

ux-app 13y ago
> The reason they're slow is that they're also extremely complex and slow operations. In that case it seems that we need something new to replace CSS for layout. Or maybe a 'strict mode' equivalent for CSS where styling is separated from layout. In this mode rules that affect style (bold, font etc) cannot affect container dimensions. This mode would include a subset of rules that affect only layout (position, width, height etc). This would presumably greatly reduce the impact of the parse/dom traversal/paint cycle of CSS.
- untog 13y ago
  In this mode rules that affect style (bold, font etc) But bold and font would affect the width of the text which would affect text flow and possibly affect whether the container ought to grow and shrink or whether it ought to provide scroll bars... No change is simple, in that sense.
- _greim_ 13y ago
  > In that case it seems that we need something new to replace CSS for layout There's so much that CSS (and browsers in general) do that we take for granted, which is good in one sense but bad since you can't dip below those abstractions and grapple with the layout engine (or garbage collector, or HTML parser, or selector engine) at a low level. You get the whole ball of wax and all that stuff runs all the time, even if you don't actually need it. In my view this is essentially what separates HTML apps from native ones.
- spyder 13y ago
  So we need asm.css? :)
- wwweston 13y ago
  I totally think CSS layout could use some improvements, but isn't the separation you're talking about here already pretty strong? I'm struggling to think of an example of a situation where text styles affect layout on containers where dimensions are anything other than 'auto'. And any situation at all where text styles affect positioning.

pcwalton 13y ago

The browser vendors definitely do micro-optimize these. DOM binding performance is measured in nanoseconds these days.

MatthewPhillips 13y ago
Then what is it?
- ricardobeat 13y ago
  Repaints/reflow. DOM+CSS+JS is a complex system. Watch this: http://www.paulirish.com/2011/dom-html5-css3-performance/ http://www.paulirish.com/2011/dom-html5-css3-performance/
- wyck 13y ago
  To add to ricardobeat, it's all repaints and recalculations. Web devs have become overzealous with smashing JS into every nook and cranny to manipulate the dom, it seems to be a battle Google is trying to educate people about, and good on them. Open dev tools in chrome, the click network/frames, hit record and refresh the page. Do this on a sluggish site that uses tons of js and you will see the problem.
- bzbarsky 13y ago
  The most commons causes of slowness I've seen are: 1) Interleaving changes to style and requests for layout information: this causes lots of relayouts instead of just one. 2) Using libraries that under the hood helpfully end up doing item #1 for you. 3) Using complex graphical effects (blurred shadows are a common one, as are certain gradients) that are actually very expensive to implement and may not be amenable to being GPU-accelerated.

untog 13y ago

An example from my experience- auto-complete filtering. Loading a list of the user's Facebook friends (which can number into the thousands) and filter as they type. When that's on the main UI thread it's hideous- the page stops responding to typing, so people hit the key twice, the whole page feels like it's hanging. It's not constant CPU usage, but it's CPU usage at the exact moment the user expects the site to react immediately. Same goes for calculations when a user is swiping, or something like that.

vidarh 13y ago

> Very few web applications are CPU bound to the point of locking the UI. It comes up regularly around here. We've had to resort to all kinds of ugly workarounds (such, as, e.g. chunking work and running small pieces off setTimeout() or requestAnimationFrame). A simple thing like changing fonts on the Canvas more than a couple of things can kill any hope of a responsive UI unless you very carefully manage your rendering, depending on browser (Canvas font handling is ok on Chrome, and ridiculously slow on Firefox, for example).