Proposed W3C Charter: Web Platform Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Web Platform Working Group (formerly Web Applications WG & HTML WG)
  https://www.w3.org/2016/08/web-platform-charter-draft.html
  https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0001.html

Mozilla has the opportunity to send comments or objections through
this Friday, September 30.

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why I don't like DXR

[Erik Rose]

I second the sentiment: it's clear that DXR needs a real manual. I've got the 
start of one at https://dxr.readthedocs.io/en/latest/use.html. So if you want 
to file PRs against 
https://github.com/mozilla/dxr/blob/master/docs/source/use.rst, we can grow 
that into a proper manual, import it into the app, and hang it off the "?" 
button—which is probably where you went looking for help in the first place. 
I'll endeavor to merge any such PRs promptly.

Erik

> On Sep 28, 2016, at 16:30 , Eric Rahm  wrote:
> 
> It's sounds like some sort of mxr => dxr transition wiki entry would be
> useful. Perhaps you can start by collecting the feedback you received here?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: So, what's the point of Cu.import, these days?

[Nick Fitzgerald]

On Wed, Sep 28, 2016 at 1:19 AM, David Teller  wrote:

>
> * CommonJS
>

​Just a heads up: the devtools have been using CommonJS modules and lazily
requiring modules for a couple years now. If you don't want to jump
directly to ES modules, reusing our infrastructure is probably a good idea.
We also run eslint on this stuff, but I don't know exactly how much
integration it has with our lazy requires.

http://searchfox.org/mozilla-central/search?q=lazyRequireGetter=false=false=
​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Engineering TMO Survey

[Ryan VanderMeulen]

Just a friendly reminder to please consider filling out this survey if 
you haven't already done so. We've already gotten a lot of great 
feedback and we'd love to get more! It will be open for responses until 
Friday the 30th.


Thanks!

-Ryan

On 9/23/2016 3:25 PM, Ryan VanderMeulen wrote:

Looks like the body of the email got lost!

In order to make telemetry.mozilla.org (TMO) and related sites a tool
that better supports the needs of the Firefox engineering teams, we
would like to collect feedback about people's experiences using these
tools. It shouldn't take more than a few minutes and responses are
welcome whether it's a tool you've personally used before or not.

Thank you for your time!

-Ryan

On 9/23/2016 3:23 PM, rvandermeu...@mozilla.com wrote:

I've invited you to fill out the following form:
Firefox Engineering TMO Survey

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSfu_8RosGp9_yNNc1m0Nn6Un9KD3P9yClUob6x9tnPbv1iIJw/viewform?c=0w=1usp=mail_form_link



Google Forms: Create and analyze surveys.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why I don't like DXR

[Honza Bambas]

Thanks everyone for answers.  This is helpful, but why don't I see any 
help like this right on DXR?  Why do I have to ask on dev-platform?


According identifiers not found on DXR I presume MXR might suffered the 
same issue, so no blame for DXR here.  I was just confused by not being 
able to easily do a fallback search.


Now I do.

Thanks!

-hb-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: So, what's the point of Cu.import, these days?

[Zibi Braniecki]

On Tuesday, September 27, 2016 at 2:01:09 PM UTC-7, David Teller wrote:

> "why": because you wrote "The former is a more tricky." in your previous
> message. If it's not, I'm quite happy to not remove them :)
> 
> For reference, "the former" is a snippet such as:
> 
> if (needed) {
>   Cu.import(...);
> }
> 
> to which I would add
> 
> function foo() {
>   Cu.import(...);
> }

It's tricky for migration, but it's extremely useful for performance and memory 
consumption.

I believe we want both nested and conditional imports.

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: So, what's the point of Cu.import, these days?

[David Teller]

\o/, let's join forces :)

I admit that I haven't thought at all about the impact on exceptions. If
we migrate to ES6 modules, then the problem is something that we don't
need to handle. If we migrate to CommonJS modules with a loader built
into XPConnect, I think that we can solve this without blood or pain.
More on this later.

I'm not entirely scared of lazy modules. There are obvious difficulties,
but I don't think that they are insurmountable.

I'll answer separately for CommonJS and ES6 modules, because the
problems we'll be facing are clearly different.

* CommonJS

As you mention in c), I'm pretty sure that we can trivially port
`defineLazyModuleGetter` to CommonJS, without changes to the client
code. See [1] for a few more details.

This will not be sufficient to get static analysis to understand lazy
imports, but I imagine that we can fix this as follows:

1. Introduce a `lazyRequire` function with the same signature and scope
as `require` and with the semantics of `defineLazyModuleGetter`.

2. Either teach our open-source linters that `lazyRequire` is `require`
or use Babel to rewrite `lazyRequire` to `require` before static analysis.



* ES6 modules

Indeed, ES6 modules don't like lazy imports. Theoretically, we could
port `defineLazyModuleGetter` using `processNextEvent` footgun magic,
but I would really hate to go in this direction.

I have put together in [2] a possible plan to migrate to ES6 modules
without breaking `defineLazyModuleGetter` – pending confirmation from
@jonco that this can be done. Essentially, past some point in the
migration, `Cu.import` becomes a sync version of the ES7's `import()`
function.

If this works (and it's a pretty big "if"), we can use more or less the
same steps as above.


Cheers,
 David


[1] https://gist.github.com/Yoric/777effee02d6788d3abc639c82ff4488
[2] https://gist.github.com/Yoric/2a7c8395377c7187ebf02219980b6f4d



On 28/09/16 00:42, Kris Maglione wrote:
> On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote:
>> So, can anybody think of good reason to not do this?
> 
> One major problem I see with this is that we currently lazily import
> most modules the first time that a symbol they export is referenced. 
> If
> we move to CommonJS or ES6 modules, we need to either:
> 
> a) Load essentially *all* of our Chrome JS at startup, before we even
> draw the first window. Maybe the static dependency handling of ES6
> modules would make that more tractable, but I'd be surprised.
>
> 
> b) Manually import modules whenever we need them. That might be doable
> in CommonJS or with the proposed future dynamic imports of ES6, but with
> a lot of additional cognitive overhead.
> 
> c) Use CommonJS, but with a lazy import helper. I wouldn't mind that
> approach so much, but I think that it would pretty much nullify any
> advantage for static analysis.
> 
> or,
> 
> d) Some hybrid of the above.
> 
> Frankly, I've been considering transitioning the code I work with to
> CommonJS for a while, mainly because easier for outside contributors to
> cope with (especially if they're used to Node). Cu.import tends to hide
> the names of the symbols it exports (which shows in how often our ESLint
> hacks fail to guess at what it exports), and even defineLazyModuleGetter
> takes some getting used to.
> 
> The main things that have been stopping me are the lack of support for
> lazy imports, and the unfortunate impact that the SDK loader has on
> debugging, with its mangling of exceptions, and the source URL mangling
> imposed by the subscript loader. But those problems can be overcome.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform