New Firefox data steward

[Benjamin Smedberg]

I am happy to announce that Rebecca Weiss will be taking over my
responsibilities as Firefox data steward. Rebecca has been a data steward
peer for a while and has been instrumental in helping Mozilla use data
effectively.

--BDS

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

Re: Proposed W3C Charter: WebVR Working Group

[Eric Rescorla]

LGTM

-Ekr


On Fri, Aug 18, 2017 at 2:59 PM, L. David Baron  wrote:

> OK, here's a draft of Tantek's points in a form that I think we
> could submit.  Please let me know if there are things you think I
> should change:
>
> -
> We support the idea of bringing WebVR into a working group at the W3C.
>
> However, bringing work that has been incubating in a community group (CG)
> into a working group (WG) requires more interaction with the existing CG
> than has happened here.  While we are aware that not all members of the CG
> support moving the work into a WG, we would like to see the process of
> developing a WG charter involve the existing CG more, and try to find an
> acceptable compromise that allows the formation of a WG.
>
> We're objecting because we believe this charter should be redrafted in a
> dialog with the existing Co
> mmunity Group, in order to build consensus there on the scope of the
> working group, its relationship to the community group, and other details.
> -
>
> -David
>
> On Friday 2017-08-18 10:17 -0500, Lars Bergstrom wrote:
> > Thanks, Tantek! I like this response. I have not been able to reach
> > google/microsoft but will inform them of this intention.
> >
> > To reinforce point #1, I'd add that WebVR is currently under TAG review
> > (see https://github.com/w3ctag/design-reviews/issues/185 ).
> Standardization
> > is definitely the intended path here.
> > - Lars
> >
> > On Thu, Aug 17, 2017 at 5:33 PM, Tantek Çelik 
> > wrote:
> >
> > > Given that we have a day left to respond to this poll, we should begin
> > > writing up at least a draft answer with known facts that we can
> > > iterate on as we get more information.
> > >
> > > Rough draft WebVR proposed charter response points for consideration:
> > >
> > >
> > > 1. Timing is good. We think WebVR is ready for a WG to formally
> > > standardize it.
> > >
> > > [Our very action of shipping a WebVR feature publicly (without pref)
> > > speaks louder than any words on any email lists (including this one)
> > > and communicates that we think WebVR is ready for adoption on the open
> > > web (if that were not true, we should not be shipping it publicly, but
> > > my understanding is that that decision has been made.), and thus ready
> > > for rapid standardization among implementers.]
> > >
> > > 2. WG charter details bad. We have strong concerns about the proposed
> > > WG charter as written, including apparent disconnects with the CG, and
> > > in particular failure to involve  implementers (e.g. browser vendors
> > > and major hardware providers).
> > >
> > > 3. Conclusion: Formal objection. Charter bad, needs to be withdrawn,
> > > be rewritten in an open dialog with the CG, such that there is at
> > > least rough consensus with the CG on scope, chairs, and other details.
> > >
> > >
> > > I believe these points reflect our actions and what Lars has
> communicated
> > > below:
> > >
> > > On Thu, Aug 17, 2017 at 9:14 AM, Lars Bergstrom 
> > > wrote:
> > > > I'll follow up more with the chairs of the community group (they just
> > > had a
> > > > face to face earlier this week and I presume it came up). The last
> bit
> > > that
> > > > I heard is consistent with what Dan mentioned -  the concern is not
> > > around
> > > > standardization
> > >
> > > Thanks for the clarification, thus point 1.
> > >
> > > > but that neither the chairs nor the browser vendors nor the
> > > > major hardware providers were consulted publicly in the creation of a
> > > > proposal to transition to a working group:
> > > > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0083.html
> > >
> > > Thus point 2.
> > >
> > > > Based on that thread, I'd expect the proposal to be withdrawn or -
> as Dan
> > > > mentioned - things adjusted to involve the the current spec
> contributors.
> > >
> > > Thus point 3 - we should openly advocate for the proposed charter to
> > > be withdrawn and rewritten accordingly.
> > >
> > >
> > > > I'll try to get on the phone with folks to find out more and get
> > > something
> > > > to dbaron by tomorrow. I'm not familiar with the inner workings of
> the
> > > W3C,
> > > > but I find it hard to imagine how things will go well with none of
> the
> > > > current spec contributors involved.
> > >
> > > Short answer: historically when W3C WGs move forward without strong
> > > implementer participation, they have very low chances of success, high
> > > chances of failure, and especially of damaging good will in relevant
> > > communities. Your concerns are merited.
> > >
> > > More information definitely appreciated to help iterate on our
> response.
> > >
> > > Thanks Lars,
> > >
> > > Tantek
> > >
> > >
> > > > On Wed, Aug 16, 2017 at 10:46 PM, Eric Rescorla 
> wrote:
> > > >
> > > >>
> > > >>
> > > >> On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz  >
> > > >> wrote:
> > > >>
> > > >>> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron  >
> > > >>> wrote:
> > > >>>
> > > >>> > I still think opposing this charte

Re: Proposed W3C Charter: WebVR Working Group

[L. David Baron]

OK, here's a draft of Tantek's points in a form that I think we
could submit.  Please let me know if there are things you think I
should change:

-
We support the idea of bringing WebVR into a working group at the W3C.

However, bringing work that has been incubating in a community group (CG) into 
a working group (WG) requires more interaction with the existing CG than has 
happened here.  While we are aware that not all members of the CG support 
moving the work into a WG, we would like to see the process of developing a WG 
charter involve the existing CG more, and try to find an acceptable compromise 
that allows the formation of a WG.

We're objecting because we believe this charter should be redrafted in a dialog 
with the existing Co
mmunity Group, in order to build consensus there on the scope of the working 
group, its relationship to the community group, and other details.
-

-David

On Friday 2017-08-18 10:17 -0500, Lars Bergstrom wrote:
> Thanks, Tantek! I like this response. I have not been able to reach
> google/microsoft but will inform them of this intention.
> 
> To reinforce point #1, I'd add that WebVR is currently under TAG review
> (see https://github.com/w3ctag/design-reviews/issues/185 ). Standardization
> is definitely the intended path here.
> - Lars
> 
> On Thu, Aug 17, 2017 at 5:33 PM, Tantek Çelik 
> wrote:
> 
> > Given that we have a day left to respond to this poll, we should begin
> > writing up at least a draft answer with known facts that we can
> > iterate on as we get more information.
> >
> > Rough draft WebVR proposed charter response points for consideration:
> >
> >
> > 1. Timing is good. We think WebVR is ready for a WG to formally
> > standardize it.
> >
> > [Our very action of shipping a WebVR feature publicly (without pref)
> > speaks louder than any words on any email lists (including this one)
> > and communicates that we think WebVR is ready for adoption on the open
> > web (if that were not true, we should not be shipping it publicly, but
> > my understanding is that that decision has been made.), and thus ready
> > for rapid standardization among implementers.]
> >
> > 2. WG charter details bad. We have strong concerns about the proposed
> > WG charter as written, including apparent disconnects with the CG, and
> > in particular failure to involve  implementers (e.g. browser vendors
> > and major hardware providers).
> >
> > 3. Conclusion: Formal objection. Charter bad, needs to be withdrawn,
> > be rewritten in an open dialog with the CG, such that there is at
> > least rough consensus with the CG on scope, chairs, and other details.
> >
> >
> > I believe these points reflect our actions and what Lars has communicated
> > below:
> >
> > On Thu, Aug 17, 2017 at 9:14 AM, Lars Bergstrom 
> > wrote:
> > > I'll follow up more with the chairs of the community group (they just
> > had a
> > > face to face earlier this week and I presume it came up). The last bit
> > that
> > > I heard is consistent with what Dan mentioned -  the concern is not
> > around
> > > standardization
> >
> > Thanks for the clarification, thus point 1.
> >
> > > but that neither the chairs nor the browser vendors nor the
> > > major hardware providers were consulted publicly in the creation of a
> > > proposal to transition to a working group:
> > > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0083.html
> >
> > Thus point 2.
> >
> > > Based on that thread, I'd expect the proposal to be withdrawn or - as Dan
> > > mentioned - things adjusted to involve the the current spec contributors.
> >
> > Thus point 3 - we should openly advocate for the proposed charter to
> > be withdrawn and rewritten accordingly.
> >
> >
> > > I'll try to get on the phone with folks to find out more and get
> > something
> > > to dbaron by tomorrow. I'm not familiar with the inner workings of the
> > W3C,
> > > but I find it hard to imagine how things will go well with none of the
> > > current spec contributors involved.
> >
> > Short answer: historically when W3C WGs move forward without strong
> > implementer participation, they have very low chances of success, high
> > chances of failure, and especially of damaging good will in relevant
> > communities. Your concerns are merited.
> >
> > More information definitely appreciated to help iterate on our response.
> >
> > Thanks Lars,
> >
> > Tantek
> >
> >
> > > On Wed, Aug 16, 2017 at 10:46 PM, Eric Rescorla  wrote:
> > >
> > >>
> > >>
> > >> On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz 
> > >> wrote:
> > >>
> > >>> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron 
> > >>> wrote:
> > >>>
> > >>> > I still think opposing this charter because the group should still
> > >>> > be in the incubation phase would be inconsistent with our shipping
> > >>> > and promotion of WebVR.
> > >>> >
> > >>>
> > >>> I agree that would be exceptionally odd and require a well reasoned
> > >>> argument about why formal standardization was inappropriate.
> > >>>
> 

Re: sccache as ccache

[Ted Mielczarek]

On Thu, Aug 17, 2017, at 10:01 PM, Mike Hommey wrote:
> On Wed, Jul 26, 2017 at 09:54:14AM -0400, Alex Gaynor wrote:
> > If you're on macOS, you can also get sccache with `brew install sccache`.
> 
> If you're on macOS and were hitting errors building openvr, this is
> fixed in sccache master.

I've also now published a 0.2.1 release to crates.io, so you can `cargo
install --force sccache` to get a release containing this fix.

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

APZ autoscrolling enabled on Nightly channel

[Botond Ballo]

Hi everyone,

APZ autoscrolling (bug 1390247) is now enabled by default on the
Nightly channel.

For those not familiar with autoscrolling, it's a scrolling mechanism
activated by middle-clicking the mouse, which causes an "anchor" to
appear on the screen, and moving the mouse away from the anchor. (It's
enabled by default on Windows, and can be enabled on Mac and Linux by
checking "Enable autoscrolling" in about:preferences).

Until now, autoscrolling was driven by the content process main
thread, which meant it was susceptible to jank on pages that are slow
to paint or run heavy script. APZ autoscrolling fixes that by driving
it from the compositor, allowing it to be smoother. (At the same time,
like other async scrolling methods, APZ autoscrolling can trigger
checkerboarding if you scroll sufficiently fast on a sufficiently long
page.)

If you notice any regressions related to autoscrolling on the Nightly
channel, please file bugs blocking bug 1390247.

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

Re: disabled non-e10s tests on trunk

[jmaher]

Yesterday I landed bug 1391371 which enabled non-e10s unittests on windows 7 
debug.  A few tests had to be disabled in order to do this.  To keep track of 
what we did and each of the test suites to evaluate, I have filed bug 1391350.

As a note we now have the following non-e10s tests running:
windows7-debug: all trunk branches
android opt/debug: all trunk branches (existing media, plain, reftest)
linux64-jsdcov: mozilla-central (mochitest-plain/browser-chrome/devtools)
** this is a linux64 opt build and we use the jsdebugger to collect code 
coverage metrics- but we specifically run this in non-e10s mode.

Please let me know if there are large areas that we have overlooked.

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

Re: Quantum Flow Engineering Newsletter #20

[Ehsan Akhgari]

On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> Is there a good way to get a sense of what the higher-impact bugs are that
> remain for improving Speedometer? Just going through the deps is difficult
> because it's hard to assess how much of a win some of those are. Are we
> gated mostly on JS perf at this point? Layout? Something else? :-)
>

That's a pretty hard question to answer since in many cases the impact of
each individual bug fix may fall below the measurement noise in the
benchmark score, and also it's pretty hard to map what you see in profiles
to benchmark score numbers, except for bugs that have some kind of in
progress patch which allows us to measure the before and after state
without them having been fixed yet.

In general Speedometer performance isn't generally gated on anything
extremely big and instead has been improved by fixing many small
performance issues all over the place.  That being said, there are some
"high profile" bugs that come to my mind.  Jan may think of some more in
SpiderMonkey:

  * https://bugzilla.mozilla.org/show_bug.cgi?id=651120 I think will be
able to gain us a few extra points but it's a complex change with many
dependencies and a few people are helping out Cătălin with it.
(Interestingly I just realized it wasn't on the dependency list of the main
SM2 bug!)
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1346723 may also help some
more still.  We have already done a ton of work under that bug, but there's
some more work to be done.  However this bug is getting closer to the state
where most of the remaining work involves fixing many different issues,
each of which is costing a bit of the overall time spent there when running
the benchmark.
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1349255 is a sync IPC that
hurts Speedometer so fixing it may have an outsized impact relative to
other bug fixes.
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1377131 may have a large
impact also, but I'm not sure exactly how much.  Olli may be able to
provide more information about that.

Cheers,
Ehsan


> Thanks!
>
> -Ryan
>
> On Fri, Aug 18, 2017 at 1:26 AM, Ehsan Akhgari 
> wrote:
>
>> Hi everyone,
>>
>> It is hard to believe that we've gotten to the twentieth of these
>> newsletters.  That also means that we're very quickly approaching the
>> finish line for this sprint.  We only have a bit more than five more weeks
>> to go before Firefox 57 merges to beta.  It may be a good time to start to
>> think more carefully about what we pay attention to in the remaining time,
>> both in terms of the risk of patches landing, and the opportunity cost of
>> what we decide to put off until 58 and the releases after.
>>
>> We still have a large number of triaged bugs
>> 
>> that are available for someone to pick up and work on.  If you have some
>> spare cycles, we really would appreciate if you consider picking one or two
>> bugs from this list and working on them.  They span many different areas of
>> the codebase so finding something in your area of interest and expertise
>> should hopefully be simple.  Quantum Flow isn't the kind of project that
>> requires fixing every single one of these bugs to be finished successfully,
>> but at the same time big performance improvements often consist of many
>> small parts, so the cumulative impact of a few additional fixes can make a
>> big impact.
>>
>> It is worth mentioning that lately while lurking on various tech news and
>> blog sites where Nightly users comment, I have seen quite a few positive
>> comments about Nightly performance from users.  It's easy to get lost in
>> the details of the work involved in getting rid of synchronous IPCs,
>> synchronous layout/style flushes, unnecessary memory allocations, hashtable
>> lookups, improving data locality, JavaScript JIT performance, making sure
>> code gets inlined better, ship a new CSS engine, etc. etc. but it is
>> reassuring to see people 
>> take  notice
>> .
>> :-)
>>
>> Moving on to mention one point about Speedometer charts on AWFY
>> 
>> which I have gotten a few questions about recently.  We now have
>> Speedometer benchmark numbers on Firefox Beta on the reference hardware
>> reported in addition to inbound optimized and PGO builds.  You may notice
>> that the benchmark score numbers we are getting on Beta are around the same
>> as Nightly (which swings around 83-84 these days).  This doesn't mean that
>> we haven't made any improvements on Nightly since the last Beta merge!  We
>> have some Nightly only telemetry code and some features th

Re: Proposed W3C Charter: WebVR Working Group

[Lars Bergstrom]

Thanks, Tantek! I like this response. I have not been able to reach
google/microsoft but will inform them of this intention.

To reinforce point #1, I'd add that WebVR is currently under TAG review
(see https://github.com/w3ctag/design-reviews/issues/185 ). Standardization
is definitely the intended path here.
- Lars

On Thu, Aug 17, 2017 at 5:33 PM, Tantek Çelik 
wrote:

> Given that we have a day left to respond to this poll, we should begin
> writing up at least a draft answer with known facts that we can
> iterate on as we get more information.
>
> Rough draft WebVR proposed charter response points for consideration:
>
>
> 1. Timing is good. We think WebVR is ready for a WG to formally
> standardize it.
>
> [Our very action of shipping a WebVR feature publicly (without pref)
> speaks louder than any words on any email lists (including this one)
> and communicates that we think WebVR is ready for adoption on the open
> web (if that were not true, we should not be shipping it publicly, but
> my understanding is that that decision has been made.), and thus ready
> for rapid standardization among implementers.]
>
> 2. WG charter details bad. We have strong concerns about the proposed
> WG charter as written, including apparent disconnects with the CG, and
> in particular failure to involve  implementers (e.g. browser vendors
> and major hardware providers).
>
> 3. Conclusion: Formal objection. Charter bad, needs to be withdrawn,
> be rewritten in an open dialog with the CG, such that there is at
> least rough consensus with the CG on scope, chairs, and other details.
>
>
> I believe these points reflect our actions and what Lars has communicated
> below:
>
> On Thu, Aug 17, 2017 at 9:14 AM, Lars Bergstrom 
> wrote:
> > I'll follow up more with the chairs of the community group (they just
> had a
> > face to face earlier this week and I presume it came up). The last bit
> that
> > I heard is consistent with what Dan mentioned -  the concern is not
> around
> > standardization
>
> Thanks for the clarification, thus point 1.
>
> > but that neither the chairs nor the browser vendors nor the
> > major hardware providers were consulted publicly in the creation of a
> > proposal to transition to a working group:
> > https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0083.html
>
> Thus point 2.
>
> > Based on that thread, I'd expect the proposal to be withdrawn or - as Dan
> > mentioned - things adjusted to involve the the current spec contributors.
>
> Thus point 3 - we should openly advocate for the proposed charter to
> be withdrawn and rewritten accordingly.
>
>
> > I'll try to get on the phone with folks to find out more and get
> something
> > to dbaron by tomorrow. I'm not familiar with the inner workings of the
> W3C,
> > but I find it hard to imagine how things will go well with none of the
> > current spec contributors involved.
>
> Short answer: historically when W3C WGs move forward without strong
> implementer participation, they have very low chances of success, high
> chances of failure, and especially of damaging good will in relevant
> communities. Your concerns are merited.
>
> More information definitely appreciated to help iterate on our response.
>
> Thanks Lars,
>
> Tantek
>
>
> > On Wed, Aug 16, 2017 at 10:46 PM, Eric Rescorla  wrote:
> >
> >>
> >>
> >> On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz 
> >> wrote:
> >>
> >>> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron 
> >>> wrote:
> >>>
> >>> > I still think opposing this charter because the group should still
> >>> > be in the incubation phase would be inconsistent with our shipping
> >>> > and promotion of WebVR.
> >>> >
> >>>
> >>> I agree that would be exceptionally odd and require a well reasoned
> >>> argument about why formal standardization was inappropriate.
> >>>
> >>
> >> This puzzles me as well. Lars, can you explain what the argument against
> >> standardization of a shipping feature is?
> >>
> >> -Ekr
> >>
> >>
> >>>
> >>> I'm troubled that the members of the incubation group seem to feel that
> >>> chairs are being imposed on them who have been less involved (or
> >>> uninvolved?) with leading the feature to the point it's gotten so far.
> But
> >>> I don't understand the politics of that or whether we could or should
> get
> >>> involved on that point.
> >>>
> >>> -Dan Veditz
> >>> ___
> >>> dev-platform mailing list
> >>> dev-platform@lists.mozilla.org
> >>> https://lists.mozilla.org/listinfo/dev-platform
> >>>
> >>
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #20

[Ryan VanderMeulen]

Is there a good way to get a sense of what the higher-impact bugs are that
remain for improving Speedometer? Just going through the deps is difficult
because it's hard to assess how much of a win some of those are. Are we
gated mostly on JS perf at this point? Layout? Something else? :-)

Thanks!

-Ryan

On Fri, Aug 18, 2017 at 1:26 AM, Ehsan Akhgari 
wrote:

> Hi everyone,
>
> It is hard to believe that we've gotten to the twentieth of these
> newsletters.  That also means that we're very quickly approaching the
> finish line for this sprint.  We only have a bit more than five more weeks
> to go before Firefox 57 merges to beta.  It may be a good time to start to
> think more carefully about what we pay attention to in the remaining time,
> both in terms of the risk of patches landing, and the opportunity cost of
> what we decide to put off until 58 and the releases after.
>
> We still have a large number of triaged bugs
> 
> that are available for someone to pick up and work on.  If you have some
> spare cycles, we really would appreciate if you consider picking one or two
> bugs from this list and working on them.  They span many different areas of
> the codebase so finding something in your area of interest and expertise
> should hopefully be simple.  Quantum Flow isn't the kind of project that
> requires fixing every single one of these bugs to be finished successfully,
> but at the same time big performance improvements often consist of many
> small parts, so the cumulative impact of a few additional fixes can make a
> big impact.
>
> It is worth mentioning that lately while lurking on various tech news and
> blog sites where Nightly users comment, I have seen quite a few positive
> comments about Nightly performance from users.  It's easy to get lost in
> the details of the work involved in getting rid of synchronous IPCs,
> synchronous layout/style flushes, unnecessary memory allocations, hashtable
> lookups, improving data locality, JavaScript JIT performance, making sure
> code gets inlined better, ship a new CSS engine, etc. etc. but it is
> reassuring to see people 
> take  notice
> .
> :-)
>
> Moving on to mention one point about Speedometer charts on AWFY
> 
> which I have gotten a few questions about recently.  We now have
> Speedometer benchmark numbers on Firefox Beta on the reference hardware
> reported in addition to inbound optimized and PGO builds.  You may notice
> that the benchmark score numbers we are getting on Beta are around the same
> as Nightly (which swings around 83-84 these days).  This doesn't mean that
> we haven't made any improvements on Nightly since the last Beta merge!  We
> have some Nightly only telemetry code and some features that are only
> enabled on the Nightly channel, and those add a bit of overhead, which
> causes us to see a bit of an improvement after an uplift from
> mozilla-central to mozilla-beta without any code changes.  This means that
> when the current code on Nightly gets merged to Beta 57, we should expect a
> bit of an improvement similarly.
>
> And now let me take a moment to acknowledge the work of some of those who
> helped make Firefox faster last week.  I hope I'm not dropping anyone's
> name mistakenly.
>
>- Perry Jiang made _shouldCapture() run off of the idle queue and do
>nothing for about: pages
>. Perry also
>made it so that we don’t unnecessarily load the autoscroll PNG when opening
>a new window.
>- Kris Maglione fixed a recent regression causing extremely poor
>performance with extensions which have scripts creating large numbers of
>message listeners which never call their response callbacks
>.  He also made
>code that registers a lot of lazy module and service getters use loops
> to make such
>code easier to optimize by SpiderMonkey JIT.  He furthermore switched
>away from using FileUtils.getFile()
> which does
>main-thread I/O to check for the respective directory exists.  Kris also
>made us not create the IndexedDB bindings in sandboxes
> since they’re
>never used and avoided adding the caller location to the sandbox name
>if an explicit name if provided by the caller
>.
>- Jan de Mooij added a megamorphic SetElement stub
>

JavaScript Binary AST Engineering Newsletter #1

[David Teller]

Hey, all cool kids have exciting Engineering Newsletters these days, so
it's high time the JavaScript Binary AST got one!


# General idea

JavaScript Binary AST is a joint project between Mozilla and Facebook to
rethink how JavaScript source code is stored/transmitted/parsed. We
expect that this project will help visibly speed up the loading of large
codebases of JS applications, including web applications, and will have
a large impact on the JS development community, including both web
developers, Node developers, add-on developers and ourselves.


# Context

The size of JavaScript-based applications – starting with webpages –
keep increasing, while the parsing speed of JavaScript VMs has basically
peaked. The result is that the startup of many web/js applications is
now limited by JavaScript parsing speed. While there are measures that
JS developers can take to improve the loading speed of their code, many
applications have reached a situation in which such an effort becomes
unmanageable.

The JavaScript Binary AST is a novel format for storing JavaScript code.
The global objective is to decrease the time spent between
first-byte-received and code-execution-starts. To achieve this, we focus
on a new file format, which we hope will aid our goal by:

- making parsing easier/faster
- supporting parallel parsing
- supporting lazy parsing
- supporting on-the-fly bytecode generation
- decreasing file size.

For more context on the JavaScript Binary AST and alternative
approaches, see the companion high-level blog post [1].


# Progress

## Benchmarking Prototype

The first phase of the project was spent developing an early prototype
format and parser to validate our hypothesis that:

- we can make parsing much faster
- we can make lazy parsing much faster
- we can reduce the size of files.

The prototype built for benchmarking was, by definition, incomplete, but
sufficient to represent ES5-level source code. All our benchmarking was
performed on snapshots of Facebook’s chat and of the JS source code our
own DevTools.

While numbers are bound to change as we progress from a proof-of-concept
prototype towards a robust and future-proof implementation, the results
we obtained from the prototype are very encouraging.

- parsing time 0.3 (i.e. parsing time is less than a third of original time)
- lazy parsing time *0.1
- gzipped file size vs gzipped human-readable source code *0.3
- gzipped file size vs gzipped minified source code *0.95.

Please keep in mind that future versions may have very different
results. However, these values confirm that the approach can
considerably improve performance.

More details in bug 1349917.


## Reference Prototype

The second phase of the project consisted of building a second prototype
format designed to:

- support future evolutions of JavaScript
- support annotations designed to allow safe lazy/concurrent parsing
- serve as a reference implementation for third-party developers

This reference prototype has been implemented (minus compression) and is
currently being tested. It is entirely independent from SpiderMonkey and
uses Rust (for all the heavy data structure manipulation) and Node (to
benefit from existing parsing/pretty-printing tool Babylon). It is
likely that, as data structures stabilize, the reference prototype will
migrate to a full JS implementation, so as to make it easier for
third-party contributors to join in.

More details on the tracker [2].


## Standard tracks

As any proposed addition to the JavaScript language, the JavaScript
Binary AST needs to go through standards body.

The project has successfully been accepted as an ECMA TC39 Stage 1
Proposal. Once we have a working Firefox implementation and compelling
results, we will proceed towards Stage 2.

More details on the tracker [3].



# Next few steps

There is still lots of work before we can land this on the web.


## SpiderMonkey implementation

We are currently working on a SpiderMonkey implementation of the
Reference Prototype, initially without lazy or concurrent parsing. We
need to finish it to be able to properly test that JavaScript decoding
works.

## Compression

The benchmarking prototype only implemented naive compression, while the
reference prototype – which carries more data – doesn’t implement any
form of compression yet. We need to reintroduce compression to be able
to measure the impact on file size.



# How can I help?

If you wish to help with the project, please get in touch with either
Naveed Ihsanullah (IRC: naveed, mail: nihsanullah) or myself (IRC:
Yoric, mail: dteller).


[1] https://yoric.github.io/post/binary-ast-newsletter-1/
[2] https://github.com/Yoric/binjs-ref/
[3] https://github.com/syg/ecmascript-binary-ast/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Stylesheet wait timeout?

[Gervase Markham]

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