Am 16/01/2017 um 21:43 schrieb Dave Townsend:
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:
* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.
The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?
Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:
* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.
What other features do we depend on in XUL that I haven't listed?
Accessibility? Not sure how big the difference is there between XUL and
HTML.
Gandalf already mentioned l10n. We need something that moves us forward,
there are loads of requests on how we ship localizations that we can't
fulfill right now, and just bugs that we can't fix easily.
Flexbox still has perf issues?
https://bugzilla.mozilla.org/show_bug.cgi?id=1304473 tracks quite a few
bugs.
The question that other people have raised is "What HTML?", and I'd like
to share my thoughts on that, too.
Plain HTML documents are fine for what they can do. Write a text
document, get it parsed into DOM, some CSS, layout, done. At the
bare-metal, there are functionality problems that got mentioned, but
this is probably mostly uneventful.
Going into the JS side of things is where it's getting interesting.
There's the "jquery isn't html" ;-) And we have a ton of React right now.
With the experience the l10n team went through in the past couple of
months, creating your content via JS one at a time is slow. We learned
the hard way trying to figure out our performance challenges with
l20n.js. You can't create a DOMDocument via js calls from React in the
same time as the HTML or XML parsers. (The fix for l20n will lie in
dedicated platform APIs to do our DOM modifications in one call from js
to c++)
My takeaway from this is that any design pattern that creates much of
our UI DOM via DOM calls, element by element, attribute by attribute,
will struggle to be fast.
And then I have some old-school philosophical issues with React. Mostly,
I think that React is trying to solve the same problems we tried to
solve with XBL/XUL back in the days. And I think it generates many of
the same problems.
To me, someone good in React is like someone good in XBL. Probably true
for any other "component" infrastructure.
The fact that you know how to write components and use them doesn't help
you in using the library of existing components. You still need to go
through the list, and read the docs for things that sound like something
related to what you do right now, and see if they're the right tool.
I think we should keep this in mind when we talk about how many
developers out there can code X, and would easily be able to help patch
Firefox.
Another concern about React in particular is that it makes it harder to
improve on HTML, by it's design philosophy. That shows in the
conversations we have around l20n, but I think the same applies anywhere
where you can either do things in js, or use a platform feature that
implements that as efficiently as it can. Animations might be another
good example, webgl shaders?
Lastly, this wasn't mentioned, sometimes React and Global State go
together, so if you're interested in that, please hit me with questions.
I know more today on why we failed on
http://www-archive.mozilla.org/xpapps/aurora/ than back when I became
module owner of RDF. And as such merrily contributed to that failure.
Axel
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
