It was a statement that it's feasible to hold off on monoculture because compatibility isn't impossible to achieve on new engines.
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.
(Disclaimer: As always, I speak for myself, not for my employer.)
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.
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. :)
Ideally, when rewriting a large legacy app you want to take the StranglerApplication[1] approach. Netscape tried rewriting its software from scratch and we all know how that ended for Netscape[2] - Netscape is no more. Luckily, Firefox came from that whole mess. But I assume a lot of effort was lost, going from Netscape to Firefox.
In idealized scenario, Servo slowly starts taking replacing parts of Firefox. First URL parser and media player, then slowly DOM, CSS, Renderer, and finally takes over and rewrites JS VM.
The takeover is silent and gradual and user doesn't notices anything outside speed improvements. It's like some kind of silent Borg infection.
[1] http://paulhammant.com/2013/07/14/legacy-application-strangu...
[2] http://www.joelonsoftware.com/articles/fog0000000027.html
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.
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.
[1] https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/
woah! that's truly tragic.
at the risk of ruining the rest of my week, may i ask where?
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. ;)
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 :(
That's what we've done so far. We haven't exposed any Gecko- or WebKit-specific stuff that I'm aware of. We have our hands full with the standard :)
(That said, we have implemented things that are unspecified but are de facto standards implemented by both Gecko and WebKit. That includes basic things like <button> and tables…)
It depends on how you define standards-compliant.
> Replicating other engine's bugs sounds like too much effort towards the wrong direction
Well, web pages depend on those. So your options are either to standardize them or to have a standard that, when implemented, gives you a non-working product.
In practice, they're being standardized (just like XMLHttpRequest was a non-standard thing that ended up getting standardized). See https://compat.spec.whatwg.org/ and https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the bits of the HTML spec that reference it, the bits of https://drafts.csswg.org/cssom/ that mention "webkit", and so forth.
So in the end, a "standards-compliant" engine will implement those standards, which are themselves to some extent a codification of old implementation bugs; pretty normal for standards...
So far, we are (as far as I know)! We try very hard to avoid nonstandard behavior, and if we can't avoid it, try to push for its inclusion in the standard. Given that there are no users that rely on Servo, we can even wait for the standard to be changed before implementing it.
We often try to implement the standard to the word, with code that closely matches up to the standard. This has helped find tons of bugs in the standard (or in the tests). Nonstandard behavior in components shared with Gecko are off in Servo mode.
But if Servo is to be a product we probably will have to change our stance here eventually.
Servo will remain the place where the most radical experiments happen and once proven, will "stabilize" their way into Gecko.
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.
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.