Live data from Hacker News

Transitioning Firefox's rendering engine from Gecko to Servo

jensimmons.com

91–100 of 219 posts

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#91

This seems apt: https://www.joelonsoftware.com/2000/04/06/things-you-should-... Mozilla spending time on this suggests Mozilla doesn't know what to spend time on.

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…

The complete rewrite wasn't initially too good either. It took them years to bring it on par with Netscape 4.7, warts and all.

I've been in a talk of a mozilla developer like a decade or more ago, shortly after they had released the rewrite. His comment on starting a project like that from scratch: "don't". What they intend to do (slowly and gradually transition to Servo) seems consistent with an organization that has learned from this experience.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#92
post #45
post #8

The submission title has been changed from "Replacing the Jet Engine While Still Flying" to "Mozilla’s project to replace Gecko with Servo" (at the time of this writing). Some of the other comments are pertaining to the "Jet Engine" title. For anybody that might be confused, like I was :)

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 increasi…

To put servo into production and let it face attackers would be a profuse test for the viability of the memory safety claims.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#93
post #31

Earlier quoted context omitted.

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."?

I genuinely don't get all the hoo-haa about titles. In pretty much every comments section I read here, there will be at least one person who complains that the title is "linkbait" or (more often) "clickbait" - even the most boring, anodyne description of the article. They're not allowed to seem interesting in any possible way. The original title wasn't particularly descriptive. That doesn't mean it was misleading, an…

On the HN frontpage per se, titles are pretty much the only content, so the bias is obvious.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#94

What do folks think of internetisms that the author uses like "Because Mor Better Ideas™."? I see a number of engineers use broken phrasing like that in posts and presentations and it comes off really badly to others not in on the "joke". Does anyone really find that sort of thing actually funny or additive or is it the equivalent of trite office humor gone online?

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.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#95

What do folks think of internetisms that the author uses like "Because Mor Better Ideas™."? I see a number of engineers use broken phrasing like that in posts and presentations and it comes off really badly to others not in on the "joke". Does anyone really find that sort of thing actually funny or additive or is it the equivalent of trite office humor gone online?

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.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#96
post #82

Is this an announcement of a change in strategy? I'm a big fan of rust and Servo, but my understanding was that it's still "experimental" and they're learning stuff about concurrent rendering and stuff like that, with no concrete plan to use Servo in Firefox (or make Servo a standalone, supported browser). I know there's a few odds and ends in Firefox that use rust, but I thought the future of Servo was still ambiguo…

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 re…

While writing a browser in Rust might not be, per-se, particularly experimental anymore, nobody has written a browser engine from scratch since KHTML in 1998, and with the growth in complexity of the web since then it's unclear whether one can write a new browser engine from scratch without spending years reverse-engineering the competition—we've come a long way in the past decade in better defining many historically undefined fundamental parts of the platform, particularly in HTML5 and CSS2.1. At the same time, there are still parts of the platform that remain largely undefined.

Apple's work on WebKit for several years after forking KHTML was essentially just reverse-engineering IE and fixing site-compatibility bugs; Opera had maybe 10% of all people working on Presto up until the end largely reverse-engineering the competition and fixing site-compatibility bugs; etc., etc., etc.

That's not even the only interesting question: nobody has tried to parallelise layout before, and how does that interact with things like the Grid Module? How about Houdini?

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#98
post #75
post #45

Earlier quoted context omitted.

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 increasi…

Well, you can write individual components in Rust and put them into Servo and then refactor the existing C++ to make it modular enough for those components to be replaced by the Rust version. Then eventually you'll be able to replace enough components that it's all Servo, and no Gecko. At that point Servo will be functionally complete, as its individual components will be on par with the Gecko components.

I think it's unclear whether everything will get replaced by Rust components from Servo: certainly, smaller components are likely to get replaced, but larger interwoven parts are obviously going to be far harder to replace. I suspect not all of the Rust code that replaces the old C++ code will be from Servo: some will be written specifically for Gecko.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#99

Earlier quoted context omitted.

It's not going to change that. No matter how efficient you make the JS engine, crappy JS will still steal all your ressouces.

Yes. However, a crappy, leaky, JS engine running crappy JS code will steal all resources even quicker. I hope a JS engine built with Rust smart ptrs will be less leaky than one built in C/C++. In my experience, hand rolled memory pooling systems can be very leaky.

There's no plan to write a new JS engine at Mozilla, FWIW.

Re: Transitioning Firefox's rendering engine from Gecko to Servo

#100
post #61

Makes me wonder what's going to happen to Presto now that the Chinese bought Opera ASA...

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

And in principle is still supported in some embedded devices, AIUI.
Post reply on HN