5 ms·

This sounds to me like Mozilla is getting impatient with Servo. Servo was more than just a parallel browser engine it was the only new web engine not based off

This sounds to me like Mozilla is getting impatient with Servo. Servo was more than just a parallel browser engine it was the only new web engine not based off of decade old codebase. It was a statement that it's feasible to hold off on monoculture because compatibility isn't impossible to achieve on new engines.

larsberg 10y ago
Project Quantum is an opportunity to ship some of the Servo components in Firefox and gain millions of users, real-world tests of the technology, and hopefully dramatically expand our contributor base. As we mention in a post to the Servo mailing list (https://groups.google.com/forum/#!topic/mozilla.dev.servo/3bH1KaqJq0s https://groups.google.com/forum/#!topic/mozilla.dev.servo/3b... ), Servo has a lot coming in 2017 unrelated to Project Quantum or Firefox.
- Touche 10y ago
  Speaking for myself, I don't want "Servo components" in Firefox; I want Servo in Firefox. I want an engine as fast as the one they have shown of Servo as being; not pieces of it that make Firefox incrementally better; I want a browser that is miles ahead. That's always what I found interesting about Servo.
  - zbraniecki 10y ago
    At the same time, you want a browser that keep working with the web at least on the same level as Firefox is right now. Servo is getting us 80% there, the remaining 20% of quirks, non-standardized behavior and web sites coded with only Chrome/Fx/IE in mind are going to be increasingly difficult to cover. On the other hand some pieces of servo are close to have "full" compatibility. That means that we can put them in Firefox already. The result is that web coverage alignment between Servo and Firefox increases which is great for Servo, and the performance and safety between them improves as well which will benefit Firefox.
    - Touche 10y ago
      Incremental improvements are fine, but they don't need a codename or a blog post. Incremental improvements are just something you always do in software development.
      - bzbarsky 10y ago
        Incremental improvements that together amount to a significant rearchitecture are not the same as incremental improvements that are just fiddling around the edges. But even the latter may need a name if they will involve months of time and a large enough group of people that all need to be able to refer to them. Blog posts are more debatable, of course.
      - oldmanjay 10y ago
        There's a giant gap between your personal lack of interest and the notion that this blog post is something no one finds interesting.
        Touche 10y ago
        > Speaking for myself
        oldmanjay 10y ago
        Perhaps in some comment to which I did not reply. The parent I am attached to had no such disclaimer but did explicitly say this is not worth a blog post.
    - mwcampbell 10y ago
      It also wouldn't be good to have Servo in Firefox until unglamorous things like accessibility are implemented. There's a lot that goes into mature, production software that isn't there in a new research prototype. So incrementally introducing pieces of Servo into the production codebase is probably better.
  - pcwalton 10y ago
    Even if you don't care about Gecko, this benefits Servo. It lets us battle-harden core components like WebRender and the style system.
    - Aldo_MX 10y ago
      It also benefits the Rust language for the same reasons. Firefox is already shipping components compiled in Rust[1]. [1] https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/ https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/
dblohm7 10y ago
Servo has always been and still is a research project. It was never intended to go into production as a fully-fledged Mozilla product. Quantum is the initiative to bring a lot of those technologies into Gecko.
- pcwalton 10y ago
  > Servo has always been and still is a research project. It was never intended to go into production as a fully-fledged Mozilla product. That's not true. Servo is designed to be production-grade.
  - metajack 10y ago
    To elaborate on this "production grade" comment, Quantum is using the same code that's in Servo. I think the fact we were able to build a production grade style system so quickly (and that is 4x faster!) is a testament to the advantages of Rust.
  - dblohm7 10y ago
    > That's not true. Servo is designed to be production-grade. I never said that it wasn't. I said that it wasn't going to be shipped as a production Mozilla product.
    - pcwalton 10y ago
      > I never said that it wasn't. I said that it wasn't going to be shipped as a production Mozilla product. That's also not true. Maybe it will, maybe it won't; that's a decision that has to incorporate many factors other than technical ones. From my point of view as an engineering lead, I'm designing the engine to ship.
      - tedmielczarek 10y ago
        One key difference here is that this keeps Servo open to continuing to be a research vehicle for new technologies without the exposure of compatibility for millions of users. If we ship Servo in a product that does change the equation a bit.
deleted 10y ago
[deleted]
dherman 10y ago
I can tell you from where I sit at Mozilla, everyone is very excited about Servo. It just takes time to build things! :) It wouldn't make sense to wait for Servo to reach full web compatibility before starting to integrate it into production uses. This is really just a natural next step in the progression of adopting Servo at Mozilla.
pcwalton 10y ago
Servo is still being developed with the same manpower. Quantum is not de-emphasizing Servo. It would make little sense to do so, since the lack of legacy in Servo is part of what has given us the freedom to experiment with things like parallel restyling in the first place. And Quantum helps Servo, too—by giving us real-world Web compatibility experience with portions of Servo's codebase sooner, it helps us shake out bugs faster than we can with Servo alone. (Disclaimer: As always, I speak for myself, not for my employer.)
- cgag 10y ago
  It would make no sense to de-emphasize servo. It seems like it would make a lot of sense to de-emphasize Quantum/firefox/everything mozilla is wasting their time and money on that isn't Servo. I hope that either mozilla is lying for political reasons about their lack of intent to use servo outright, or that the servo team forks from mozilla and takes funding from patreon (or snowdrift when it launches) and builds something great, without the burden of mozilla and firefox.
  - pcwalton 10y ago
    > It seems like it would make a lot of sense to de-emphasize Quantum/firefox/everything mozilla is wasting their time and money on that isn't Servo. Here's how I think of it: What's the biggest risk to Servo? I think most people would answer that (besides it being a lot of work), as it's a big boil-the-ocean project, there's a lot of newly-written code that hasn't been battle-tested yet. How do we fix that? By getting early user adoption on pieces when they're ready, so we can shake out the issues. Quantum is the perfect way to do that. Of course, I happen to care about Firefox's success too, so getting great features to Firefox users as soon as possible is also a big win from Quantum. :)
    - allendoerfer 10y ago
      The competition in the browser market is much harder than for example the market of programming languages and even there big version bumps have huge costs. If you can avoid it, you don't want all your resources tied to Perl 6, PHP 6, Python 3 and so on, while your users are complaining because the usable version of your software does not improve any longer.
Manishearth 10y ago
> This sounds to me like Mozilla is getting impatient with Servo. I mean, yes. In a way. I think this was always part of the plan for Servo -- if things go well start uplifting ideas and/or code to Firefox. This isn't exactly impatience; it makes perfect sense to do this. This isn't a change in gear for Servo, though. Servo is still chugging along. There are still no concrete plans (that I know of) for a Servo product, however Servo is working on stuff that it needs for it to be a product (i.e. it's not just focused on trying out researchy ideas to be used by Gecko), like proper SSL security. So there's nothing stopping Servo from being a product in the future, and Quantum doesn't affect this. Quantum affects Servo in a couple of ways: - There are now paid Gecko engineers hacking on bits of Servo (yay!). On the flipside, paid Servo engineers (e.g. me) are working on Quantum, but for the most part this involves improving Servo itself. - Rough edges are being polished, web compatibility is being addressed for the quantum components. These were things that were always being worked on, but weren't always a priority for a given component. For example, there have always been optimizations that we knew we could do, but we hadn't done them so far since there were other researchy things to focus on. Now these are getting implemented. - The build/CI system will probably have major changes to make it possible to smoothly integrate with Gecko. This doesn't really affect goals, just the day-to-day servo developer experience. It doesn't affect Servo's goals or de-emphasize Servo itself. It just gets some of the advances that Servo has made to the public faster.
NoGravitas 10y ago
Isn't this announcement basically just saying, though, that Servo is going to replace Gecko piece by piece, rather than all at once?
- zbraniecki 10y ago
  Servo components will replace Gecko components Where It Makes Sense (tm). Servo will remain the place where the most radical experiments happen and once proven, will "stabilize" their way into Gecko.
bzbarsky 10y ago
Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" switch with behavior specified for both branches. :(
- leeoniya 10y ago
  > Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" woah! that's truly tragic. at the risk of ruining the rest of my week, may i ask where?
  - bzbarsky 10y ago
    Sure. https://html.spec.whatwg.org/multipage/webappapis.html#concept-navigator-compatibility-mode https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the pieces of that spec that use it is the main place so far. There is also discussion about maybe using the same switch in https://github.com/whatwg/dom/issues/278 https://github.com/whatwg/dom/issues/278 if it turns out that too many pages assume "not webkit" means XMLDocument.load exists. It could be worse. When the ECMAScript committee discovered that parsing for function-in-a-block differs between browsers and that sites sniff and do different things in different browsers such that none of the browsers can change to each other's behavior, they went ahead and specified a "compatible subset" of behavior such that if you follow those rules you will get the same behavior in all browsers. That's fine, but if you _don't_, as web pages do not, then you're back to square 1: pages sniff and do different things. And the details are not written down anywhere, so a new implementation has no choice but to try to reverse-engineer the sniffing somehow and then also reverse-engineer the actual runtime behavior of function declarations of whatever browser's sniffing response they decided to fake. The good news is that this function-in-a-block thing is literally the worst situation I have encountered in web standards, so all the other ones suck less. ;)
- Aldo_MX 10y ago
  Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? Replicating other engine's bugs sounds like too much effort towards the wrong direction :/ Although, after the -webkit-disaster I don't really expect anyone to like the idea of a standards-compliant engine :(

larsberg 10y ago

Project Quantum is an opportunity to ship some of the Servo components in Firefox and gain millions of users, real-world tests of the technology, and hopefully dramatically expand our contributor base. As we mention in a post to the Servo mailing list (https://groups.google.com/forum/#!topic/mozilla.dev.servo/3bH1KaqJq0s https://groups.google.com/forum/#!topic/mozilla.dev.servo/3b... ), Servo has a lot coming in 2017 unrelated to Project Quantum or Firefox.

Touche 10y ago
Speaking for myself, I don't want "Servo components" in Firefox; I want Servo in Firefox. I want an engine as fast as the one they have shown of Servo as being; not pieces of it that make Firefox incrementally better; I want a browser that is miles ahead. That's always what I found interesting about Servo.
- zbraniecki 10y ago
  At the same time, you want a browser that keep working with the web at least on the same level as Firefox is right now. Servo is getting us 80% there, the remaining 20% of quirks, non-standardized behavior and web sites coded with only Chrome/Fx/IE in mind are going to be increasingly difficult to cover. On the other hand some pieces of servo are close to have "full" compatibility. That means that we can put them in Firefox already. The result is that web coverage alignment between Servo and Firefox increases which is great for Servo, and the performance and safety between them improves as well which will benefit Firefox.
  - Touche 10y ago
    Incremental improvements are fine, but they don't need a codename or a blog post. Incremental improvements are just something you always do in software development.
    - bzbarsky 10y ago
      Incremental improvements that together amount to a significant rearchitecture are not the same as incremental improvements that are just fiddling around the edges. But even the latter may need a name if they will involve months of time and a large enough group of people that all need to be able to refer to them. Blog posts are more debatable, of course.
    - oldmanjay 10y ago
      There's a giant gap between your personal lack of interest and the notion that this blog post is something no one finds interesting.
      - Touche 10y ago
        > Speaking for myself
        oldmanjay 10y ago
        Perhaps in some comment to which I did not reply. The parent I am attached to had no such disclaimer but did explicitly say this is not worth a blog post.
  - mwcampbell 10y ago
    It also wouldn't be good to have Servo in Firefox until unglamorous things like accessibility are implemented. There's a lot that goes into mature, production software that isn't there in a new research prototype. So incrementally introducing pieces of Servo into the production codebase is probably better.
- pcwalton 10y ago
  Even if you don't care about Gecko, this benefits Servo. It lets us battle-harden core components like WebRender and the style system.
  - Aldo_MX 10y ago
    It also benefits the Rust language for the same reasons. Firefox is already shipping components compiled in Rust[1]. [1] https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/ https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/

dblohm7 10y ago

Servo has always been and still is a research project. It was never intended to go into production as a fully-fledged Mozilla product. Quantum is the initiative to bring a lot of those technologies into Gecko.

pcwalton 10y ago
> Servo has always been and still is a research project. It was never intended to go into production as a fully-fledged Mozilla product. That's not true. Servo is designed to be production-grade.
- metajack 10y ago
  To elaborate on this "production grade" comment, Quantum is using the same code that's in Servo. I think the fact we were able to build a production grade style system so quickly (and that is 4x faster!) is a testament to the advantages of Rust.
- dblohm7 10y ago
  > That's not true. Servo is designed to be production-grade. I never said that it wasn't. I said that it wasn't going to be shipped as a production Mozilla product.
  - pcwalton 10y ago
    > I never said that it wasn't. I said that it wasn't going to be shipped as a production Mozilla product. That's also not true. Maybe it will, maybe it won't; that's a decision that has to incorporate many factors other than technical ones. From my point of view as an engineering lead, I'm designing the engine to ship.
    - tedmielczarek 10y ago
      One key difference here is that this keeps Servo open to continuing to be a research vehicle for new technologies without the exposure of compatibility for millions of users. If we ship Servo in a product that does change the equation a bit.

deleted 10y ago

[deleted]

dherman 10y ago

I can tell you from where I sit at Mozilla, everyone is very excited about Servo. It just takes time to build things! :) It wouldn't make sense to wait for Servo to reach full web compatibility before starting to integrate it into production uses. This is really just a natural next step in the progression of adopting Servo at Mozilla.

pcwalton 10y ago

Servo is still being developed with the same manpower. Quantum is not de-emphasizing Servo. It would make little sense to do so, since the lack of legacy in Servo is part of what has given us the freedom to experiment with things like parallel restyling in the first place. And Quantum helps Servo, too—by giving us real-world Web compatibility experience with portions of Servo's codebase sooner, it helps us shake out bugs faster than we can with Servo alone. (Disclaimer: As always, I speak for myself, not for my employer.)

cgag 10y ago
It would make no sense to de-emphasize servo. It seems like it would make a lot of sense to de-emphasize Quantum/firefox/everything mozilla is wasting their time and money on that isn't Servo. I hope that either mozilla is lying for political reasons about their lack of intent to use servo outright, or that the servo team forks from mozilla and takes funding from patreon (or snowdrift when it launches) and builds something great, without the burden of mozilla and firefox.
- pcwalton 10y ago
  > It seems like it would make a lot of sense to de-emphasize Quantum/firefox/everything mozilla is wasting their time and money on that isn't Servo. Here's how I think of it: What's the biggest risk to Servo? I think most people would answer that (besides it being a lot of work), as it's a big boil-the-ocean project, there's a lot of newly-written code that hasn't been battle-tested yet. How do we fix that? By getting early user adoption on pieces when they're ready, so we can shake out the issues. Quantum is the perfect way to do that. Of course, I happen to care about Firefox's success too, so getting great features to Firefox users as soon as possible is also a big win from Quantum. :)
  - allendoerfer 10y ago
    The competition in the browser market is much harder than for example the market of programming languages and even there big version bumps have huge costs. If you can avoid it, you don't want all your resources tied to Perl 6, PHP 6, Python 3 and so on, while your users are complaining because the usable version of your software does not improve any longer.

Manishearth 10y ago

> This sounds to me like Mozilla is getting impatient with Servo. I mean, yes. In a way. I think this was always part of the plan for Servo -- if things go well start uplifting ideas and/or code to Firefox. This isn't exactly impatience; it makes perfect sense to do this. This isn't a change in gear for Servo, though. Servo is still chugging along. There are still no concrete plans (that I know of) for a Servo product, however Servo is working on stuff that it needs for it to be a product (i.e. it's not just focused on trying out researchy ideas to be used by Gecko), like proper SSL security. So there's nothing stopping Servo from being a product in the future, and Quantum doesn't affect this. Quantum affects Servo in a couple of ways: - There are now paid Gecko engineers hacking on bits of Servo (yay!). On the flipside, paid Servo engineers (e.g. me) are working on Quantum, but for the most part this involves improving Servo itself. - Rough edges are being polished, web compatibility is being addressed for the quantum components. These were things that were always being worked on, but weren't always a priority for a given component. For example, there have always been optimizations that we knew we could do, but we hadn't done them so far since there were other researchy things to focus on. Now these are getting implemented. - The build/CI system will probably have major changes to make it possible to smoothly integrate with Gecko. This doesn't really affect goals, just the day-to-day servo developer experience. It doesn't affect Servo's goals or de-emphasize Servo itself. It just gets some of the advances that Servo has made to the public faster.

NoGravitas 10y ago

Isn't this announcement basically just saying, though, that Servo is going to replace Gecko piece by piece, rather than all at once?

zbraniecki 10y ago
Servo components will replace Gecko components Where It Makes Sense (tm). Servo will remain the place where the most radical experiments happen and once proven, will "stabilize" their way into Gecko.

bzbarsky 10y ago

Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" switch with behavior specified for both branches. :(

leeoniya 10y ago
> Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" woah! that's truly tragic. at the risk of ruining the rest of my week, may i ask where?
- bzbarsky 10y ago
  Sure. https://html.spec.whatwg.org/multipage/webappapis.html#concept-navigator-compatibility-mode https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the pieces of that spec that use it is the main place so far. There is also discussion about maybe using the same switch in https://github.com/whatwg/dom/issues/278 https://github.com/whatwg/dom/issues/278 if it turns out that too many pages assume "not webkit" means XMLDocument.load exists. It could be worse. When the ECMAScript committee discovered that parsing for function-in-a-block differs between browsers and that sites sniff and do different things in different browsers such that none of the browsers can change to each other's behavior, they went ahead and specified a "compatible subset" of behavior such that if you follow those rules you will get the same behavior in all browsers. That's fine, but if you _don't_, as web pages do not, then you're back to square 1: pages sniff and do different things. And the details are not written down anywhere, so a new implementation has no choice but to try to reverse-engineer the sniffing somehow and then also reverse-engineer the actual runtime behavior of function declarations of whatever browser's sniffing response they decided to fake. The good news is that this function-in-a-block thing is literally the worst situation I have encountered in web standards, so all the other ones suck less. ;)
Aldo_MX 10y ago
Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? Replicating other engine's bugs sounds like too much effort towards the wrong direction :/ Although, after the -webkit-disaster I don't really expect anyone to like the idea of a standards-compliant engine :(