“The colored boxes indicate which CPU core performed layout for each node”

It would be interesting if Servo could get layout time under the frame budget on mobile devices. Right now, the divide is basically "Do whatever you want on desktop, but don't touch the DOM or use any CSS property other than transform/opacity in a mobile animation" - and it misses the mark by a large margin, eg. layout on a reasonably complicated site like Google Search is on the order of 100-150ms while the frame budget is 17ms. If you could get layout on mobile to run in under, say, 10ms, it would dramatically change what web developers can do in an animation, which would potentially also change the native vs. web technology equation.

It's all about "butter" vs "stutter".

And as a Firefox fanboy, I'm sad to report that Firefox is on the latter end of the continuum. What you describe is my experience exactly -- except that it's not quite limited to mobile.

I do all my primary development against Firefox. I'm content to optimize for Gecko, and I've learned what it handles well and what it doesn't [0]. In cases where I've really doubled down to optimize some transitions, I can get almost-butter from Firefox, where Chrome and Safari are pure pleasure, seemingly no matter what I throw at them. Hell, even IE 11 is better when it comes to transitions.

That said, I think Gecko looks the most beautiful for static rendering. This is less true since Chrome 38, which supports proper web font rendering for Windows, but I'll maintain that Gecko's compositor output still has a certain je ne sais quoi compared to everything else.

Still, as a developer who "wants the web to win," [1] it's troubling to me that the vendors with native platforms are still outperforming in the browser space, and I hope that Servo is the dark horse that will change all that.

[0] For instance, I've read this thread one too many times: https://bugzilla.mozilla.org/show_bug.cgi?id=524925

[1] Quoting http://jlongster.com/Radical-Statements-about-the-Mobile-Web

I've noticed the Gecko vs WebKit rendering difference as well. I never bothered to look into exactly what it was.

Heh.

That wasn't intentionally a joke (I wrote that bit), but I can see how it sounds like one. "chrome" is a term for the stuff that's part of a browser but not the browser engine (the rest of the UI).

I did realize that that term could be misinterpreted (damn you Google) and thoought of alternative ways of putting it, but I couldn't come up with anything. "GUI" and "shell" both sounded wrong.

When I said "another" I was referring to MiniServo[1][2] and the CEF port.

[1]: https://github.com/pcwalton/miniservo-mac [2]: https://github.com/metajack/miniservo-gtk

Note that the contributors are from a period of three weeks (due to other commitments I ended up postponing/procrastinating this blog post for two weeks). But yeah, we usually get a lot of new contributors -- around 4 a week, with around ... 20% retention? (mostly guessing from observations). Still pretty nice given our size.

I'll attribute this to a couple of things:

We actively maintain a list of [easy bugs](https://github.com/servo/servo/labels/E-easy). This also means holding off on fixing minor things. For example, if I'm working on a feature I might notice some things which can be fixed, or have some portions of the feature that are easy to implement but can be excluded from the main pull request without losing out on much. I'll file E-Easy issues and land the basic pr, and those small changes will be something a hopeful new contributor can pick up and work on. Resisting that itch to fix all the things gets us a good crop of easy bugs. We don't have many string substitution easy bugs[1] unlike projects like Firefox, but most of the easy bugs can be worked on in an hour or two given a Servo build and basic Rust knowledge. Usually less than that.

Additionally, we do easy bugs right. There's almost always enough information to help a newbie get started; with links to the relevant code and/or spec. Of course, there's a lot we can improve on here, but we're still ahead of the curve on this.

We also mentor newbies -- if you leave a comment on an issue asking for help (or drop in on IRC), someone's bound to help you.

We consciously consider newbie onboarding, too -- "will this affect newbies?" is a common issue that springs up in discussions. It helps that many of the core contributors (including me) are volunteers themselves.

Our code generally isn't too complicated. Most of the areas which newbies flock to (eg the DOM) are well documented and we don't have much usage of advanced, confusing looking Rust features. I've seen open source code heavy with template metaprogramming and all sorts of strange macros --- whilst our code does use macros and syntax extensions, it looks pretty clean and to the most part the strangeness is innocuous (eg the annotations and other strangeness look ignorable). To be fair, this is probably highly subjective, but to me Rust code is generally quite readable, even when it uses advanced features -- it was this way when I started, too.

Also, we have Josh[2] :) He is behind most of the mentoring system in Firefox and is in general very interested in easing the way for new contributors -- most of the stuff above probably was largely his initiative. If you want ideas on how to improve newbie onboarding on a project you're interesting, you might want to have a discussion with him (or Ms2ger) in IRC.

[1]: I'm really fond of such bugs because they make for a very smooth transition for those trying out open source. For the first bug you do some easy thing like editing a string or deleting a comment or renaming a function, and get used to the version control system, issue tracker, and the workflow. For the second bug, try something more substantial; you can focus on the code this time without worrying about other things. [2]: http://github.com/jdm