<div dir="ltr">On Mon, Jul 13, 2015 at 9:13 AM, David Rajchenbach-Teller <span dir="ltr"><<a href="mailto:dteller@mozilla.com" target="_blank">dteller@mozilla.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
** High-level<br>
* Get rid of the deprecated (XUL) bits of Gecko in a finite time.<br>
* Don't break Firefox [1].<br></blockquote><div><br></div><div>I think this is a huge challenge. If we deprecate XUL (meaning we implement new things in HTML, try to make the amount of Firefox using XUL smaller over time) then we are increasing the complexity of development, as the period of transition will be significantly more complex than the status quo.  An unfinished transition plan will itself significantly add to complexity, as everyone will constantly have to ask: what is the right way to do something *today*.  The only win for complexity is when XUL is actually eliminated, and it might be years *after* XUL is eliminated before we see a net gain on that investment given the cost of the transition.<br><br></div><div>If we want to reduce complexity, while simultaneously working on everything else we want to do in Firefox, my hunch is that we should have a plan in place that eliminates XUL all at once, rather than deprecate it over time.  That's not easy, but I think we would save time and effort by investing hundreds, even a thousand or more person-hours into coming up with a definitive approach – an approach that doesn't add a tax to all ongoing work, and an approach that reaches a conclusion.<br><br></div><div>Speculating a bit what that might look like: that kind of  approach would require that the bulk of the work happen as tooling entirely separate from mozilla-central.  It wouldn't attempt to re-implement all the logic embodied in XUL, but it would reimagine that logic  in a different context.  That might be something like React Native where the markup is turned into native controls.  Or it might be something like Web Components where XUL becomes a set of components built on HTML.  Ideally most code could be converted automatically.  Things that couldn't be converted should at least be detected, and ideally could be converted by hand in mozilla-central to a XUL pattern that was more amenable to automatic conversion.  The team might land linters so that problematic constructs didn't get reintroduced.  Ideally tests that worked pre-conversion would work post-conversion (and getting those tests passing would be a target), though I would expect that test fragility would be a serious problem.<br></div></div><br></div><div class="gmail_extra">Obviously a very hard problem, and I honestly don't  have any guess on the best way to execute any of the many details, but this is my sense of a process by which we could come to a positive conclusion.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Ian Bicking | Engineering Manager | Firefox Group | Mozilla<br></div></div></div></div></div></div></div></div>
</div></div>