Live data from Hacker News

Transitioning Firefox's rendering engine from Gecko to Servo

jensimmons.com

31–40 of 219 posts

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

#31
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 :)

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

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

#32
post #18

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.

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

If you call Firefox incredibly successful.

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

#33

Earlier quoted context omitted.

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.

Wasn't Mozilla the open source version of Netscape Communicator, rather than a rewrite?

Mozilla started as a big rewrite of Communicator 4, which was then open-sourced at an early stage. It wasn't great because it concentrated a bit too much on rewriting underpinnings (XUL, Gecko etc), resulting in a relatively poor UI.

Eventually a skunkwork project was started to drop all non-browser components and focus on user UI, and that became Firefox.

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

#37

They are still using many unsafe blocks and there was an use-after-free before :P

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.

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

#38

Earlier quoted context omitted.

No, "run" is Past Simple here. It took me a few moments to get that though.

Is that an Americanism? Ran is most common in the UK.

I think they omitted 'had' from run. The past tense of run is 'had run', 'was running' or 'ran' depending on how you want to use it after all.

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

#39

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…

Netscape as a company owned by AOL pretty much died during the process of the rewrite. Although parts lived on in the Mozilla foundation.

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

#40
post #7
post #5

Even though the title might disappoint, it's super interesting to see where Firefox is going. I can't wait for 2017!

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. Br…

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