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.
[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.
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.
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.
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.
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.
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.
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
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, 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 :)
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