6 ms·

These kind of complexities is why, as much as I would love it to, the web as it is cannot compete with the performance of native apps. What is in native a simp

These kind of complexities is why, as much as I would love it to, the web as it is cannot compete with the performance of native apps. What is in native a simple number (maybe two) is dozens of pages of specifications - which result in insane amount of work to deduce the value of a simple variable. Layout and rendering is probably even worse in this regard.

Asooka 9y ago
If you are writing a Web application, you can always just use the one number and skip the complexity. A lot of work is poured into browser engines to make them render the simple cases as quickly as possible, while allowing for rich styling grammar for use by people writing documents.
- Illniyar 9y ago
  Font size is the least of the issues really. Layout and animation are the big issues.
augustus0 9y ago
That was my reaction to the article as well. The amount of work being done here for Servo (and which has been done in other browsers) is hugely impressive, but this problem feels a little artificial — we could have build the same web that we have today with half these options and not even have lost much in terms of ergonomics. I wonder if some kind of "Expedient CSS" might be possible as a way forward. Site developers could opt themselves in with a comment tag and promise to use only a subset of CSS features and only simple cascades (maybe none) in return for better rendering performance. A little like what's been done for JavaScript with asm.js.
pcwalton 9y ago
On the contrary, when native apps support styling (e.g. through React Native), it's invariably very slow compared to all the optimizations that have gone into browsers. They generally can't compete with the decades of optimization that have gone into the Web platform. Sure, cascading of certain properties can be complex. But the compressed in-memory style representation, style sharing optimizations, parallel restyling, etc. more than make up for this. Each one of these is at least a 2x speedup on its own. Every single implementation of native app styling that I've seen hasn't even begun to implement any of these optimizations.
- vanderZwan 9y ago
  I don't know if you're aware of this, but you're making a different comparison than GP: GP: a simple way to set font size, say, in pixels vs CSS styling You: native support for CSS styling vs browser CSS styling Of course browsers are faster with the latter, due to the reasons you mentioned. But they cannot hope to be able to optimise as much and as easily as the former approach (in principle that is, I cannot say anything about whether or not they actually do). So I'd say you're both right by virtue of not debating the same thing. PS: When are the fast SVGs demo'd in Servo a long time ago coming to Firefox? :)
  - pcwalton 9y ago
    Setting font size in pixels on an inline style is as fast on the Web as, say, changing the font on an NSTextFieldCell. Why wouldn't it be?
    - Manishearth 9y ago
      To expand on this, CSS totally supports the basic performance of styling native apps provided you use features with the ergonomics of styling native apps (i.e. inline styles). It's when one wants to be able to better declare what the styles will be that you have performance implications, and as pcwalton says these are worse for native styling frameworks since they don't have much optimization work put into them. (Also, wrt the original comment, all this font-size handling isn't particularly a perf issue. There are other minor font perf issues, but this isn't one)
    - vanderZwan 9y ago
      You're again talking about current performance. The full HTML and CSS spec is large, complicated, and full of corner cases, and thus a lot harder to optimise. The point GP is making is that a simpler framework is much easier to maintain and optimise because it has much less to worry about (again, in principle). I think the key difference is this part of your earlier reply: > when native apps support styling .. when the implicit statement Illnyar was comparing CSS to a framework that doesn't support styling, or at least much simpler styling. I'm not hating on browsers, HTML or CSS here - they're amazing technologies. But these are two different points being made.

Asooka 9y ago

If you are writing a Web application, you can always just use the one number and skip the complexity. A lot of work is poured into browser engines to make them render the simple cases as quickly as possible, while allowing for rich styling grammar for use by people writing documents.

Illniyar 9y ago
Font size is the least of the issues really. Layout and animation are the big issues.

augustus0 9y ago

That was my reaction to the article as well. The amount of work being done here for Servo (and which has been done in other browsers) is hugely impressive, but this problem feels a little artificial — we could have build the same web that we have today with half these options and not even have lost much in terms of ergonomics. I wonder if some kind of "Expedient CSS" might be possible as a way forward. Site developers could opt themselves in with a comment tag and promise to use only a subset of CSS features and only simple cascades (maybe none) in return for better rendering performance. A little like what's been done for JavaScript with asm.js.

pcwalton 9y ago

On the contrary, when native apps support styling (e.g. through React Native), it's invariably very slow compared to all the optimizations that have gone into browsers. They generally can't compete with the decades of optimization that have gone into the Web platform. Sure, cascading of certain properties can be complex. But the compressed in-memory style representation, style sharing optimizations, parallel restyling, etc. more than make up for this. Each one of these is at least a 2x speedup on its own. Every single implementation of native app styling that I've seen hasn't even begun to implement any of these optimizations.

vanderZwan 9y ago
I don't know if you're aware of this, but you're making a different comparison than GP: GP: a simple way to set font size, say, in pixels vs CSS styling You: native support for CSS styling vs browser CSS styling Of course browsers are faster with the latter, due to the reasons you mentioned. But they cannot hope to be able to optimise as much and as easily as the former approach (in principle that is, I cannot say anything about whether or not they actually do). So I'd say you're both right by virtue of not debating the same thing. PS: When are the fast SVGs demo'd in Servo a long time ago coming to Firefox? :)
- pcwalton 9y ago
  Setting font size in pixels on an inline style is as fast on the Web as, say, changing the font on an NSTextFieldCell. Why wouldn't it be?
  - Manishearth 9y ago
    To expand on this, CSS totally supports the basic performance of styling native apps provided you use features with the ergonomics of styling native apps (i.e. inline styles). It's when one wants to be able to better declare what the styles will be that you have performance implications, and as pcwalton says these are worse for native styling frameworks since they don't have much optimization work put into them. (Also, wrt the original comment, all this font-size handling isn't particularly a perf issue. There are other minor font perf issues, but this isn't one)
  - vanderZwan 9y ago
    You're again talking about current performance. The full HTML and CSS spec is large, complicated, and full of corner cases, and thus a lot harder to optimise. The point GP is making is that a simpler framework is much easier to maintain and optimise because it has much less to worry about (again, in principle). I think the key difference is this part of your earlier reply: > when native apps support styling .. when the implicit statement Illnyar was comparing CSS to a framework that doesn't support styling, or at least much simpler styling. I'm not hating on browsers, HTML or CSS here - they're amazing technologies. But these are two different points being made.