Transitioning Firefox's rendering engine from Gecko to Servo

A good way to force this along is to have a champion for the work, and an automated burndown metric that random devs can watch and influence.

Mozilla is pretty good at the latter, cf. https://arewefastyet.com

One big problem I find with these transforms is there always comes a point where something, for a while, has to get a bit worse. Either a bit slower, or some features disappear.

Now I try to ensure we agree up front which issues will be blocking, and how much extra memory / CPU is acceptable, which features have to be kept, etc.

But... Firefox itself was an example of a different approach to a transition, it started as a re-implementation of a clean, simple browser when Mozilla was getting pretty stale. The same approach could have been taken here... Firefox does feel a bit long in the tooth to me these days...

> If you're not careful this can drag on for years with half the stuff done

Exactly. I would suggest to focus on Servo and a HTML based UI, and take some ideas from Vivaldi browser (which has an HTML5 UI). Firefox needs a "reboot", like Firefox was a leaner reboot of Mozilla Suite - but as Mozilla Suite back then, Firefox got too bloated.

Mozilla is really just another software company owned by a nonprofit. They have hundreds of millions in revenue and have been "profitable" in many/all years. But they are definitely much smaller than Google/Apple/MS and can't benefit from ecosystem lock-in effects.

I really love seeing new folks get on board with Servo itself, but there's something else that's equally important: the Cargo ecosystem. Servo is built with Cargo and incorporates a lot of code from the Rust community. Likewise, we try to make our standalone Servo pieces available as Cargo packages on crates.io when we can. We take code from the broader Rust community and give back in turn.

In this way, even folks who have no intention of hacking on Servo can effectively end up contributing to the project. And, by the same token, we also in effect contribute to lots of projects in the Rust community.

Note that most of the recent Rust "marketing" articles have nothing to do with Mozilla and weren't a coordinated effort (https://news.ycombinator.com/item?id=13325196), it just sort of happened.

This specific article is by Mozilla from the Developer Relations team, so you might call it marketing, but there hasn't been such an article from Mozilla for quite a while now.

But yeah, I agree, Rust will make it easier to contribute to Firefox IMO. We have a lot of contributors on Servo.

You are still on KDE 1?

One could argue that Trident (or EdgeHTML as partial fork) is still in wide use, and this started with IE4 in 1997.

> KHTML (the origin of webkit and blink) was started in 1998, only a year after Gecko. Of course, probably not much (if any?) of the original KHTML source is still present in webkit

At least this part is still there: http://www.hanshq.net/roman-numerals.html#khtml

Original Opera engine started somewhere in 1993, last update to Opera Classics was year ago.

I remember using Konqueror+KHTML much more recently than KDE 1.0 too :-). At one time it worked quite well.

> I have animations that run at a smooth 60fps in Chrome and Safari effortlessly, quite often producing 1-2 FPS in Firefox.

Can you give an example? I'm sure Mozilla's animation people would love to hear about this.

It's called Project Quantum, they announced it a few months back, as a formal project to integrate Servo components into Gecko.

I think calling Servo "experimental" is still somewhat confusing as it stands today. I think the initiatives to implement engine in Rust is no longer an experiment. The language has gained some serious production attractions in the last year or so as Rust reached 1.0. While Rust isn't as "popular" as Go, Rust community is strong.

I think however it is better off to interpret that Mozilla is getting more serious on replacing many parts of Firefox in Rust. Mozilla already started doing that last year [1].

[1]: https://hacks.mozilla.org/2016/07/shipping-rust-in-firefox/

Correct. That's why it's such a massive task. Servo is pretty decent at supporting a lot of web standards now. Unfortunately, the real web is made of quirks and implementation targeting workarounds.

I think the biggest lesson from Servo is that entry barrier to the web market is already much higher than we would like it to be.

Having a great new web engine supporting 100% of web standards does not get you even close to being ready to serve the web.

And the willingness of web developer community to take the "one browser only feature" bait is a major part of the problem.

I for one hope we're getting better at that: we're sharing more tests across browsers than ever before, and I think that's quite possibly going to end up being the de-facto norm for all new tests this year.

Of course, that doesn't mean that we'll get rid of all bugs, but it does mean that more bugs should be found before shipping.

(As a disclaimer: this is essentially the majority of what I've got paid to do over the past year-and-a-bit.)

That has two problems:

1) A lot of flight tests can't be done without a large fraction of passengers on the plane.

2) It may make getting to the final end state faster (though maybe not), but it means you don't get any benefits until you make the switch. Doing things incrementally means you start seeing benefits much earlier. Classic throughput/latency tradeoff.

Looking forward to it too; this is a big deal because it will put a Rust implementation on many millions of desktops. I'm totally fed up with CPU and memory hogging browser bloat on my laptop. My dev env runs so much better when I kill all Chrome processes. I know that the article is only talking about the render engine, and not JavaScript, which I suspect is the main browser bloat culprit , but I'm still hopeful. Bring on the Rust JS engine I say!

Yes. But the point is any unsafe code can be reviewed separately and be subject to more stringent checking than the majority of code which is safe.

I've been looking at the HTML parser they are writing (servo/html5ever) which is incredibly impressive and parses the hideous Daily Mail homepage in my tests in < 30ms. It uses the tendril library which contains lots and lots of unsafe code, but this library is set out to do a very specific thing which is make parsing strings much much more efficient. This is a design tradeoff that is desirable; as long as tendril can be shown to be robust it's a good decision over a slower parser.

The use after free basically had to do with spidermonkey, which has a GC, and is not 100% safe to use in Servo (we try to make it safe).

The quantum projects don't involve moving Servo's DOM into Firefox (they do involve implementing lessons learned from Servo's DOM, but not the DOM itself), so this isn't an issue.

Presto was only still being used in Opera Mini, it had been swapped out for Blink in the desktop and full-fat mobile versions.

I enjoy reading words which indicate the person who wrote them is not entirely dead inside. It provides, i feel, for a Mor Better Reading Experience™

I think it shows who the author had in mind while writing the piece. If you use memes etc. then you are writing for an 'in crowd' that understands the same cultural references as you. That's OK, but you should be clearly aware of it.

The one thing I would have appreciated from the post is for the author to have written about the "Mor Better Ideas" that make Servo better than Gecko.

To me that particular phrase in this particular post is a little out of place and lowers the tone slightly. I expect that to others it will be seen as fun/human and indicating that the post isn't written by a corporate drone.

YMMV

It's annoying and unprofessional. Stop trying to be cutesy and present the information in a way that people who are busy can consume quickly and make decisions on.

Is this the tone of the whole project? I'd love to contribute, but I don't want to wade through a reddit-comment-thread-level of forced references and memes to do that.

I get the reason for doing it, and I like that the internet isn't full of drab corporate-speak all the time, but this piece just missed the mark I think. The title doesn't really communicate the intent well and instead feels like its trying to be a little clever for the sake of being clever. It's really a two or three sentence press release that got fluffed up with some non-corporate language.

I've been annoyed by the capitalization and (TM) thing since I first started seeing it on slashdot (maybe it was fish and chips then) in the late 90s. But live and let live. At least we've dropped the micro$oft thing.

Contrast "this should be done better" against "this should be done Mor Better". The intention, I think, is to be less abrasive and "something else". Really I'm not even sure how to describe it, which I think is actually why people use such formulations; it does add at least some connotative meaning which is hard to express explicitly.

Basically, I do find it "additive", but it's obviously only feasible in very informal contexts and the percentage of the audience for whom it is not additive (and possibly quite jarring) might be quite high.

It's a bit like sarcasm, even if less grumpy. But unlike conventional sarcasm, which is both best (as in enjoyable to the type of person who enjoys sarcasm) and worst (as in completely defeating communication for those who don't) when it is borderline unrecognizable, these "internetisms" don't need to play hide and seek to be good at what they are. In the servo post, extra capitalization and an ironic "™" is used for tagging, but if one ever felt the need to further reduce subtlety, any amount of emojis or "funny" typography could be added without diminishing any quality it might have (or exacerbating lack of quality, depending on where you stand). What I try to establish: amongst colloquial witticisms, this pattern is probably one of the most harmless ones.

Do I personally like it? I sure would not say that I love it, but I do enjoy reading texts that are less impersonal than a press release. Patterns like this can help identifying them, so I tend to be happy when I see them. What I hate, and I feel tempted to claim that all of humanity is with me in this, is when these patterns are used to engineer press release type communication into appearing like something different.

Does that mean that the original title was bad, as the HN guidelines states, "Otherwise please use the original title, unless it is misleading or linkbait."?

Unfortunately the new title seems to be misleading in a different way. There is no "project to replace gecko with servo". There is a project to advance gecko so it is state of the art in browser engines. Much of the current state of the art has been developed in Servo, and the natural way to bring that technology to gecko is to integrate the components from servo directly. This has other nice properties like increasing the Rust-to-C++ ratio, which we believe will be a win for safety and maintainability. But it is nevertheless components, rather than the whole shebang. Servo, for example, only just got document.write support and still (as far as I know) doesn't have a correct representation of document history. So it is some way from being a production grade engine for use on the general web.

Why is the title back again?

No one can understand what the link is about with just engine and jet as nouns in the title.

If performance is not competitive, it will not be much of a success story, but it will be more interesting to see how much better it will be in terms of security issues.

Not if in the process they'll make all the existing add-ons incompatible and therefore lose all their remaining market share.

The story changed its title from being about Gecko and Servo to this literally in between me viewing the frontpage and clicking on the comments link.

This story here is IMO should be extempt from the "original title" rule - the original title is annoyingly misleading.

Some piston-engined aicraft had crawlways in the wing to permit inflight engine servicing ( Ju-90, XB-15 and B-36 come to mind ) but sadly I'm unaware of any jet aircraft with such a clever feature. Potentially the YB-49 flying-wing but I haven't located a cutaway to confirm.

Me too! I was like "Whoa that's a novel idea...and it is about browsers...damn!" I was already conjuring up crazy scenarios similar to in-flight refueling.

Same here. was click-baited to another Rust article :D

Yeah, talk about setting people up for a letdown. :) I was expecting some insane experiment from the golden era of aviation.

> Wouldn't it be more appropriate to have written rust in a GPU language like OpenGL or OpenCL, since the aim here was to replace the display engine?

That's not the aim of Rust. Rust, according to its own website is:

> Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

Servo makes incredibly good use of the GPU. Being able to do that, and iterate so fast on that work, is part of what Rust brings to the table.

(I don't think they've swapped out the font renderer and image codecs yet, but there are quite a few bits and pieces they have swapped out as the Rust community delivers more pure Rust libraries.)

Servo is not a "display engine". The term is "rendering engine", but that's an inaccurate bit of terminology, most of what a rendering engine does doesn't actually deal with rendering. A better term is "browser engine".

Parsing, styling, the DOM, running JS, handling networking, computing layout are all things that a browser engine does that don't involve rendering. Many of these can't be done on the GPU, and for others the GPU brings no additional benefit because it's not the kind of load the GPU can magically parallelize.

Servo's rendering stack does make extensive use of the GPU. https://github.com/servo/webrender/ (talk by patrick in https://air.mozilla.org/bay-area-rust-meetup-february-2016/) There's also work on glyph rasterization on the GPU going on right now.

This is a misunderstanding of what a rendering engine does. It operates on at least two layers:

1. On the CPU, architecting the drawing commands and resource management for the GPU

2. GPU programs (in the form of API calls, shaders, output buffers, etc.)

Generally speaking, part 1 is not the resource-intensive part unless you also have to run an intensive algorithm on the CPU. If you see the renderer as a synthesizer unit, the CPU is the number of user parameters you have - the number of knobs and switches and sliders and patch points. You would typically only have a few knobs to turn, if you were writing a custom renderer for your application. But a complex, general-purpose renderer like that of the HTML DOM is more like a wall of patch cables; and within that, the Servo renderer found opportunities to make "risky" optimizations that parallelize, make tighter use of memory, etc., but many of them are only reasonable to do from within Rust, because of the additional checks it can perform.

Actually, it's already there. Has been since last year.

What is your complaint, exactly? Considering it includes support for almost total customization of the user interface by third-party code, I think they've done an excellent job with the UX.

Mozilla was a rewrite of Netscape and Firefox was a restructuring of Mozilla.

The only reason they still exist today and have relevance is their willingness to rewrite.

I don't disagree with Joel - but his main point seems to be - be prepared to spend longer than you expect on a rewrite - that doesn't mean you shouldn't do it.

Others have pointed out that Netscape's rewrite gave us Firefox, so the rewrite was incredibly successful.

Ironically Mozilla is the best counter-example to that Joel on Software article.

The article specifically mentions that Netscape shouldn't try and re-write their browser. But if they hadn't done that, we wouldn't have Firefox. We'd still have an incremental improvement over Netscape 4.7.

For those who can't remember Netscape 4.7, let me remind you, it wasn't very good at the end. If they hadn't rewritten it, causing Joel to write that article to tell them they were wrong, there would be no relevant browser called Firefox today.

It seems you either haven't read or understood either Joel's article or this article.

They are going for small incremental changes, instead of rewriting code from scratch, which is what Joel warned against. They aren't saying, fuck Firefox, replace it with Servo. Instead the idea is use Servo as a way to discover better layout, rendering components and transplant it into Firefox.

See Strangular Application pattern

http://www.martinfowler.com/bliki/StranglerApplication.html

> I guess we could land the plane, let all the passengers disembark so they can wander over and take other planes, and not provide any service for a while while we change the engines out… but no — no, we can't do that. Not gonna happen.

> We could keep flying the current plane, while starting from scratch and building an entirely new plane on the ground — special ordering every nut, every bolt, designing a new cockpit, and waiting many years before we to get to fly that plane. But we don't want to do that either.

Mozilla is exactly following Joel's advice.

Joel's article is about doing everything from scratch, while if I read it correctly the article talks about doing things in-place, alongside normal use and development.