Mozilla have been developing a programming language called Rust for a while now. Two of the things it explicitly attempts to address are removing classes of potential memory bugs (like buffer overflows) and making it easier to write concurrent multicore programs. These two traits map nicely onto the browser landscape, as most devices have 2-8 cores now and memory bugs are a perennial problem.

To capitalise on this, and to give Rust a ‘halo’ project that uncovers potential issues early, Mozilla kicked off a project called Servo to research the ways that Rust could be used to produce a browser rendering engine. This has let them explore technologies like multicore rendering of a single page without dealing with the practical considerations (tried to find a nice way of putting it ) that Gecko has scattered throughout its codebase.

After Mozilla had made some progress Samsung became interested and started contributing a reasonable amount of code. I’m not sure if this is still happening, but you can see their interest given their prediliction for 8-core mobile CPUs.

Mozilla currently have no plans to replace Gecko with Servo outright, but they are folding Servo components back into Gecko when they’re portable and have obvious benefits. Gecko’s build chain can now handle Rust and I believe the URL parser is a port of Servo code (though I’m not sure it has landed yet). I think I recall a Mozilla engineer saying that Servo had progressed beyond a research project now, and it is pretty good at rendering reasonably complex sites, but they’ve still got a long way to go before it could be a drop-in replacement for Gecko.

This is a great summary. Some very minor details that you didn't cover:

Rust and Servo were basically announced to the world at the same time, as "the Servo project." It was really important that we build Servo at the same time as Rust, to make sure that the language was actually useful at building a real practical thing. The experience of building Servo helped Rust's development immeasurably. Furthermore, it also helped Rust be built in Rust itself. There's a danger when you build a boot strapped compiler: you might make a language that's great for making compilers, but not much else. Servo made sure that wasn't true.

https://bugzilla.mozilla.org/show_bug.cgi?id=1135640 is the overall tracking bug for moving Rust stuff into Firefox. Firefox 45 on Mac and Linux will contain a teeny bit of Rust, and just got turned on for Windows a few days ago. It's an MP4 metadata parser. The URL parser has a patch, but it hasn't landed yet.

Gecko is also importing bits of Servo's CSS system: https://bugzil.la/stylo

It should be mentioned that even though they started out as one project the Rust language team has done a great job at not letting the development of the language be influenced by the needs of the Servo project.

This is not at all true. The needs of Servo have had a huge impact on the development of the Rust language. The Rust team prioritizes feedback from Rust users, the largest of which (larger than rustc itself) is currently Servo.

I believe what hobofan is implying is that the Rust developers have resisted bending the language solely to the needs of Servo, despite there originally being almost a 50/50 overlap between the Rust and Servo developers (nowadays the division is more clear, with pcwalton working full-time on Servo and brson working full-time on Rust).

The most notable example is the proposal variously known as "virtual structs" or "inheritance", which had a brief prototype implementation in Rust (circa 2013) solely to support Servo's needs (specifically regarding representing the DOM), but which met a wall of opposition from the community. Such a feature is still likely to appear sometime in the future (after all, if Servo needs it, then it's likely that others do too), but the Rust developers are taking their time to explore solutions that integrate the most cleanly with the rest of the language.

It is true in some sense, we don't just implement things Servo wants. If Rust was beholden to Servo, we would have put inheritance in the language over a year ago, for example. That said, the eventual work for "something inheritance like" is absolutely predicated on Servo's needs. But we put it on the roadmap and weight it like anything else.

That said, we do take their needs into account rather highly, just like any project with a large upstream user.

Just like we wouldn't want Rust to be useful for only compilers, "only compilers and web rendering engines" isn't much better.

Is there a plan to test the security benefits of writing Servo in Rust? Or, in other words, at what point will it be both practical and realistic for Servo to be tested in something like Pwn2Own?

Well, Pwn2Own is usually done with production-ready browsers, so I would assume Servo isn't eligible until it supports the whole web platform.

I'm not sure, as I'm on the Rust team, and not Servo; maybe someone who works on Servo directly knows better than I what plans are here.

This was an excellent summary explanation; thank you.

Externally, Firefox has become a brand. Servo is comparable to Gecko or WebKit (it is a browser engine), although it is new, not finished, and uses novel techniques.

What follows is speculation on my part. I am not a Mozilla employee.

Mozilla might, in about five years, offer a new product for desktops which features Servo, SpiderMonkey (the JS engine currently used in Firefox), and an as-of-yet undefined chrome (the UI bits around the rendered page). It may be a mobile product instead, or a product for a different type of hardware, although the current thinking seems to be to target it for desktops.

Whatever that product is, it may still be called Firefox or a derivation of that brand (as Firefox OS was), although it might have a completely new name (it worked for Microsoft Edge, after all).

(Updated for clarity.)

  > Mozilla might, in about five years, 

Since some of us in this thread work for Mozilla and on Rust/Servo, I would like to point out that this number is your own speculation and nothing official, timeline wise. Nothing the matter with that! Just don't want people to get confused.

It's a research project to build a browser written in Rust. A few components will be merged into Firefox, but Servo itself probably won't be the "next" browser.

https://servo.org/

https://en.wikipedia.org/wiki/Servo_%28layout_engine%29

(Servo team member here)

So. There's a programming language called Rust[1] which Mozilla pushed for and developed (it's now developed by a larger community, though Mozilla is still involved). Among other things, it guarantees freedom from memory safety issues and data races. Both are important here.

Freedom from memory safety issues gets rid of a whole class of security bugs (common in browsers) in one fell swoop. Lack of data races lets one write concurrent code without worrying; without needing to program defensively everywhere. "Fearless Concurrency" is what we call this colloquially, after a blog post with the same name[2].

Fearless Concurrency lets us try ambitious things like making layout parallel. Layout in browsers is the step that takes all the nodes on the page with their hierarchy (the DOM) and computed CSS style, and figures out what goes where. All browsers currently do this in a single threaded way.

Servo[3] is a research project by Mozilla. It's a browser engine[4] which does layout (amongst other things) in parallel. It's written in Rust to make this possible (and to avoid security bugs due to memory safety issues). Webrender is a (succesful!) sub-experiment to see if we can be more like game engines and do as much on the GPU as possible.

Here are a bunch of (non mutually exclusive) ways it can go from here:

- Bits and pieces of Servo's code get uplifted into Firefox/Gecko (Gecko is the browser engine behind Firefox). This is already happening[5] (integrating webrender into Firefox is something being discussed, too). This means that Firefox can get some wins without having to wait for Servo to be completed.

- Servo gets its own UI and is shipped as a new browser. A promising UI being worked on is browser.html[6].

- Servo becomes an embedding thingy to be used like a webview.

- Servo replaces Gecko for Firefox for Android: Whilst replacing Gecko in Firefox Desktop is rather hard (the two are tightly intertwined), this is less of a problem in the Android app. It's possible that Servo would have its own app that's either released under a new name or branded as the new Firefox for Android.

- Servo replaces Gecko within Firefox: Hard (not impossible). Probably won't happen.

[1]: http://rust-lang.org

[2]: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

[3]: http://servo.org

[4]: This is not the same thing as a browser. A browser engine handles the displaying and interaction of a given webpage, but doesn't bother itself with concerns like a URL bar, bookmarks, history, a proper UI, etc.

[5]: https://wiki.mozilla.org/Oxidation

[6]: https://github.com/browserhtml/browser.html

Oh how I wish Mozilla would just slap basic browser chrome on and ship the thing. Firefox used to be a fast browser, nowadays after a couple hours it takes 30s to open a new window on my 32GB machine and 10s to register a link click and start loading the page.

I am in my peer group the last Firefox guy standing, but not for much longer, I fear.

I compile Servo twice per week or so to check out the progress. It's really not ready to go as a daily browser. You can load pages, they're recognizable but generally not fully correct, the form input fields are rudimentary, and it crashes every time I go back to the previous page.

There's been one proof of concept basic chrome [1] and it wouldn't be THAT difficult to build a more robust one but I'd be much more interested in seeing it running in Electron so you could run Atom or VS Code since the domains are much more limited and rendering perf is a fairly significant limiting factor in those apps.

[1] https://github.com/glennw/servo-shell

P.S. I've never had perf issues with Firefox like you're talking about. You might want to try cleaning out your profile and if it's not that, you might have addons doing something screwy.

https://github.com/browserhtml/browser.html works fine as a basic chrome too.

Could you expand on "form input fields are rudimentary"? (I know they are, I'm wondering what part of this you're referring to). Is it the styling, lack of selection support, lack of HTML5 input fields, bugs, or something else? (I might be looking into improving these later)

The "go back" crash is something that can be fixed easily; I think we know why it happens but haven't fixed it yet (I forgot the reason though).

> Could you expand on "form input fields are rudimentary"?

All of the above except the lack of HTML5 fields. :) I don't mean to be negative, just to give reasons it's not as simple as "just slap chrome on it". I really should start contributing.

Yeah, no I get it :)

Thanks for the feedback.

I have done the profile cleaning routing (I think that's something like the defragmentation runs of old...) and disabled all add-ons except for uBlock, Reddit Enhancement Suite and greasemonkey (for a total of 3 GM scripts).

I don't understand what's up either, but I have it both on my Windows work machine with a 4+4 core desktop CPU and 32GB RAM and my Macbook with 16GB. After a couple of hours, I can type in a text-field and see the text lagging. On a 2.4Ghz machine.

I do have lots of tabs open, but since they only load on activation I doubt that's the reason. Maybe it's the Web Telegram app. It's totally frustrating that I am not even able to find the culprit if there's one since not even the dev tools have something like `ps -aux` to show what the tabs are consuming.

Granted, it's gotten better with v.45, but still I just hope something useful comes out of Servo, and soon.

Try going to about:memory to see if some tab is taking up a lot of memory. I've got this CI system where if I leave it open overnight it takes a gig or two and makes the browser unusable (Firefox and Chrome; it's a problem with DOM elements). If your GM scripts retain DOM elements for a long time (and the tabs aren't closed) that might be an issue too.

We'd love it if you submitted some profiling data: https://developer.mozilla.org/en-US/docs/Mozilla/Performance...

Is there a way to do it on the bog-standard Firefox? I can't use a nightly on my company's work machine.

Have you tried running without any extensions after having reset Firefox? The only time I've seen that where it wasn't a dying hard drive or a malware-infested/corporate IT-mismanaged system was when someone had some particularly poorly-optimized extensions installed.

I was curious & ran a couple of tests on this 2010 Mac Book Air. Normal launch time according to about:healthreport is 2.8 seconds and testing with something like `open -a Firefox https://www.google.com` when Firefox was not already running takes 4-5 seconds to finish rendering. When it is already running, it's under a second from start to finish.

On my Windows machine, firefox.exe has been running since 14th of February, and I'd estimate it takes less than 2 seconds between Ctrl+N and registering me typing in the default home page search box. Of course, Ctrl+T is much faster.

Among my extensions are Classic Theme Restorer, Cookie Controller, FireGestures, RefControl, Status-4-Evar, Tab Mix Plus, Tree Style Tab, uBlock Origin, FoxyProxy amongst several others - this isn't a lightweight installation.

Chrome isn't competitive with Firefox + Tree Style Tabs, so there's little risk of me switching any time soon.

Servo's not production-ready yet. "A good browser chrome" is not the blocker for this; browser.html is already a good enough "basic browser chrome".

I tried using Servo with browser.html and found it to be unusably slow, is this browser.html's fault or Servo's? I'm thinking it is Servo, it's too slow to just be slow javascript, it feels like my GPU isn't being used. On a Macbook

Did you use release or debug build? The perf difference in Rust between those is quite staggering

release

Please file a bug with your system specs and specifically what you were trying then. We'll try to get it triaged ASAP.

aand link it here. I tried to build browser.html+servo today on my macos and the browser.html UI feels terribly slow (while servo launched on its own feels fast).

Thanks for the report! Landing a fix for the issue (-b/glutin) right now—I had it queued but never actually got around to landing it.

Thanks, where can I run benchmarks (either the ones in your video or others) so I can compare it against Firefox? It still doesn't "feel" as smooth as Firefox, but then again that could be unrelated to WebRender.

I think it's not really ready for informal benchmarks like that. There are lots of random issues. Feel free to try various pages and file bugs, though.

Don't forget to use the -w switch to enable WebRender.

If that doesn't help, please file a bug. Getting to optimum performance with diverse hardware configurations is a slog, unfortunately, and any and all performance/hardware data is a great help :)

I'm using `gulp servo` which appears to use that switch: https://github.com/browserhtml/browserhtml/blob/master/gulpf... . Used the binary in the target/release folder... not sure what I could have done wrong.

Their roadmap also specifies how some parts of Servo might get incorporated into Firefox: https://github.com/servo/servo/wiki/Roadmap.