Revisiting how we build Firefox
Enrico Weigelt, metux IT consult
enrico.weigelt at gr13.net
Wed Jul 8 23:16:37 UTC 2015
On 06.07.2015 18:46, Dave Camp wrote:
just my personal oppinion:
> Firefox is built on web technologies*, but we could do a much better
> job of capitalizing on that.
I doubt that. IMHO, a browser is just yet another application, just
like dozens of others, and it should be handled that way - especially
when it comes to deployment, etc.
And yes: I'm strictly opposed to applications updating themselves
(or even just components of / extensions for itself) - these things
should run entirely through the OS'es/distro's package management.
It's even a major security issue.
> The first thread of discussion was around deployment: since Firefox
> began, the industry has continually evolved how it deploys code to
IMHO, it devolved. The fundamental concepts - like package management -
are there since decade. On many platforms (eg. GNU/Linux) it's the
standard and well proven - just some esoteric platforms still dont have
it (or just start introducing something in that direction ...)
> 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
NAK. Features can wait, until they're _ready_.
Features aren't an self-purpose - they have to solve _real_ problems,
otherwise they're useless and just disturbing (and yes: FF has several
misfeatures, I'd really like to get rid of).
> Critical fixes should ship to users in minutes, not days.
Yes, of course. That's what package management is for. With tools like
> Individual features rolling out to small audiences for focused and
> multi-variate testing.
Also trivial, with additional package repositories.
> *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.
I'm still a bit undecided at that point. Actually, I'm currently
designing a new widget/gui toolkit, primarily focused on efficiency.
And I'm yet investigating whether XUL might be a suited UI modeling
language (still have to check whether it's suited for code generation).
Even HTML5 isn't actually made for GUIs, you only can abuse it for such
things (with lots of additional code) ... too far away from the problem
> 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.
local/desktop applications != web applications.
anyways, I still prefer classical desktop applications (or even console
tools) for daily tasks.
> Because XUL and XBL aren’t web technologies, they don’t get the same
> platform attention that HTML does (for good reason!).
The actual problem, IMHO, is _not_ technologies like XUL (or maybe glade
+ friends), but the hype for HTML/Web-Apps. Something that really
> Performance problems go unfixed and it creates a lot of unnecessary
> complexity within Gecko.
Does it need to be within Gecko at all ?
IMHO, the problem domains are entirely different. Common topics (eg.
graphics rendering, XML parsing, js, etc) should belong into their
own, separate and generic modules anyways.
> How does this affect add-on developers?
How does it affect usability ?
I would really hate to have FF's UI look and feel like some web app.
metux IT consulting
More information about the firefox-dev