Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Mon, May 15, 2017 at 10:14:10AM -0700, Sam Foster wrote:

I think this deserves a round of applause. Its a large undertaking with
measurable perf wins in areas with strong SEP(1) fields


Do you have measurements? It seems likely to be a perf win, but 
I haven't seen any metrics to confirm what effects it's had.



On Wed, May 10, 2017 at 7:09 PM, Florian Quèze  wrote:


On Mon, Mar 27, 2017 at 9:42 PM, Dave Townsend 
wrote:

> lets go ahead with this and avoid using Task.jsm in the future.

Patches to remove Task.jsm usage from browser/ and toolkit/ are now
available in https://bugzilla.mozilla.org/show_bug.cgi?id=1353542
along with the scripts that generated them.

I currently expect to land them on Friday morning. Given the size of
the patches (2040 files changed, more than 35k lines changed), this
landing will likely happen with a tree closure, to avoid merging
conflicts between inbound and autoland.

If you have WIP front-end patches that are almost ready to land, I
would suggest landing them soon to avoid bitrot.

Florian

--
Florian Quèze
___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev




___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev



--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

The cardinal doctrine of a fanatic's creed is that his enemies are the
enemies of God.
--Andrew Dickson White

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

Re: Switching to async/await from Task.jsm/yield

[Sam Foster]

I think this deserves a round of applause. Its a large undertaking with
measurable perf wins in areas with strong SEP(1) fields

1. https://en.wikipedia.org/wiki/Somebody_else%27s_problem

/Sam



On Wed, May 10, 2017 at 7:09 PM, Florian Quèze  wrote:

> On Mon, Mar 27, 2017 at 9:42 PM, Dave Townsend 
> wrote:
>
> > lets go ahead with this and avoid using Task.jsm in the future.
>
> Patches to remove Task.jsm usage from browser/ and toolkit/ are now
> available in https://bugzilla.mozilla.org/show_bug.cgi?id=1353542
> along with the scripts that generated them.
>
> I currently expect to land them on Friday morning. Given the size of
> the patches (2040 files changed, more than 35k lines changed), this
> landing will likely happen with a tree closure, to avoid merging
> conflicts between inbound and autoland.
>
> If you have WIP front-end patches that are almost ready to land, I
> would suggest landing them soon to avoid bitrot.
>
> Florian
>
> --
> Florian Quèze
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Florian Quèze]

On Mon, Mar 27, 2017 at 9:42 PM, Dave Townsend  wrote:

> lets go ahead with this and avoid using Task.jsm in the future.

Patches to remove Task.jsm usage from browser/ and toolkit/ are now
available in https://bugzilla.mozilla.org/show_bug.cgi?id=1353542
along with the scripts that generated them.

I currently expect to land them on Friday morning. Given the size of
the patches (2040 files changed, more than 35k lines changed), this
landing will likely happen with a tree closure, to avoid merging
conflicts between inbound and autoland.

If you have WIP front-end patches that are almost ready to land, I
would suggest landing them soon to avoid bitrot.

Florian

-- 
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Dave Townsend]

On Mon, Apr 3, 2017 at 9:38 AM, Joshua Cranmer 🐧 
wrote:

> On 3/16/2017 5:29 PM, Dave Townsend wrote:
>
>> For a long time now we've been writing JS code that waits for promises
>> using Task.jsm and generator functions. Recently though the JS team added
>> support for the JS standard way of doing this, async/await:
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
>> rence/Statements/async_function
>>
>> Writing code in standard JS is always better for the web, makes it easier
>> to onboard new engineers and allows for better support in developer tools.
>> So I'd like to propose that we switch to the standard way of writing these
>> functions immediately. New code should use async/await instead of Task.jsm
>> going forwards.
>>
>> Florian has some rough plans to automatically rewrite existing usages of
>> Task.jsm to the standard JS forms so for now don't worry much about going
>> and submitting patches to fix up existing code. Once that is done we can
>> remove Task.jsm from the tree.
>>
>> Does anyone object to any of this?
>>
>
> Is it possible to make those scripts public so as to be able to run them
> on comm-central?


They aren't written yet but once they are they will definitely be
available.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Joshua Cranmer 🐧]

On 3/16/2017 5:29 PM, Dave Townsend wrote:

For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions immediately. New code should use async/await instead of Task.jsm
going forwards.

Florian has some rough plans to automatically rewrite existing usages of
Task.jsm to the standard JS forms so for now don't worry much about going
and submitting patches to fix up existing code. Once that is done we can
remove Task.jsm from the tree.

Does anyone object to any of this?


Is it possible to make those scripts public so as to be able to run them 
on comm-central?


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Mon, Mar 27, 2017 at 12:42:46PM -0700, Dave Townsend wrote:
It looks like the main concern raised about switching over to async/await 
where possible is bug 1242505.


I personally wouldn't consider this a blocker. I'm all for it 
being fixed, but the benefit of not having Promise.jsm noise in 
my tests outweighs it. And there are places where we can't 
actually use Promise.jsm (content scopes, extension copes), so 
we wind up with a mix of the two models if we try to stick with 
Promise.jsm in some places and not in others.


We're going to try to get some resources for fixing that bug and it probably 
blocks doing a mass rewrite of existing code but I don't think it blocks 
people starting to use async/await right now as we're already using native 
Promises in lots of places.


I think that, if anything, it should probably the other way around. Existing 
tests that use Promise.jsm probably don't have many unhandled exceptions, but 
new tests are more likely to wind up with them. If we start using native 
promises in more new places and then add unhandled rejection tracking to 
tests, we're probably going to have to do a lot more work fixing existing 
issues to get it turned on than if we gradually migrated to native promises 
after it was fixed.


But I'd still rather we use native promises and async functions in new tests, 
so I'm all for mass converting old code as well, and making sure we invest 
time in fixing that bug as soon as possible.

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

Re: Switching to async/await from Task.jsm/yield

[Dave Townsend]

It looks like the main concern raised about switching over to async/await
where possible is bug 1242505. We're going to try to get some resources for
fixing that bug and it probably blocks doing a mass rewrite of existing
code but I don't think it blocks people starting to use async/await right
now as we're already using native Promises in lots of places. So lets go
ahead with this and avoid using Task.jsm in the future.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Till Schneidereit]

On Sun, Mar 26, 2017 at 8:16 PM, Ehsan Akhgari 
wrote:

> On 2017-03-17 7:41 PM, Kris Maglione wrote:
> > On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:
> >> Have we measured the performance of our async/await implementation?  I
> >> think we should definitely do some extensive testing of the performance
> >> of any new ES primitives before deciding to switch to using them in the
> >> front-end code en masse.  Of course, if the performance result aren't
> >> good, that doesn't mean we shouldn't use them in the front-end code, it
> >> means we need to make the performance better.  :-)  But we need to be
> >> able to make the trade-off cautiously.
> >
> > Yes. There was performance testing for the self-hosted version (which
> > was basically the same as the Promise.jsm implementation) before it was
> > converted to C++, and after:
> >
> > https://bugzil.la/1314055
> >
> > In short, it's better, but not hugely.
>
> That's quite nice if you ask me.  :-)  I have see code surrounding this
> stuff show up in profiles a lot, although I admit I haven't had a way to
> measure the overhead of this part directly.  And often times the way
> that this matters is in a "death by a thousand cuts" scenario, i.e.,
> when in some edge case something is taking super long, this overhead
> makes things much worse, so I'm really happy to see this happening!
>

Additionally, the async/await implementation will get faster eventually.
There are quite a few ways to optimize it which we haven't yet implemented.
They're not exactly trivial, so this isn't necessarily a short-term thing,
but they'll definitely happen. So if we change as much code as possible to
using async/await instead of Promise.jsm, we'll get the benefits of this
automatically in many areas of the browser.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Ehsan Akhgari]

On 2017-03-17 7:41 PM, Kris Maglione wrote:
> On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:
>> Have we measured the performance of our async/await implementation?  I
>> think we should definitely do some extensive testing of the performance
>> of any new ES primitives before deciding to switch to using them in the
>> front-end code en masse.  Of course, if the performance result aren't
>> good, that doesn't mean we shouldn't use them in the front-end code, it
>> means we need to make the performance better.  :-)  But we need to be
>> able to make the trade-off cautiously.
> 
> Yes. There was performance testing for the self-hosted version (which
> was basically the same as the Promise.jsm implementation) before it was
> converted to C++, and after:
> 
> https://bugzil.la/1314055
> 
> In short, it's better, but not hugely.

That's quite nice if you ask me.  :-)  I have see code surrounding this
stuff show up in profiles a lot, although I admit I haven't had a way to
measure the overhead of this part directly.  And often times the way
that this matters is in a "death by a thousand cuts" scenario, i.e.,
when in some edge case something is taking super long, this overhead
makes things much worse, so I'm really happy to see this happening!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Paolo Amadini]

On 3/17/2017 5:19 PM, Dave Townsend wrote:

One issue I have just spotted is that Task.jsm uses a JavaScript
implementation of promises under the hood while async/await obviously uses
our native implementation in the JS engine.


You're inadvertently losing test coverage if you convert everything
before landing .
I strongly recommend fixing unhandled rejection reporting for browser
tests before any mass conversion from Task.jsm to async functions.

With regard to async stacks, I think the important thing is ensuring
that we have useful traces for test failures that happen in async
functions. We are supposed to have useful stack rewriting in Task.jsm,
but I believe that it did break at some point, because we don't have
any test checking that we don't add extraneous frames to the stack. I
started some work to fix that situation in bug 1144353, but wasn't able
to continue in that area. There might be no need to work on that
particular bug now if this is functionality that comes for free when
using async functions.

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

Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:

Have we measured the performance of our async/await implementation?  I
think we should definitely do some extensive testing of the performance
of any new ES primitives before deciding to switch to using them in the
front-end code en masse.  Of course, if the performance result aren't
good, that doesn't mean we shouldn't use them in the front-end code, it
means we need to make the performance better.  :-)  But we need to be
able to make the trade-off cautiously.


Yes. There was performance testing for the self-hosted version 
(which was basically the same as the Promise.jsm implementation) 
before it was converted to C++, and after:


https://bugzil.la/1314055

In short, it's better, but not hugely.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Ehsan Akhgari]

On 2017-03-16 6:29 PM, Dave Townsend wrote:
> For a long time now we've been writing JS code that waits for promises
> using Task.jsm and generator functions. Recently though the JS team
> added support for the JS standard way of doing this, async/await:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
> 
> Writing code in standard JS is always better for the web, makes it
> easier to onboard new engineers and allows for better support in
> developer tools. So I'd like to propose that we switch to the standard
> way of writing these functions immediately. New code should use
> async/await instead of Task.jsm going forwards.
> 
> Florian has some rough plans to automatically rewrite existing usages of
> Task.jsm to the standard JS forms so for now don't worry much about
> going and submitting patches to fix up existing code. Once that is done
> we can remove Task.jsm from the tree.
> 
> Does anyone object to any of this?

Have we measured the performance of our async/await implementation?  I
think we should definitely do some extensive testing of the performance
of any new ES primitives before deciding to switch to using them in the
front-end code en masse.  Of course, if the performance result aren't
good, that doesn't mean we shouldn't use them in the front-end code, it
means we need to make the performance better.  :-)  But we need to be
able to make the trade-off cautiously.

On the plus side, I sometimes really struggle to read the profiles when
looking at the JS call stacks involving Task.jsm primitives, so moving
away from them sounds really exciting to me personally!

Thanks,
Ehsan

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

Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Fri, Mar 17, 2017 at 10:19:02AM -0700, Dave Townsend wrote:

One issue I have just spotted is that Task.jsm uses a JavaScript
implementation of promises under the hood while async/await obviously uses
our native implementation in the JS engine. This may mean the two have
slightly different characteristics. That shouldn't matter for new code
written but may cause problems as we attempt to automatically rewrite older
code and tests make bad assumptions.


With the exception of async stacks, the two have basically the same 
characteristics these days. Promise.jsm uses native promises to schedule 
its flush loop these days, so the two should behave in the same way.


The only particular issue I've run into is that some test code assumes it 
will always have a JS caller on the stack for reporting, which isn't 
always the case when called as a native promise resolution handler.



On Thu, Mar 16, 2017 at 3:29 PM, Dave Townsend 
wrote:


For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/
Reference/Statements/async_function

Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions immediately. New code should use async/await instead of Task.jsm
going forwards.

Florian has some rough plans to automatically rewrite existing usages of
Task.jsm to the standard JS forms so for now don't worry much about going
and submitting patches to fix up existing code. Once that is done we can
remove Task.jsm from the tree.

Does anyone object to any of this?


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

Re: Switching to async/await from Task.jsm/yield

[Dave Townsend]

One issue I have just spotted is that Task.jsm uses a JavaScript
implementation of promises under the hood while async/await obviously uses
our native implementation in the JS engine. This may mean the two have
slightly different characteristics. That shouldn't matter for new code
written but may cause problems as we attempt to automatically rewrite older
code and tests make bad assumptions.

On Thu, Mar 16, 2017 at 3:29 PM, Dave Townsend 
wrote:

> For a long time now we've been writing JS code that waits for promises
> using Task.jsm and generator functions. Recently though the JS team added
> support for the JS standard way of doing this, async/await:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/
> Reference/Statements/async_function
>
> Writing code in standard JS is always better for the web, makes it easier
> to onboard new engineers and allows for better support in developer tools.
> So I'd like to propose that we switch to the standard way of writing these
> functions immediately. New code should use async/await instead of Task.jsm
> going forwards.
>
> Florian has some rough plans to automatically rewrite existing usages of
> Task.jsm to the standard JS forms so for now don't worry much about going
> and submitting patches to fix up existing code. Once that is done we can
> remove Task.jsm from the tree.
>
> Does anyone object to any of this?
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Thu, Mar 16, 2017 at 09:08:24PM -0400, Michael Layzell wrote:

Can we pass async functions everywhere where we use `add_task` in tests
already? If we can't, is there a tracking bug for converting all of the
test systems to support it?


Yes, add_task accepts any function which returns a promise, including async 
functions.



Can you `await` a function created with Task.async such as
`BrowserTestUtils.withNewTab` during the transition period?


Yes, you can await on any object with a Promise-like `then` method.


How about in ESR52? Will uplifting tests to ESR52 be a painful experience
due to having to use different tools to write the tests?


ESR52 supports async functions.


Can I pass an async function as the callback argument to things like
ContentTask.spawn and BrowserTestUtils.withNewTab? How about on ESR52?


Yes, they stringify in a way that's compatible with ContentTask.spawn, and 
withNewTab doesn't care what kind of function you pass it, so long as it 
returns a promise or generator.

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

Re: Switching to async/await from Task.jsm/yield

[Michael Layzell]

I mostly use tasks when writing tests, so I mostly have questions about how
it's use in that situation will be affected.

Can we pass async functions everywhere where we use `add_task` in tests
already? If we can't, is there a tracking bug for converting all of the
test systems to support it?
Can you `await` a function created with Task.async such as
`BrowserTestUtils.withNewTab` during the transition period?
How about in ESR52? Will uplifting tests to ESR52 be a painful experience
due to having to use different tools to write the tests?
Can I pass an async function as the callback argument to things like
ContentTask.spawn and BrowserTestUtils.withNewTab? How about on ESR52?

On Thu, Mar 16, 2017 at 7:18 PM, J. Ryan Stinnett  wrote:

> Sounds like a good change to make from the discussion so far.
>
> If there are issues with stack traces, I would assume having more of our
> code base using async / await is a good way to apply pressure for stack
> trace improvements (if needed) that will benefit everyone.
>
> - Ryan
>
> On Thu, Mar 16, 2017 at 5:52 PM, Kris Maglione 
> wrote:
>
> > On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:
> >
> >> For modules that have already converted, is there any performance change
> >> (good or bad) between async / await vs. Task?
> >>
> >
> > I haven't noticed any differences either way, but I also haven't done any
> > explicit profiling. There's definitely a difference in the way we collect
> > async stacks in async/await code vs. with the Promise.jsm promises that
> > Task.jsm uses, but that shouldn't show up much on release.
> >
> >
> > On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione 
> >> wrote:
> >>
> >> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
> >>>
> >>> Writing code in standard JS is always better for the web, makes it
> easier
>  to onboard new engineers and allows for better support in developer
>  tools.
>  So I'd like to propose that we switch to the standard way of writing
>  these
>  functions immediately. New code should use async/await instead of
>  Task.jsm
>  going forwards.
> 
> 
> >>> +1
> >>>
> >>> I've already started doing this in places where using Task.jsm was
> >>> unwieldy, and it's improved things tremendously.
> >>>
> >>
> ___
> 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: Switching to async/await from Task.jsm/yield

[J. Ryan Stinnett]

Sounds like a good change to make from the discussion so far.

If there are issues with stack traces, I would assume having more of our
code base using async / await is a good way to apply pressure for stack
trace improvements (if needed) that will benefit everyone.

- Ryan

On Thu, Mar 16, 2017 at 5:52 PM, Kris Maglione 
wrote:

> On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:
>
>> For modules that have already converted, is there any performance change
>> (good or bad) between async / await vs. Task?
>>
>
> I haven't noticed any differences either way, but I also haven't done any
> explicit profiling. There's definitely a difference in the way we collect
> async stacks in async/await code vs. with the Promise.jsm promises that
> Task.jsm uses, but that shouldn't show up much on release.
>
>
> On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione 
>> wrote:
>>
>> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
>>>
>>> Writing code in standard JS is always better for the web, makes it easier
 to onboard new engineers and allows for better support in developer
 tools.
 So I'd like to propose that we switch to the standard way of writing
 these
 functions immediately. New code should use async/await instead of
 Task.jsm
 going forwards.


>>> +1
>>>
>>> I've already started doing this in places where using Task.jsm was
>>> unwieldy, and it's improved things tremendously.
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:

For modules that have already converted, is there any performance change
(good or bad) between async / await vs. Task?


I haven't noticed any differences either way, but I also haven't 
done any explicit profiling. There's definitely a difference in 
the way we collect async stacks in async/await code vs. with the 
Promise.jsm promises that Task.jsm uses, but that shouldn't show 
up much on release.



On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione 
wrote:


On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:


Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions immediately. New code should use async/await instead of Task.jsm
going forwards.



+1

I've already started doing this in places where using Task.jsm was
unwieldy, and it's improved things tremendously.

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

Re: Switching to async/await from Task.jsm/yield

[J. Ryan Stinnett]

For modules that have already converted, is there any performance change
(good or bad) between async / await vs. Task?

- Ryan

On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione 
wrote:

> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
>
>> Writing code in standard JS is always better for the web, makes it easier
>> to onboard new engineers and allows for better support in developer tools.
>> So I'd like to propose that we switch to the standard way of writing these
>> functions immediately. New code should use async/await instead of Task.jsm
>> going forwards.
>>
>
> +1
>
> I've already started doing this in places where using Task.jsm was
> unwieldy, and it's improved things tremendously.
> ___
> 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: Switching to async/await from Task.jsm/yield

[Kris Maglione]

On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:

Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions immediately. New code should use async/await instead of Task.jsm
going forwards.


+1

I've already started doing this in places where using Task.jsm was 
unwieldy, and it's improved things tremendously.

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

Switching to async/await from Task.jsm/yield

[Dave Townsend]

For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions immediately. New code should use async/await instead of Task.jsm
going forwards.

Florian has some rough plans to automatically rewrite existing usages of
Task.jsm to the standard JS forms so for now don't worry much about going
and submitting patches to fix up existing code. Once that is done we can
remove Task.jsm from the tree.

Does anyone object to any of this?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform