On 2016-05-13 8:44 AM, Nicolas B. Pierron wrote: > On 05/13/2016 12:04 AM, Ehsan Akhgari wrote: >> On 2016-05-12 9:53 AM, Nicolas B. Pierron wrote: >>> The more we empower people for working only on their domain(s) of >>> expertise, the less we would have need for such heroes. Having persons >>> responsible for the integration would help us on that. >> >> As someone who has worked on many parts of the browser, I cannot >> disagree more. Bugs just don't tend to align themselves within >> someone's "domain expertise". I think of bugs which seem to only >> require me to only remember knowledge that I have accrued over the years >> as "easy bugs", and the more I learn about different parts of the >> browser, the more I come across issues that touch on the things that I >> have never learned about before, or things that I haven't learned well >> enough. Those I call "normal bugs". >> >> Also bugs are only one part of our work. I have found out that the more >> parts of the browser I have learned about, the more I have been able to >> work on "cross-functional" things that have benefited the browser as a >> whole, and nowadays these sorts of stuff are commonplace projects that >> we're working on. Take e10s as an example, that project doesn't map at >> all to any of the islands that we have created in our organization >> and/or code base. We need more and more people to be able and willing >> to step out of the little islands, as the whole world has grown much >> smaller now and the islands that maybe we created for good reasons back >> in the day are really just an artifact of the past. > > Yes, e10s is the greatest example to highlight the difficulty which > arise from the coupling of components. How many years did we loose > failing at making it a reality? And now, we only manage to make it a > reality by taking various specialist out of their domain of expertise > for multiple years, before being able to achieve something which comes 7 > years[1] (more?) too late?
When you count the number of years, you should consider things such as canceling the entire organization wide project for a couple of years, and also the shift of focus from Fennec to desktop and then focusing on parts of the multi-process implementation needed by b2g, etc. It's not like we spent 7 years only dealing with the coupling between our code's component. Also, a large portion of the effort was needed because our front-end is tightly coupled with Gecko, and that is one of the couplings that has proved to be hurtful over the years (part of the proof coming from the e10s project experience.) > e10s involves keeping multiple coupled components working as expected. > Not having such coupling, would have made the project simpler, and I > think b2g multi-process is the best way to highlight this. Thus this > problems could have been solved as a per-component bases, with > specialist from each team. The b2g multi-process support happened faster because a) a large portion of the platform team was tasked to prioritize it and b) because there wasn't any existing code that we'd need to keep supporting, so it's not really an apples vs apples comparison. The loosely coupled set of components creating a browser engine was where we were a long time ago, and the reason why we moved away from that model was that over time we realized that it causes problems for us that we couldn't solve with keeping things loosely coupled. Another thing that has changed since that time is the sheer size of the functionality that a browser has to support. Given that the old architecture wasn't working well even back then, it's hard to imagine how it could work better today. >> The current reality how web browsers are made don't afford us treating >> our codebase in that way any more. To me, discussions around unifying >> the coding style drill into the heart of this problem: we need to move >> on from having small compartments with people painting the walls to >> their heart's content, and treat the browser as the one unified beast >> that it truly is. […] > > When I describe the difference "style" of implementation between Gecko > and SpiderMonkey, I describe Gecko as being Java-like written in C++, > and SpiderMonkey being C with templates. > > Are you suggesting that we rewrite SpiderMonkey in Java-like style? I'm not quite sure what you mean by Java-like written in C++, so I can't say whether I'm advocating for that or not, but I highly doubt that I am given that I'm not a huge fan of rewriting large portions of the code manually all else being equal (which shouldn't be confused with reformatting the coding style of large portions of the code using automated tools. :-) ) _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
