Question of the Day: What about all this asynchrony?

Isiah Meadows isiahmeadows at gmail.com
Wed Nov 8 19:06:36 UTC 2017


Michael,

>>
>>
>> Lambasting TC39 for not formalizing and centralizing these educational
>> resources -- a task that exists far outside of their charter -- is not
>> productive.
>
>
> This (not concerning themselves with the end users experience) is a mistake
> (an opinion).  The JavaScript community would be better off if more care
> were given to this aspect (not an opinion).
>

The point Jeremy was trying to make is that it's one thing to complain
that there doesn't exist any decent centralized resources about this
outside maybe MDN (which has a focus on docs, not so much tutorials or
committee stuff). TC39 does attempt to be as open as practically
possible, unusually more so than any other ECMA technical committee
(they've noted several struggles with ECMA and ISO here).

Also, most TC39 committee members are *excessively* busy, with
families, jobs, talks, and expert consultation. A little perspective
helps here.

>>
>>
>> Dr. Rauschmayer has also written a series of extraordinarily useful books
>> that he has graciously made freely available online, here:
>> http://exploringjs.com/.
>>
>> Regarding the "closed" nature of TC39:
>>
>> Most discussion happens here on this mailing list, in public. Copious
>> meeting notes for all in-person meetings are available here, as well:
>> http://tc39.github.io/tc39-notes/.
>
>
> So this mailing list is it, and it seems my efforts here are failing.
>

I wouldn't say they're failing so much as there's a lot more nuance
than what meets the eye. My complaints have historically been in the
case of certain implementors not being quite open enough on why they
would refuse to accept certain proposals ([Google on one of the
cancellation proposals][1], for example).

[1]: https://github.com/tc39/proposal-cancelable-promises/issues/70

>>
>>
>> For your specific questions about why we have Promises AND Generators AND
>> Iterators AND...
>>
>> The General Theory of Relativity (https://github.com/kriskowal/gtor/). You
>> obviously already mentioned this, but I encourage you to please go and read
>> it. While this isn't a general resource for the language, it is the most
>> comprehensive and useful exploration of this specific topic that I'm aware
>> of, and I genuinely believe you would find it illuminating on why this
>> complexity exists around asynchrony.
>
>
> If I get time, I might head back there.  Honestly, though, I'm looking for
> simple summaries as opposed to exhaustive histories.  Give me the takeaways.
> Save me some time.  And, more importantly, what will the future be like?
> That's what I was in search of.  What has this committee concluded on is the
> vision for the future (in terms of all the various async solutions, and
> creating interoperable adapters)?  I don't think the answer to this is in
> that document.

That does include some history, but it's probably more of an
exhaustive explanation of asynchrony than a simple summary.\*

\* It's actually called "A General Theory of Reactivity", for future readers.

>>
>> Tooling is best left to evolve independent of the language itself, rather
>> than being frozen at the specification level. Even the most basic developer
>> tools, like the `console` object, are not a part of the ecmascript spec -
>> they are host objects provided by the runtime.
>
>
> I understand.  Yet, many of the people on this list work on those runtime
> implementations (Chrome, node, whatever).  I'm reaching out to anyone who
> will listen.

Just because some of them work on tooling doesn't obligate them to
include any of it in the spec - in particular, it might encourage them
to leave certain things out, just to keep the tooling separate.
Another example: the C++ standard doesn't mandate any linter warnings,
but all major C++ compilers implement numerous linter options anyways.

> I guess the average developer is required to follow all the people, read all
> the blogs, come back to MDN every so often and reread the entire site to
> make sure they don't miss something that appears in there.

The average developer only really needs to care about what's shipping
in browsers, and IMHO, [JavaScript Weekly][2] fills 90% of that void
(it also includes other interesting developments). Pretty much
everything that's hit stage 4 (shipping in the next spec revision) has
made it to JavaScript Weekly, including smaller things like the
[template literal revision][3].

[2]: http://javascriptweekly.com/
[3]: http://javascriptweekly.com/issues/300

-----

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


More information about the es-discuss mailing list