4 ms·

You mentioned these features as selling points but at the current state of things parallel styling/layout are buggy. Servo is buggy. And its not 100% proven bet

You mentioned these features as selling points but at the current state of things parallel styling/layout are buggy. Servo is buggy. And its not 100% proven better (emphasis on "experimental") than current tech. Chrome may not have these on the roadmap but its stable. The styling and layout algorithms are battle tested. Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value.

pcwalton 9y ago
I'd be more than willing to hear your technical thoughts as to why the features I mentioned are not "100% proven better" than the status quo. From my point of view, having measured this stuff over and over again for years, it's undeniable that they result in wins. The remaining bugs are features at the margins and will not affect the overall results. You seem confident, so I'm sure you have specific technical reasons, right? > Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value. Doing nothing is an even bigger risk. I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?
- bokan 9y ago
  The question isn't whether you should or shouldn't try to improve, it's where to invest your resources. Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. I don't think the sentiment is "lets be complacent", rather that Servo is optimising in the wrong places. We need to fix the web platform so that apps don't need to rely on performance killing techniques. Servo is cool, but I don't think it's solving what really ails the web. Disclaimer: I work on Chrome.
  - pcwalton 9y ago
    > Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. We need to fix the web platform so that apps don't need to rely on performance killing techniques. This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution). The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo. The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread. To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.
    - bokan 9y ago
      > which means that layout performance affects what looks like script time Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading. > And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution). I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it. > If layout were fast, we wouldn't see people implementing layouts in JS Are people re-implementing layout/paint because it's slow? Or because we didn't bake in the little detail they want into the platform through a multiyear standardisation process? I think it's naive to think developers will just stop writing JS if the browser gets x% faster. > If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread. I disagree. Developers will always find something to fill it with. IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms. I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive. In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web. Lets all innovate independently and let the results speak for themselves :).
- vatotemking 9y ago
  > Doing nothing is an even bigger risk. True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship? 1, 2 years? Was there a market research before hand? Like I said its a big question mark. Cant blame me if I have doubts after Firefox OS. > I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it? I dont know and I dont have something to do with it. Personally, I think the popular opinion on HN is pro Rust and pro Servo. > I'd be more than willing to hear your technical thoughts... Wait, are you using the "if you cant talk technical GTFO" card on me? We are straying from my original comment. To make this perfectly clear: Im not against improvement. Im against Mozilla's poor business decisions. You can see that was my point in the original comment. No im not downplaying all your hard work. But ive seen this happen before. Happened to me as well. "Oh this will be great when it ships" at the expense of the company. Im trying to give an alternative opinion here contrary to the constant positive reinforcement when Rust and Servo is posted on HN. Nothing personal.
  - steveklabnik 9y ago
    > Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship? Bits have already landed, and another major piece is being worked on right now. That's the whole idea of Quantum; no need to wait till Servo is done for Firefox users to start seeing benefit.
  - pcwalton 9y ago
    > True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands? Are you sure that people will download Firefox over Chrome when Mozilla does nothing?
    - vatotemking 9y ago
      The answer to that is obvious not a question mark.

pcwalton 9y ago

I'd be more than willing to hear your technical thoughts as to why the features I mentioned are not "100% proven better" than the status quo. From my point of view, having measured this stuff over and over again for years, it's undeniable that they result in wins. The remaining bugs are features at the margins and will not affect the overall results. You seem confident, so I'm sure you have specific technical reasons, right? > Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value. Doing nothing is an even bigger risk. I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?

bokan 9y ago
The question isn't whether you should or shouldn't try to improve, it's where to invest your resources. Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. I don't think the sentiment is "lets be complacent", rather that Servo is optimising in the wrong places. We need to fix the web platform so that apps don't need to rely on performance killing techniques. Servo is cool, but I don't think it's solving what really ails the web. Disclaimer: I work on Chrome.
- pcwalton 9y ago
  > Servo improves the speed of layout, style, etc. but is that really what's making the web experience slow? If you do some performance tracing, you'll see your browser already spends a paltry amount of time doing those things. It's spending most of its time running ridiculous amounts of JS that's being pulled in from dozens of domains on any given page load. We need to fix the web platform so that apps don't need to rely on performance killing techniques. This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution). The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo. The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread. To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.
  - bokan 9y ago
    > which means that layout performance affects what looks like script time Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading. > And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution). I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it. > If layout were fast, we wouldn't see people implementing layouts in JS Are people re-implementing layout/paint because it's slow? Or because we didn't bake in the little detail they want into the platform through a multiyear standardisation process? I think it's naive to think developers will just stop writing JS if the browser gets x% faster. > If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread. I disagree. Developers will always find something to fill it with. IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms. I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive. In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web. Lets all innovate independently and let the results speak for themselves :).
vatotemking 9y ago
> Doing nothing is an even bigger risk. True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship? 1, 2 years? Was there a market research before hand? Like I said its a big question mark. Cant blame me if I have doubts after Firefox OS. > I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it? I dont know and I dont have something to do with it. Personally, I think the popular opinion on HN is pro Rust and pro Servo. > I'd be more than willing to hear your technical thoughts... Wait, are you using the "if you cant talk technical GTFO" card on me? We are straying from my original comment. To make this perfectly clear: Im not against improvement. Im against Mozilla's poor business decisions. You can see that was my point in the original comment. No im not downplaying all your hard work. But ive seen this happen before. Happened to me as well. "Oh this will be great when it ships" at the expense of the company. Im trying to give an alternative opinion here contrary to the constant positive reinforcement when Rust and Servo is posted on HN. Nothing personal.
- steveklabnik 9y ago
  > Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship? Bits have already landed, and another major piece is being worked on right now. That's the whole idea of Quantum; no need to wait till Servo is done for Firefox users to start seeing benefit.
- pcwalton 9y ago
  > True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands? Are you sure that people will download Firefox over Chrome when Mozilla does nothing?
  - vatotemking 9y ago
    The answer to that is obvious not a question mark.