Followup: modularity, WebExtensions, and going faster

[Alexandre poirot]

2016-10-12 18:04 GMT+02:00 Gijs Kruitbosch <gijskruitbosch at gmail.com>:

> 2016-10-12 8:26 GMT-07:00 Gijs Kruitbosch <gijskruitbosch at gmail.com>:
>
>> Session restore?
>> http://blog.techno-barje.fr/post/2016/03/14/session-restore-
>> web-extension/
>> The big advantage to this particular feature is that it doesn't involve
>> much UI, which is where WebExtension is the most limited.
>>
>> ... but then, is avoiding the UI problem really going to be helpful in
>> the future?
>>
> That's just being iterative. This experiment is here, available for anyone
to test it, compare the performances, and see for real how that would look
like.

We should also be iterative about integrating within browser.xul UI. The
awesomebar for example could be a good candidate of a self contained UI. I
have a prototype where I rip off browser.xul completely and implement
everything out of web extensions (I described in my first reply in this
thread). But that's just a showoff to help drawing a path between today and
a fully addonified browser.
Speaking about mochitest-plain, I got them running in a completely new
browser, in full HTML, on try. It wasn't green as some web features were
obviously broken, but the test harness was running just fine.

Aligning ourselves with the web is a good goal, IMO, but seems problematic
> with WebExtensions. WebExtensions, its async-ness, and its lacking support
> for actual UI creation, and interfacing with related UI on a single main
> thread with multiple async components, is (to the best of my knowledge) not
> a solved problem**. Then there's all the stuff about exposed vs. internally
> used API surfaces. Using React for the internal implementation of the
> frontend components would be better-understood (even if I'm personally not
> a massive React fan...).
>

Using React is ortogonal to the extension proposal. You may use whatever
web feature you prefer in it.
The benefit of building your app with addons is that you can replace each
of them and use completely different web technologies. Whereas if you just
do one big document implementing everyhing, like browser.xul, it won't be
possible.


> Those are all solvable problems, but there would need to be a commitment
> that people want to invest in this, and broader agreement on tools and
> direction.
>

I think some experiments would help taking any decision and help everyone
understand how that would really look like.

I've been working on this very narrow topic since January as a side project
and I do have a interesting feedback to share:
* I wasn't expecting to be able to reimplement most of Session restore
features as a web extension. I'm missing some really small tweaks to
chrome.tabs API.
* I was really surprised to be able to reimplement the core browser
features (tabs, urlbar, content) by just using chrome.tabs API, as-is, with
really dumb tweaks made to the official API, which I'm not sure have to be
privileged/internal and could just be exposed to all addons!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161012/2e5aca4f/attachment.html>