Not sure if it is still true but a few months back (6 maybe?), there was a post on HN about contributing to Servo where OP said that he found it easy to contribute despite the fact that he didn't have prior experience in rust. As this post mentions, the code base is relatively small and a lot of simple features were still missing, at least back then.
> OP said that he found it easy to contribute despite the
> fact that he didn't have prior experience in rust
Just yesterday I was talking to the person who contributed WebGL support to Servo (a relatively recent and substantial patch), and they reiterated this sentiment. It was their first time ever using Rust, and although they'd reluctantly done some C++ in the past their primary programming language is Javascript. They were pleasantly surprised at how easy it was to contribute such a large patch, and had bountiful praise for how well-organized the codebase is. The patch actually bounced a few times, and they were also very pleased at how the core contributors continued to work with them over the course of days to track down the breakage and keeps things moving.
This person's primary interest is in virtual reality, specifically WebVR (http://webvr.info/), and given Servo's incredible benchmarks so far they're very optimistic about its ability to advance the state of the art of virtual reality on the web.
Their biggest complaint was build times. Yeah... we're working on that. :)
Nope, in the blog post I was referring to the author went to some event (in France, I believe) where some of core contributors helped him, if my memory serves well.
Last week I tried my hand at putting vim functionality into servo, a la pentadactyl.
It's not even close to being ready. Even rendering a simple page like hackernews is broken.
That's not to say I am not excited for this. I think servo will be huge and I think it will see widespread adoption. It's just that with all the news we hear about it, you might be lead to think that today it's competing with webkit. It's not. Soon, though.
The stack of web technologies is staggeringly enormous. It may not feel like it just scanning over a simple HTML page, but it is, and there's a lot of invisible-yet-critical stuff like proper same-origin policy enforcement. The miracle is not that it takes Servo a while to be created, it's that this stack works at all, and that they're even trying!
Couldn't they just do something similar to Microsoft's Edge/IE11 approach? Servo for HTML5+/CSS3+/Javascript ES6+ and then keep Gecko as well inside Firefox for "legacy websites"?
HTML5/CSS3/ES6 define how to process legacy content as well as current — the only actual branching for versions is quirks mode and that has relatively minor effects which aren't that much code to implement.
Edge should, in principle, support everything, including legacy sites (at least as well as other browsers do today). Trident is only being kept around for sites that do extensive UA sniffing and rely on obscure behaviour — and pretty much only for the intranet.
Gecko is not exactly separable from Firefox (unlike Blokc/Webkit and I'm guessing Trident/Spartan). The firefox UI depends heavily on things like XUL and XPCOM and whatnot which are nonstandard features in Gecko and would be a pain to support in Servo.
I guess you could run two browser engines -- one for the UI, one for the content, but I'm not sure how well that would work.
FireFox using some libraries written for Servo is a nice deviation from that.
The sheer amount of work involved in getting Servo to a usable state should be less surprising when you consider that all of the browser engines in current use date back to the 90s in some form (1997 for Gecko and Trident, 1998 for KHTML/WebKit/Blink).
Not only that, but Servo is experimenting with new techniques for just about everything as they go. Progress may seem slow if you measure how "done" it is, but it's much faster than other projects if you measure how much research is being produced.
The parallel algorithms that Servo uses to implement advanced features of CSS are, as far as I know, novel (block formatting context size speculation, float impaction detection, absolute positioning traversals, parallel automatic table layout, parallel border-collapse).
There have been academic papers on parallel CSS layout, actually, and my Servo work extends that state-of-the-art. But I've got my hands full with hacking :)
Hacker News is surprisingly un-simple, due to extreme reliance on <center> (the major remaining broken thing, with annoying interactions with CSS) and automatic table layout (very complex).
To add to this, Hacker News does not display well in either Chrome for Android or Firefox for Android[0], so it's not like it's only Servo (or even only Firefox) that has issues.
That's a feature ("font boosting"). It's a total mystery to me how something working so badly could ship, especially since the Android Webkit fork had a similar feature working perfectly. But apparently it's of "acceptable quality" in Chrome https://bugs.webkit.org/show_bug.cgi?id=84186#c24
The basic problem is that it's hard to tell the difference between nested tables used for nested tabular content and nested tables being (ab)used for layout, as HN does.
Mobile browsers attempt to make content more prominent than navigation. This matters a lot on e.g. mobile news sites.
Unfortunately the algorithm they use breaks horribly on comment threads, because it decides that long comments are content, while short comments are not important. (At least, this is my deduction from seeing it in action.)
You'll see it on reddit, forum threads, and here on HN -- so this is not exactly a layout bug, but a problem with how Firefox/Chrome try to apply some simple semantics to web content.
Sadly true. That's why I'm not using Firefox on android despite using it on the desktop. They never got the right algorithm for font inflation (that's how they call it).
HN displays ok in Opera Android but mostly because Opera can reflow text on zoom. That fixes almost everything.
The Servo team plans to ship an alpha-quality release later this year, and my entirely amateur opinion is that Servo will be ready to compete with Webkit by 2017. Place your bets...
I'm really curious how Servo (and Electrolysis which I know is un-related) are planning to handle the GPU. Most GL drivers if not all of them are not multi-thread happy.
Are they implementing an internal command buffer like Chrome or is there some other solution that allows multiple threads and/or multiple processes to all output content to the same window?
You shouldn't. They're specifically titled data structures and functions inherent to various specific (some to a given platform) compositors, display servers and graphics libraries. You memorize them as you go, but it's the ideas that are more important.
Obviously X11 will not just disappear, but is targeting Servo at X11 at this early stage in it's development like writing a Python library targeting Python 2?
Well, when I wrote this stuff for the first time a couple of years ago, NVIDIA's official position was "we have no plans to support Wayland". Even now I suspect X will be around for years.
I will be the first to cheer X's demise, as we've had so many problems with multithreading and X, but we have no choice right now.
And it's working? All my experience with multiple threads on different contexts is crash, crash, bug bug bug. I'm surprised it's stable at all on any platform.
What is the current goal with Servo? The last time I felt well informed, I think it was described as just a research project, with zero intention to ever supplant Firefox. Is that still the case? There seems to be an awful lot of promise and effort if there's no plans to make it a production ready browser.
So, it's definitely no longer "just a research project," but the challenges of finding initial product targets and building out the rest of the Web Platform are definitely large ones!
If Servo becomes the default layout engine for Firefox, I really hope that having one more engine in the mix forces everyone towards standards compliance, or at least uniformity. Obviously, they're still working out basic functionality, so they've got a way to go before that becomes a concern. But if the project is successful, it's going to be one more browser type for web designers to worry about. Either that or Servo's multi-threaded speed and safety are so awesome that all the major browser developers decide to ditch their own engines and everybody settles on Servo.
One fun thing about reimplementing the Web Platform is that you run across all of the spec holes (particularly in much older features, like tables, borders, etc.). Where possible, we're trying to at least determine what current browsers do with the intent of codifying those behaviors in the specifications and W3C cross-browser test suite.
That said, if Trident/Edge, Webkit/Blink, and Gecko don't all agree on the implementation of an older feature, we know that it will be a challenge to find middle ground and get things changed and the spec updated to anything more than softer statements using, "MAY."
I have a feeling Servo will finally make me give up Chrome. From what I've seen so far the performance is very impressive [1]. I just wonder if Elecrolysis will ever arrive. It seems like I've been waiting for it forever. Chrome's sandboxing is great for security and performance purposes and I can't give that up (I never seem to have a problem switching to another tab even when I have 40 of them open in Chrome, while in Firefox the whole browser "hangs" sometimes when I load a heavy tab).
I haven't really had the problem you're talking about in Firefox as it is, but you can try it out and see if Nightly is any better. Keep in mind that Nightly is slower overall than Firefox, because it has a number of debugging flags enabled that impact performance.
Obligatory disclaimer: Nightly has lots of bugs and quirks compared to Firefox, so it should not be considered indicative of the normal Firefox experience[0]. Also, many extensions have not yet been ported (which is why it's available in Nightly for developers before hitting Firefox).
I know it's in Nightly, but wasn't it in Nightly 3-5 months ago, too? Shouldn't it have moved to the "next" development version by now, like Aurora or whichever is the next "more stable" one, if Firefox follows a 6-weeks development cycle?
Not every feature can be completed in a single six-week train, especially one as complex as rewriting huge chunks of a browser that was not initially designed with process separation in mind. :)
That said, we should have a go/no-go on Monday for uplift with Firefox 40. We're getting Very Close Now. :)
If we do the uplift, I believe the plan is also to hold there until we clear out a bunch of less-critical, but shipping-blocking bugs. So it might be on Aurora for a few releases.
Electrolysis isn't a Servo thing but a Firefox thing. Something that many of us have been waiting for also. From what I've seen with the way Servo works, it should be working in basically the same way from the beginning but I'm not as confident on that as I'd like to be. Since it renders and works on each iframe in another thread and each tab is implemented as an iframe with mozbrowser extensions I would think it should fix that problem.
FWIW in Servo when talking of multiprocess stuff we colloquially call it "Electrolysis". I think Patrick has some work in progress on this. It's not as much work as the Firefox e10s (we already use threads and channels for everything), but I think there is some (relatively) minor work to be done.
how do you handle component sandboxing in Servo compared to firefox e10s? (firefox being child process sandbox, ipc to parent, and things being a little "unperfect" in the separation)
The plan is to use gaol [1] for sandboxing. For IPC, we want to send Rust objects serialized via serde [2] over native OS IPC pipes (AF_UNIX sockets on Unix).
that looks nice
i hope the separation between processes themselves will be nicer than firefox (or even chrome) since its "from scratch" :)
(ie that it wont be remoting everything and only protect the system from escaping a child - makes sense in firefox/chrome, less with rust being the compiler i guess)
I suspect that if servo doesnt try to be an OS like firefox/chrome do, a whole process sandbox may even be fine enough. But if it does.. :)
It does look like amazing performance. But It may be too early too conclude on that point. The gain of performance may only be because of less feature implemented in servo leading to less thing to compute => less computational time.
I never experience that in Firefox and have much more than 40 tabs open. Granted if the tab is not actually loaded, then it will go off and load it. How does Chrome's model help here?
Could servo-shell be used to implement a keyboard driven browser (a la dwb)? Looking at https://developer.mozilla.org/en-US/docs/Web/API/Using_the_B... it looks like the API does only offer few interaction points with the underlying iframe or shouldn't that be a problem? Can the browser html intercept all key presses and change the iframe content to display follow links, for example? :)
That might be a great way to finally have a better keyboard driven solution (since, i think that the browser addons like pentadactyl suck very much).
No concrete plans for now. JS is complicated, and we don't have enough people to do that. Relying on a JS engine that's currently being used (which we know will get security updates) is much better than rolling our own, for now.
The js engine is separate from the rendering engine as far as I know. There might be some exciting new js engines written in Rust, but I don't think they would be part of Servo per se.
I would think a JavaScript engine would be done better on a different domain specific language than Rust. It seems that a virtual machine has a different set concerns to deal with than a rendering engine.
You must have lower standards than the Servo team, because pcwalton is rather irate at the current build time. :) Rust will be prioritizing massive advances on compilation speed for 1.1 and beyond.
Just some very unscientific tests: loaded a few sites on both Servo and Chrome and compared the effects of resizing their windows. For instance, the frame rate looked about the same on Wikipedia, but Servo struggled on Reddit.
Is Servo running on Windows? The comparison could be more precise on my 120hz Windows box.
I really like how this sounds. I just really hope CSS is implemented with great care and detail. Right now - Firefox and IE has a lot of quirks, and I only find WebKit and Chrome to have it working well. I've been doing CSS intensely for over 5 years, happy to give my feedback along the way.
Not sure if it is still true but a few months back (6 maybe?), there was a post on HN about contributing to Servo where OP said that he found it easy to contribute despite the fact that he didn't have prior experience in rust. As this post mentions, the code base is relatively small and a lot of simple features were still missing, at least back then.
Bugs Ahoy is a handy tool for finding easy issues in Mozilla projects but seems to be down at the moment http://www.joshmatthews.net/bugsahoy/?servo=1