Revisiting how we build Firefox

At Whistler last week we started to talk a bit about the fundamentals of how we build Firefox. We want to get everyone involved as early as possible, so I wanted to provide background and context to those who weren’t there. Firefox is built on web technologies*, but we could do a much better job of capitalizing on that. The first thread of discussion was around deployment: since Firefox began, the industry has continually evolved how it deploys code to users, and today it isn’t done on an 18-week cycle. We think there are big wins to be had in shortening the time that new features reaches users. Critical fixes should ship to users in minutes, not days. Individual features rolling out to small audiences for focused and multi-variate testing. As Laura Thomson put it in her Whistler presentation - “The trains have served us well, but it’s time to build a hyperloop.” *The second thread was about removing that asterisk from “web technologies”. Back in the early Mozilla days, XUL was our attempt to fill the gaps HTML had at for building large-scale web applications. Over time, the web - and app development for the web - has evolved its own set of standards and technologies; we should follow it. The web development community has addressed that need through HTML in a number of interesting and novel ways that don’t rely on Mozilla-specific technology. There’s a huge body of shared wisdom about how to build applications on the web. It’s time to go back and examine how we can bring that wisdom back into Firefox. Because XUL and XBL aren’t web technologies, they don’t get the same platform attention that HTML does (for good reason!). Performance problems go unfixed and it creates a lot of unnecessary complexity within Gecko. It’s harder for even experienced web developers to get up to speed. It’s further from the web, and that doesn’t help anybody. We intend to move Firefox away from XUL and XBL, but the discussion of how to do that is in the early stages. There are a ton of unanswered questions: what technologies/best practices for web development should we adopt in its place? How does this affect add-on developers? Is there space for a native-code main-window on desktop like we have on Android? How much time should we spend on this vs. other quality issues? What unanswered questions have we not asked yet? Some of these questions are going to take a while to answer, and will involve a bunch of concurrent discussions. If you start seeing discussion of the “go faster” project, that’s talking about addressing our deployment strategy. If you start seeing people using sometimes-excessively-violent references to removing XUL/XBL from our codebase, this is the context in which that discussion is happening. When you see these discussions - including now - please join in. Thanks, -dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20150706/4180929e/attachment.html>