Question of the Day: What about all this asynchrony?

kai zhu kaizhu256 at
Wed Nov 8 19:05:29 UTC 2017

criticizing tc39 for the current problems in frontend-development is fair-game.

many of theses issues wouldn't exist if tc39 had responsibly
gatekeeped es6 with a more modest feature-set of languages-changes,
instead of creating an entirely new language.

On 11/9/17, Michael Lewis <mike at> wrote:
> On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin <jmar777 at> wrote:
>> Michael,
>> You are not alone in your frustrations. Many of your points are valid,
>> have been voiced before, and will no doubt be voiced again. No one on
>> here
>> is unsympathetic to this, and many members of TC39, as well as other
>> community members, dedicate significant amounts of time, freely, to
>> educational resources.
> Thanks, it's a relief to finally hear.  This was definitely *not* the
> impression that I've gotten so far.  I've essentially heard, "there is no
> problem, what are you talking about?"
>> 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 list of useful resources out there is pretty extensive, and as you've
>> pointed out, that can have a downside if you don't know where to go. If
>> it's helpful, here's a non-canonical overview of some of the more useful
>> ones, though:
>> *For a one-stop shop:*
>> MDN ( If you
>> want a single destination, choose this one. It has introductory material,
>> beginner, intermediate, and advanced-level tutorials, and is the most
>> complete and well-maintained developer-focused JavaScript reference site.
> MDN is great, I find myself here frequently.
>> *For non-formal discussion of cutting-edge, emergent features:*
>> Axel Rauschmayer's blog ( As it pertains to some of
>> your specific questions, there is a lot of great material here on
>> Promises
>> in particular.
> I read a good portion of his Meta Programming chapter, and find myself here
> frequently.
>> Dr. Rauschmayer has also written a series of extraordinarily useful books
>> that he has graciously made freely available online, here:
>> *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:
> So this mailing list is it, and it seems my efforts here are failing.
>> *If you want to search past es-discuss threads:*
> Yes, my original post in this thread links there.  I'm aware that all these
> emails are public archived.
>> *For your specific questions about why we have Promises AND Generators
>> AND
>> Iterators AND...*
>> The General Theory of Relativity (
>> 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.
>> There are clearly many in addition to these, but that's a short list of
>> some that I've personally found to be useful.
> I sincerely appreciate your time in compiling the list.
>> ------
>> If you don't like that this all exists as discrete, separate resources,
>> then that's an opinion that you're entitled to. A canonical,
>> comprehensive,
>> and centralized resource for all of this would required thousands of
>> hours,
>> either volunteered or paid for by others, and that's something no one is
>> entitled to. If you want to make that happen, I suggest a strategy other
>> than reprimanding a group of people that are already contributing
>> significant time to what resources do exist.
> I understand, but we can always do better (nothing is perfect).  And that
> applies even with scarce resources.  It could be better.  I want to help.
>> Regarding topic appropriateness for this mailing list, admittedly the
>> lines can be blurry at times. GUI's and developer tooling are typically
>> outside of scope, though.  Visualizations around Promises are an
>> interesting topic, but as a non-TC39 member, I think I can still safely
>> say
>> that it won't be making it into the language itself.
> Visual development is inevitable.  If TC39 doesn't address it, then by the
> time visual development becomes the norm, TC39 probably won't exist.
> There's no need for a governing body that's not doing their job.
>> 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.
>> Again, I'm not trying to be dismissive of your ideas here, but the
>> validity of an idea or a frustration isn't the measure for whether or not
>> it's on-topic for es-discuss. If you want to continue discussing some of
>> your ideas for the language, I'm not discouraging you from that, but I
>> *am* encouraging you to perhaps choose one to start with, evolve the idea
>> until it's sufficiently clear and concrete to present for discussion.
> I don't want to break the rules and get removed from the list.  But it
> seems this list is powered by mozilla, and not "owned" by TC39 anyway.  And
> because there are no official topic rules, I think that discussing aspects
> that are *required* for JavaScript development is fair game.  Unless
> someone (at mozilla) requests otherwise.
> I'm learning very quickly that the problems are systemic, and yelling
> around here won't get anywhere.
> By the way, I just found this <>
> and this <> and this
> <>.  These would have been helpful a while
> ago.  Even still, they raise more questions than answers.  These won't help
> someone struggling to make sense of things.  They will only confuse them
> more.
> 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 problem is real.  The conclusion:  "won't fix".
>> On Wed, Nov 8, 2017 at 9:00 AM, Michael Lewis <mike at> wrote:
>>> How difficult is it for a web developer to make a website?
>>> What if everyone in this mailing list shared their personal websites,
>>> and
>>> we ranked them?  Not that mine is great, but at least I'm admitting that
>>> it's really fucking hard to make a simple website... I know a *lot *of
>>> web developers that *don't have their own website*.  And most that do,
>>> probably used WordPress, a static site generator, or another crutch.
>>> I was reading a post by Jake Archibald
>>> <>
>>> the
>>> other day, and noticed he had some interactive elements within the
>>> content
>>> of his page.  Wow, what a concept, right?  Besides some major news
>>> outlets,
>>> I very rarely see this on the web.  Aside from an image (non
>>> interactive)
>>> or a video (hardly "interactive"), how often do you see *interactive
>>> content* on the web?  Very rarely.  How long did it take to create?
>>> Jake says he spent his entire weekend on that one blog post.
>>> *THE WEB IS BROKEN.  FOR CHRIST'S SAKE.  *And yes, I understand that
>>> nobody in this mailing list cares.  Maybe I need to join the whatwg
>>> group,
>>> and yell at them.  Or maybe I just continue working on it, by myself, in
>>> my
>>> basement.  Or maybe I'll get some help someday.  Lead me, follow me, or
>>> get
>>> the fuck out of my way.
>>> Also, this is a fitting time to share a page
>>> <> I wanted to share a while
>>> back (due to Jeremy Martin's inability to imagine a visual development
>>> experience).  It doesn't live re-evaluate the code for each block, as it
>>> could.  But it shows some object renderings.  If you scroll down to the
>>> last test block, and click on the object titled "this", you'll see a
>>> rendering of the actual Test object.  You can see the 1 line of code
>>> used
>>> to render that:  View.inspect(this, "this");
>>> So yes, Jeremy, you could "automatically render Promise diagrams"...
>>> Maybe I'll get around to showing you how that works.
>>> What does your app *look like?*  Creating views for all the things is
>>> really important.  If you can see it, you can understand it.
>>> On Wed, Nov 8, 2017 at 7:39 AM, Michael Lewis <mike at> wrote:
>>>> So, the group that designs the language that the world uses for
>>>> building
>>>> web apps, cannot provide insight as to why they do what they do?
>>>> Smells
>>>> like bullshit.  Maybe you can expand on that part further?
>>>> Check this <> out.  It seems
>>>> the ECMA/TC39 group is closed to the public.
>>>> I'm just trying to make this easier for everyone...
>>>> This reminds me of our government, who writes laws so dense even the
>>>> lawmakers don't read them.  And then they expect everyone to abide by
>>>> them.  It's *somewhat* understandable (given the complexity of life).
>>>> Yet, there's an easy/obvious solution:  summarize, organize, and
>>>> simplify.
>>>> The law/specifications can be complex and simple, at the same time.  And
>>>> I
>>>> feel like it's the responsibility of those who understand it the best
>>>> to
>>>> accurately reduce the complexity into simpler form.
>>>> This process (organizing, summarizing, simplifying) is the ultimate key
>>>> to life.  Science, education, content, knowledge... Sometimes we do
>>>> this,
>>>> but it can always be done better.
>>>> Have we taken JavaScript knowledge, and organized, summarized, and
>>>> simplified it to its purest form?  Absolutely not.  Not even close.
>>>> In some areas of JS development (such as module management (dep mgmt,
>>>> loading/import), version control, debugging, persistence, etc) the
>>>> *best* solutions that we have, are *severely broken*, *have been broken
>>>> for decades*, and *TC39 isn't concerned with*.  That sounds like a
>>>> problem to me.  I'm sure everyone here would like to argue with me
>>>> about
>>>> this.  The point is to realize where these areas *can be better*, and
>>>> *make
>>>> them better*.  Not to argue about why they're not broken... Duh.
>>>> But, it seems like we need a new umbrella organization that's allowed
>>>> to
>>>> discuss the entire picture.  Hahaha... it's so stupid.  "Don't talk
>>>> about
>>>> that here."  "That's not a problem, you're the problem."  So much
>>>> broken.
>>>> On Wed, Nov 8, 2017 at 6:49 AM, Naveen Chawla <naveen.chwl at>
>>>> wrote:
>>>>> Hi Michael! TC39 is rightfully reluctant to offer usage advice. People
>>>>> should develop their best practices from experiences and the use cases
>>>>> they're involved in.
>>>>> For me, to answer your question, since I'm not a TC39 member, it's
>>>>> async functions all the way, and ditch observables, raw promises,
>>>>> callbacks. I'd love to hear from those who think observables might ever
>>>>> be
>>>>> preferable over using async functions to do the same thing... since I
>>>>> don't
>>>>> currently see how it could ever be
>>>>> On Wed, 8 Nov 2017 at 17:56 Michael Lewis <mike at> wrote:
>>>>>> Hi Felipe,
>>>>>> I read and generally understand your points (while I don't fully
>>>>>> understand all the new async syntax and best practices
>>>>>> <>).
>>>>>> You agree that there's a lot to learn, but nobody wants to even
>>>>>> acknowledge that this committee has the power (responsibility?) to fix
>>>>>> that
>>>>>> problem <>.  To make learning
>>>>>> simpler, easier, etc.  It could start with an official blog.  There
>>>>>> are too
>>>>>> many scattered resources.  Too much conflicting advice, and not an
>>>>>> official
>>>>>> direction.
>>>>>> If Babel is here to stay - and transpiling custom syntax into
>>>>>> official
>>>>>> syntax is going to proliferate, this problem will only get worse.
>>>>>> This has to do with leadership - there doesn't seem to be a strong
>>>>>> presence leading the pack.  There are millions of developers
>>>>>> scrambling to
>>>>>> make sense of all this stuff, and the best resources we have are the
>>>>>> continuous stream of blog posts that are constantly introducing new
>>>>>> things,
>>>>>> and often create more questions than answers.
>>>>>> It's clear to me that the people in this mailing list tend to stay at
>>>>>> the cutting edge.  You all read about the latest immediately when
>>>>>> it's
>>>>>> released.  It makes sense to you, and there is no problem.  The "rest
>>>>>> of
>>>>>> us" who struggle just aren't doing it right.
>>>>>> On Tue, Nov 7, 2017 at 6:09 PM, Felipe Nascimento de Moura <
>>>>>> felipenmoura at> wrote:
>>>>>>> Hi.
>>>>>>> Michael, the JavaScript (and Web in general) communities are very
>>>>>>> open and always queen to help.
>>>>>>> I just think you hit the wrong mailing list to discuss all that.
>>>>>>> For new comers, indeed, there is plenty to work on, practice and
>>>>>>> study. But keep in mind that many of those features came from
>>>>>>> different
>>>>>>> languages and technologies.
>>>>>>> And there are a lot of conferences, meetups, groups, slack channels,
>>>>>>> newsletters, articles, videos...tons of content out there :)
>>>>>>> Trying to answer your question.
>>>>>>> I understand the feeling you are having, but think it this way...
>>>>>>> - Asynchronous code opens doors for possible gains in performance.
>>>>>>> Many improvements have only been possible due to this
>>>>>>> asynchronicity.
>>>>>>> - Async code helps you modulate/split your code. If your are an
>>>>>>> organized person, it will be good...otherwise, things can get messy!
>>>>>>> - Async code nowadays can be dealt with, as if it was sync (using
>>>>>>> async await), the other way around was a problem! Many times you
>>>>>>> needed
>>>>>>> something asynchronous and had to create layers on top of it.
>>>>>>> - Async allows new APIs. For example, Web workers and Service
>>>>>>> Workers. They simply wouldn't be possible if not by asynchronous
>>>>>>> ways.
>>>>>>> - Creating async APIs allows developers to explore and use your API
>>>>>>> in different ways...also, if your code is well organized, it has an
>>>>>>> easier
>>>>>>> maintanence.
>>>>>>> - APIs related to interoperability and usability also benefit from
>>>>>>> this. Let's say, you need a user permission to do something and have
>>>>>>> to way
>>>>>>> for the user to agree with it. Or maybe you ware waiting for another
>>>>>>> app to
>>>>>>> answer with the result from something else, like a picture or a
>>>>>>> share(from
>>>>>>> shareAPI).
>>>>>>> As for "which" way you want to make your code async...that goes with
>>>>>>> what you are working on.
>>>>>>> If you are using promises, you can easily** have it working with
>>>>>>> async/await.
>>>>>>> Observables and promises can work together, but you will have to
>>>>>>> study a little further to feel familiar with it.
>>>>>>> I hope I have helped somehow :)
>>>>>>> On Tue, Nov 7, 2017 at 8:42 PM, Michael Lewis <mike at>
>>>>>>> wrote:
>>>>>>>> Making things simpler, clearer, and more visual has obvious
>>>>>>>> benefits.
>>>>>>>> I think I was very clear from the beginning that this was *NOT* a
>>>>>>>> concrete proposal.  And I've seen many posts on here that are not.
>>>>>>>> From
>>>>>>>> now on, I'll title my posts to more clearly indicate that *reading
>>>>>>>> is abstract, discussion, optional.*
>>>>>>>> The confusion about async interoperability
>>>>>>>> <>
>>>>>>>> isn't
>>>>>>>> mine alone.  I'm a new comer to this scene, and my original
>>>>>>>> curiosity was
>>>>>>>> this community's long-term vision for asynchrony.  How do we get all
>>>>>>>> the
>>>>>>>> pieces to play well together?  Thank you for contributing 0 to that
>>>>>>>> understanding.
>>>>>>>> And my point about the new comers to JavaScript or computers in
>>>>>>>> general, how are they to make sense of this ever-moving language?
>>>>>>>> You need
>>>>>>>> better documentation, publication (an official blog), etc.
>>>>>>>> On Tue, Nov 7, 2017 at 3:03 PM, Jeremy Martin <jmar777 at>
>>>>>>>> wrote:
>>>>>>>>> Michael,
>>>>>>>>> You've spent a considerable amount of time putting your thoughts
>>>>>>>>> into writing, so I don't intend to be dismissive of them, but this
>>>>>>>>> doesn't
>>>>>>>>> seem to be the right distribution channel for whatever you're
>>>>>>>>> getting at.
>>>>>>>>> As it stands, you've thrown quite a few questions out that don't
>>>>>>>>> seem to be related to the ongoing standardization and specification
>>>>>>>>> process
>>>>>>>>> that this group is primarily focused on. E.g.,
>>>>>>>>>    - Are RxJS Observables basically streams?
>>>>>>>>>    - What will our children be learning in 100 years?
>>>>>>>>>    - What are generators?
>>>>>>>>>    - they work with Promises?
>>>>>>>>>    - they work with streams?
>>>>>>>>>    - etc.
>>>>>>>>> There are reams of documentation, articles, and guides that delve
>>>>>>>>> into these topics in great detail, including the excellent
>>>>>>>>> *General
>>>>>>>>> Theory of Reactivity* that you already mentioned. The questions
>>>>>>>>> you've brought up are all valid, and these resources will help you
>>>>>>>>> gain the
>>>>>>>>> knowledge you need if you still want to put a specific proposal
>>>>>>>>> forward --
>>>>>>>>> but for now your points seem to awkwardly highlight that you've
>>>>>>>>> already
>>>>>>>>> identified the best resources to do this, but refuse to actually
>>>>>>>>> read them.
>>>>>>>>> And while es-discuss is indeed an appropriate place to solicit
>>>>>>>>> feedback on language-level proposals, the ideas you've thrown out
>>>>>>>>> read like
>>>>>>>>> an off-the-cuff stream of consciousness:
>>>>>>>>>    - Promises that automatically render diagrams?
>>>>>>>>>    - A GUI for loading/defining modules (somehow related to an
>>>>>>>>>    AST)?
>>>>>>>>>    - Async strings with some informal behavior around branching
>>>>>>>>>    and transforms, that are someone analogous to version control,
>>>>>>>>> and again, a
>>>>>>>>>    GUI is involved somewhere?
>>>>>>>>>    - Real-time booleans with change events (but with a new
>>>>>>>>>    definition for "change events" that is oddly based around a
>>>>>>>>> non-reactive
>>>>>>>>>    datastructure).
>>>>>>>>> I made an honest attempt to make it through your posts with an eye
>>>>>>>>> for what your point is, but these simply aren't concrete or
>>>>>>>>> coherent enough
>>>>>>>>> to facilitate a conversation, much less be actionable.
>>>>>>>>> The concept of "do it now" or "do it later" is as easy as 123.
>>>>>>>>> I urge you to consider that statements like this belie that you
>>>>>>>>> haven't grappled with the subject matter enough. It frankly
>>>>>>>>> trivializes the
>>>>>>>>> topic beyond recognition.
>>>>>>>>> If you have a concrete proposal you'd like to see discussed, then
>>>>>>>>> a
>>>>>>>>> dedicated thread with a clear description, examples, and motivating
>>>>>>>>> factors
>>>>>>>>> is completely welcome. If you're looking to rant or ruminate around
>>>>>>>>> topics
>>>>>>>>> like Promises, Generators, Observables, Streams, etc., while
>>>>>>>>> simultaneously
>>>>>>>>> admitting that you aren't taking the time to understand them, then
>>>>>>>>> this is
>>>>>>>>> simply the wrong venue.
>>>>>>>>> On Tue, Nov 7, 2017 at 3:13 PM, Naveen Chawla <
>>>>>>>>> naveen.chwl at> wrote:
>>>>>>>>>> Correct, `for..of` instead of `forEach`
>>>>>>>>>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth <loganfsmyth at>
>>>>>>>>>> wrote:
>>>>>>>>>>> A nit, but that would have to be `for (const move of moves) await
>>>>>>>>>>> doMoveAsync()`
>>>>>>>>>>> since the `forEach` callback is a normal function.
>>>>>>>>>>> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla <
>>>>>>>>>>> naveen.chwl at> wrote:
>>>>>>>>>>>> ... that should be `await doMoveAsync()`
>>>>>>>>>>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla
>>>>>>>>>>>> <naveen.chwl at>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> async functions create a new promise for you upon every
>>>>>>>>>>>>> invocation, which you resolve via `await`, but that's all
>>>>>>>>>>>>> invisible in the
>>>>>>>>>>>>> background. It's basically:
>>>>>>>>>>>>> async function doMovesAsync(){
>>>>>>>>>>>>>     moves.forEach(
>>>>>>>>>>>>>          move=>{
>>>>>>>>>>>>>               doMoveAsync(); //another async function
>>>>>>>>>>>>>          }
>>>>>>>>>>>>>     );
>>>>>>>>>>>>> }
>>>>>>>>>>>>> you can do regular programming, in async world. This is
>>>>>>>>>>>>> why I believe it's more powerful than observables, thereby
>>>>>>>>>>>>> making them
>>>>>>>>>>>>> redundant.
>>>>>>>>>>>>> When I say branching into multiple outputs, I do mean creating
>>>>>>>>>>>>> new data that leaves the original data untouched.
>>>>>>>>>>>>> On Tue, 7 Nov 2017 at 20:57 Michael Lewis <mike at>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Also, if you've made it this far, I think it's worth
>>>>>>>>>>>>>> mentioning that these async strings are basically all you need
>>>>>>>>>>>>>> for a
>>>>>>>>>>>>>> realtime file system.
>>>>>>>>>>>>>> File("newFile.ext").append(File("fileA"), File("fileB"),
>>>>>>>>>>>>>> ...).transpile().save();
>>>>>>>>>>>>>> // --> automatically watches, all inputs (fileA, fileB, etc),
>>>>>>>>>>>>>> caches unchanged files, reapplies transforms, writes to
>>>>>>>>>>>>>> file...
>>>>>>>>>>>>>> Webpack and gulp are basically async plugin systems w/
>>>>>>>>>>>>>> transforms.  They're just way too complicated.
>>>>>>>>>>>>>> Simplify all the things.
>>>>>>>>>>>>>> And while we're at it, why not make a realtime version
>>>>>>>>>>>>>> control
>>>>>>>>>>>>>> system?  Not just for files, but for all the things (any data
>>>>>>>>>>>>>> structure
>>>>>>>>>>>>>> inside the app).  For example, if we have variable strings,
>>>>>>>>>>>>>> could we enable
>>>>>>>>>>>>>> a history on it?  Instead of branching onto a separate
>>>>>>>>>>>>>> entity/value, could
>>>>>>>>>>>>>> we branch *within *the string itself, so that we have an
>>>>>>>>>>>>>> entire *verrsion tree *for any value?
>>>>>>>>>>>>>> *What are the fundamental data structures in computer
>>>>>>>>>>>>>> science?*
>>>>>>>>>>>>>> The Boolean, obviously.  The Integer.  The String.
>>>>>>>>>>>>>> Why not a realtime boolean?  I suppose that's just a boolean
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> change events.  What is a "change event"?  Just an array of
>>>>>>>>>>>>>> functions.  But
>>>>>>>>>>>>>> JavaScript functions are an abstract concept (compared to
>>>>>>>>>>>>>> processor
>>>>>>>>>>>>>> instructions).  What do functions look like at the processor
>>>>>>>>>>>>>> level?
>>>>>>>>>>>>>> They're compiled with all the dependent values, right?  How
>>>>>>>>>>>>>> many processor
>>>>>>>>>>>>>> ticks does the average line of JavaScript use?
>>>>>>>>>>>>>> I feel like all languages could boil down to a very small set
>>>>>>>>>>>>>> of fundamental data structures, and maybe a slightly larger
>>>>>>>>>>>>>> set of
>>>>>>>>>>>>>> specialized data structures.
>>>>>>>>>>>>>> What are the different types of circuits in a process?  I
>>>>>>>>>>>>>> understand (roughly) the basic logic gates, but is there
>>>>>>>>>>>>>> specialized
>>>>>>>>>>>>>> circuitry for specialized data structures?  What if those
>>>>>>>>>>>>>> fundamental data
>>>>>>>>>>>>>> structures were optimized at the circuitry level?
>>>>>>>>>>>>>> What if we can optimize our programs to run as nearly
>>>>>>>>>>>>>> instantly as possible?  Most scripts are *mostly *instant -
>>>>>>>>>>>>>> at least, there's no external input.  For any process that's
>>>>>>>>>>>>>> *nearly* instant, couldn't it actually be instant?  In other
>>>>>>>>>>>>>> words, 1 tick of the processor?  Load up all the registers
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> necessary values, and shine the light down those
>>>>>>>>>>>>>> transistors/logic gates,
>>>>>>>>>>>>>> so that we arrive at our result, instantly?
>>>>>>>>>>>>>> I really feel like this is possible.  Like I mentioned
>>>>>>>>>>>>>> earlier, I've never compiled a lick of code in my life, and
>>>>>>>>>>>>>> have very
>>>>>>>>>>>>>> little understanding of those things.  But from my sense of
>>>>>>>>>>>>>> JavaScript,
>>>>>>>>>>>>>> it's far from instant.  How many processor ticks per line of
>>>>>>>>>>>>>> JavaScript
>>>>>>>>>>>>>> code, on average?
>>>>>>>>>>>>>> Is anyone still listening?
>>>>>>>>>>>>>> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis
>>>>>>>>>>>>>> <mike at>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> I'm not experienced in async/await enough to know what
>>>>>>>>>>>>>>> "using
>>>>>>>>>>>>>>> async functions to process [streams]" would look like.
>>>>>>>>>>>>>>> You would have to create a new promise for every iteration?
>>>>>>>>>>>>>>> Even if performance isn't an issue, it just doesn't make
>>>>>>>>>>>>>>> sense to me.  It's
>>>>>>>>>>>>>>> like, you could use `obj.value = "my string"` instead of `var
>>>>>>>>>>>>>>> myString =
>>>>>>>>>>>>>>> "my string"`, and it will work.  And the performance
>>>>>>>>>>>>>>> difference is
>>>>>>>>>>>>>>> negligible.  But, it just doesn't make as much sense...
>>>>>>>>>>>>>>> *Branching vs Mutation*
>>>>>>>>>>>>>>> The point you bring up regarding "branching the stream into
>>>>>>>>>>>>>>> multiple outputs" is another fundamental concept in
>>>>>>>>>>>>>>> programming (that I'm
>>>>>>>>>>>>>>> still trying to wrap my head around).  Basically, does an
>>>>>>>>>>>>>>> operation (aka a
>>>>>>>>>>>>>>> method) operate on the original data, or fork/branch,
>>>>>>>>>>>>>>> preserving the
>>>>>>>>>>>>>>> original, and creating a clone to apply the transform to.
>>>>>>>>>>>>>>> For example, arr.push() manipulates (mutates) the original
>>>>>>>>>>>>>>> array, but arr.slice() branches, giving you a brand new
>>>>>>>>>>>>>>> array, leaving the
>>>>>>>>>>>>>>> underlying array untouched (immutable).
>>>>>>>>>>>>>>> This has always been an area of confusion for me.  Which
>>>>>>>>>>>>>>> methods are mutators, and which are immutable?
>>>>>>>>>>>>>>> *Async Strings*
>>>>>>>>>>>>>>> An interesting away to look at all this async stuff, is to
>>>>>>>>>>>>>>> consider strings, and their operations (methods), in an
>>>>>>>>>>>>>>> asynchronous way.
>>>>>>>>>>>>>>> How can a string be asynchronous?  Just let it change over
>>>>>>>>>>>>>>> time, and
>>>>>>>>>>>>>>> broadcast change events.
>>>>>>>>>>>>>>> What if you compose a string with several pieces:
>>>>>>>>>>>>>>>  asyncParentStr.append(asyncStrA, asyncStrB, asyncStrC).
>>>>>>>>>>>>>>> Each asyncString can have change events, and will propagate
>>>>>>>>>>>>>>> changes to anyone depending on it.   asyncStrB.set("new
>>>>>>>>>>>>>>> value") will
>>>>>>>>>>>>>>> trigger asyncParentStr.change() event.
>>>>>>>>>>>>>>> I feel like this is fundamental functionality that is
>>>>>>>>>>>>>>> lacking
>>>>>>>>>>>>>>> from JavaScript.  Now that we have `const`, shouldn't `var`
>>>>>>>>>>>>>>> automatically
>>>>>>>>>>>>>>> set up change events for that "var"?
>>>>>>>>>>>>>>> *Async transforms*
>>>>>>>>>>>>>>> But lets say we do asyncParentStr.append(asyncStrA,
>>>>>>>>>>>>>>> asyncStrB.replace("hello", "goodbye"), asyncStrC).
>>>>>>>>>>>>>>> Now we have the question: do we want this .replace() to be a
>>>>>>>>>>>>>>> "live" transform?  When we asyncStrB.set("hello world"), does
>>>>>>>>>>>>>>> it re-apply
>>>>>>>>>>>>>>> the replace?  I think there are many use cases for both:
>>>>>>>>>>>>>>> mutate the
>>>>>>>>>>>>>>> original asyncStrB, so that all references to this value also
>>>>>>>>>>>>>>> exhibit the
>>>>>>>>>>>>>>> transform.  And also the alternative, the immutable,
>>>>>>>>>>>>>>> branching kind of
>>>>>>>>>>>>>>> transform, where you don't mutate the underlying value, and
>>>>>>>>>>>>>>> instead are
>>>>>>>>>>>>>>> branching.
>>>>>>>>>>>>>>> This concept is also the core concept of version control: do
>>>>>>>>>>>>>>> we continue down the same path, or branch off?
>>>>>>>>>>>>>>> *GUIs will prevail*
>>>>>>>>>>>>>>> You can try and create different methods ( ._replace() vs
>>>>>>>>>>>>>>> .$replace() ) to represent transform vs branching (I don't
>>>>>>>>>>>>>>> know which looks
>>>>>>>>>>>>>>> more like which).  But, in the end, the GUI will prevail.
>>>>>>>>>>>>>>> Artists can
>>>>>>>>>>>>>>> dream about how to envision these version trees, and perfect
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> GUI/experience.  The code interface just can't compete with
>>>>>>>>>>>>>>> GUI, in the
>>>>>>>>>>>>>>> long run.
>>>>>>>>>>>>>>> I suppose, its necessarily true that the API preceeds the
>>>>>>>>>>>>>>> GUI.
>>>>>>>>>>>>>>> API before GUI, but GUI all the things.  That's my new
>>>>>>>>>>>>>>> motto.
>>>>>>>>>>>>>>> *What if variables were automatically async, and
>>>>>>>>>>>>>>> referential?
>>>>>>>>>>>>>>> *(As opposed to `const` that could be the immutable flavor)
>>>>>>>>>>>>>>> var str = "hello world";
>>>>>>>>>>>>>>> str.replace("hello", "goodbye"); // transforms `str` var "in
>>>>>>>>>>>>>>> place"
>>>>>>>>>>>>>>> log(str) // "goodbye world"
>>>>>>>>>>>>>>> str = "hello cruel world"; // transform is reapplied
>>>>>>>>>>>>>>> log(str) // "goodbye cruel world"
>>>>>>>>>>>>>>> This will never happen, but it shows the fundamental
>>>>>>>>>>>>>>> difference in logic.  Both are logical/useful...
>>>>>>>>>>>>>>> On Tue, Nov 7, 2017 at 8:08 AM, Naveen Chawla <
>>>>>>>>>>>>>>> naveen.chwl at> wrote:
>>>>>>>>>>>>>>>> For me the future is async functions (the present
>>>>>>>>>>>>>>>> actually).
>>>>>>>>>>>>>>>> I asked a question about possible support for async streams
>>>>>>>>>>>>>>>> / observables
>>>>>>>>>>>>>>>> here: and I
>>>>>>>>>>>>>>>> realized that my use case was much better served by just
>>>>>>>>>>>>>>>> using async
>>>>>>>>>>>>>>>> functions to process each input value in the stream.
>>>>>>>>>>>>>>>> I think using async functions is much more powerful than
>>>>>>>>>>>>>>>> "observables", since it allows you to easily branch the
>>>>>>>>>>>>>>>> stream off into
>>>>>>>>>>>>>>>> multiple outputs etc. Using Promise.all etc. is also trivial
>>>>>>>>>>>>>>>> to use where
>>>>>>>>>>>>>>>> desired, etc.
>>>>>>>>>>>>>>>> Furthermore, async functions allow while/for loops that
>>>>>>>>>>>>>>>> include other async function calls, and this looks like
>>>>>>>>>>>>>>>> programming with
>>>>>>>>>>>>>>>> regular functions, so it's trivial to set up asynchronous
>>>>>>>>>>>>>>>> iteration, and/or
>>>>>>>>>>>>>>>> infinite event processing, etc., even without the new "async
>>>>>>>>>>>>>>>> iteration"
>>>>>>>>>>>>>>>> proposal.
>>>>>>>>>>>>>>>> On Tue, 7 Nov 2017 at 17:25 Michael Lewis <mike at>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> The email wasn't about my kids, and you don't have to read
>>>>>>>>>>>>>>>>> it (duh).  If your time is so valuable, maybe you shouldn't
>>>>>>>>>>>>>>>>> be picking
>>>>>>>>>>>>>>>>> fights with rambling parents.
>>>>>>>>>>>>>>>>> Where is the list of approved topics?
>>>>>>>>>>>>>>>>> On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers <rtm at>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> I'm confused. You don't have time to read "The General
>>>>>>>>>>>>>>>>>> Theory of Reactivity", yet (1) you have time to write this
>>>>>>>>>>>>>>>>>> long, rambling
>>>>>>>>>>>>>>>>>> email about your kids, and (2) expect people on this
>>>>>>>>>>>>>>>>>> mailing list to spend
>>>>>>>>>>>>>>>>>> their valuable time reading it?
>>>>>>>>>>>>>>>>>> Please stay on topic for the list.
>>>>>>>>>>>>>>>>>> Bob
>>>>>>>>>>>>>>>>>> On Tue, Nov 7, 2017 at 4:48 PM, Michael Lewis <
>>>>>>>>>>>>>>>>>> mike at> wrote:
>>>>>>>>>>>>>>>>>>> Good morning JavaScript world,
>>>>>>>>>>>>>>>>>>> Maybe I'll start my mornings with a cup of coffee, and a
>>>>>>>>>>>>>>>>>>> discussion prompt.  We'll see how long it lasts.  It's
>>>>>>>>>>>>>>>>>>> 4:39am.  I live in
>>>>>>>>>>>>>>>>>>> Aurora, Illinois, about an hour outside of Chicago.  My
>>>>>>>>>>>>>>>>>>> kids will wake up
>>>>>>>>>>>>>>>>>>> in an hour or two, so I don't have long, and should be
>>>>>>>>>>>>>>>>>>> working on my
>>>>>>>>>>>>>>>>>>> framework anyway.
>>>>>>>>>>>>>>>>>>> *So much asynchrony*
>>>>>>>>>>>>>>>>>>> There are callbacks, promises, async/await.  We have
>>>>>>>>>>>>>>>>>>> streams in node.js.  There are libraries like RxJS for
>>>>>>>>>>>>>>>>>>> Observables (that
>>>>>>>>>>>>>>>>>>> are basically streams?).
>>>>>>>>>>>>>>>>>>> What's the end game?  What will our children's children
>>>>>>>>>>>>>>>>>>> be learning in 100 years?  Let's reduce these pieces,
>>>>>>>>>>>>>>>>>>> distilling them into
>>>>>>>>>>>>>>>>>>> their simplest components.
>>>>>>>>>>>>>>>>>>> This <>
>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> an interesting thread (from es-discuss) regarding
>>>>>>>>>>>>>>>>>>> asynchrony, which
>>>>>>>>>>>>>>>>>>> references Kris Kowal's General Theory of Reactivity
>>>>>>>>>>>>>>>>>>> <>, which is too long
>>>>>>>>>>>>>>>>>>> for me to dig into at this point in my life.
>>>>>>>>>>>>>>>>>>> The disappointing part, is that this community (who has
>>>>>>>>>>>>>>>>>>> mastered asynchrony) doesn't feel like there are any
>>>>>>>>>>>>>>>>>>> shortcomings, and so
>>>>>>>>>>>>>>>>>>> we continue onward without fixing the mess.
>>>>>>>>>>>>>>>>>>> Oh, and generators?  I don't fully understand these
>>>>>>>>>>>>>>>>>>> things.  Do they work with promises?  Can you use a
>>>>>>>>>>>>>>>>>>> generator to process a
>>>>>>>>>>>>>>>>>>> stream?  How do generators work with or compare to
>>>>>>>>>>>>>>>>>>> async/await?  Who
>>>>>>>>>>>>>>>>>>> knows...
>>>>>>>>>>>>>>>>>>> I think it's safe to say that asynchrony is a confusing
>>>>>>>>>>>>>>>>>>> mess.  *But it shouldn't be.   *The concept of "do it
>>>>>>>>>>>>>>>>>>> now" or "do it later" is as easy as 123.
>>>>>>>>>>>>>>>>>>> Recently, I read through Jake Archibald's JavaScript
>>>>>>>>>>>>>>>>>>> Promises: an Introduction
>>>>>>>>>>>>>>>>>>> <>.
>>>>>>>>>>>>>>>>>>> I really enjoy Jake Archibald's writing.  He makes
>>>>>>>>>>>>>>>>>>> JavaScript less boring.
>>>>>>>>>>>>>>>>>>> But wow, understanding promises in their full depth is
>>>>>>>>>>>>>>>>>>> really complicated.
>>>>>>>>>>>>>>>>>>> Sure, a simple promise is more or less a callback, easy
>>>>>>>>>>>>>>>>>>> peasy.  But once
>>>>>>>>>>>>>>>>>>> you start composing parallel and series tasks, add error
>>>>>>>>>>>>>>>>>>> handling, and try
>>>>>>>>>>>>>>>>>>> to understand the control flow - it's a lot.
>>>>>>>>>>>>>>>>>>> I feel like Promises could automatically *render a
>>>>>>>>>>>>>>>>>>> diagram *when using them.  In Jake's very practical
>>>>>>>>>>>>>>>>>>> example (request a list of chapters, load all chapters in
>>>>>>>>>>>>>>>>>>> parallel, then
>>>>>>>>>>>>>>>>>>> append them to the page in order) there's a lot going on,
>>>>>>>>>>>>>>>>>>> to say the
>>>>>>>>>>>>>>>>>>> least.  Wouldn't it be nice to see a diagram of these
>>>>>>>>>>>>>>>>>>> tasks?  A timeline
>>>>>>>>>>>>>>>>>>> maybe?
>>>>>>>>>>>>>>>>>>> Imagine debugging a complex sequence of async actions.
>>>>>>>>>>>>>>>>>>> And you have no idea which piece is failing.  Using the
>>>>>>>>>>>>>>>>>>> console to log
>>>>>>>>>>>>>>>>>>> values, and trying to step through the code with the
>>>>>>>>>>>>>>>>>>> debugger are two of
>>>>>>>>>>>>>>>>>>> your basic approaches.  But honestly, neither of these
>>>>>>>>>>>>>>>>>>> really *show
>>>>>>>>>>>>>>>>>>> *you what's going on.
>>>>>>>>>>>>>>>>>>> Chrome Dev Tools has an awesome timeline GUI.  I've
>>>>>>>>>>>>>>>>>>> spent
>>>>>>>>>>>>>>>>>>> an hour here or there tinkering with it, but can't make
>>>>>>>>>>>>>>>>>>> sense of a lot of
>>>>>>>>>>>>>>>>>>> it.  There are 100's if not 1000's of very generic blocks
>>>>>>>>>>>>>>>>>>> that show up on
>>>>>>>>>>>>>>>>>>> the timeline, that don't clearly identify what they are.
>>>>>>>>>>>>>>>>>>> And I don't
>>>>>>>>>>>>>>>>>>> believe there's any way to visualize promises on this
>>>>>>>>>>>>>>>>>>> timeline.
>>>>>>>>>>>>>>>>>>> *The problem with Promises*
>>>>>>>>>>>>>>>>>>> I want to create a file system framework for node.  I'd
>>>>>>>>>>>>>>>>>>> like to make watching the files for changes a default
>>>>>>>>>>>>>>>>>>> feature.  The problem
>>>>>>>>>>>>>>>>>>> with promises, is that you can't re-resolve them.
>>>>>>>>>>>>>>>>>>> So I'm basically left with streams, or plain old
>>>>>>>>>>>>>>>>>>> callbacks.  Or trying to recreate the promises every time
>>>>>>>>>>>>>>>>>>> they resolve...
>>>>>>>>>>>>>>>>>>> What's the end game?  100 years from now?
>>>>>>>>>>>>>>>>>>> Frankly, this is the most important question.  I feel
>>>>>>>>>>>>>>>>>>> like if we take a step back, and try to solve these
>>>>>>>>>>>>>>>>>>> problems for the long
>>>>>>>>>>>>>>>>>>> term, we'd be better off.
>>>>>>>>>>>>>>>>>>> And so, it's 5:15.  Well done, Michael.  Well done.
>>>>>>>>>>>>>>>>>>> *The Future*
>>>>>>>>>>>>>>>>>>> If anyone has made it this far, I'm going to tell you a
>>>>>>>>>>>>>>>>>>> quick summary of my plan:
>>>>>>>>>>>>>>>>>>>    1. make an ultra-simple web framework (almost done?)
>>>>>>>>>>>>>>>>>>>    2. use that framework to make a CMS to kill WordPress
>>>>>>>>>>>>>>>>>>>    3. turn that CMS into a web OS that does everything a
>>>>>>>>>>>>>>>>>>>    real OS can do, only better
>>>>>>>>>>>>>>>>>>>    4. turn that web OS into a real, bare metal OS
>>>>>>>>>>>>>>>>>>>    5. make lots of amazing (useful) software (like
>>>>>>>>>>>>>>>>>>>    photoshop, blender, after effects, CAD, etc)
>>>>>>>>>>>>>>>>>>> Software development is sluggish.  Most software is
>>>>>>>>>>>>>>>>>>> painful to use.  Windows, Photoshop/Illustrator, many
>>>>>>>>>>>>>>>>>>> websites...  Open
>>>>>>>>>>>>>>>>>>> source software doesn't get the funding/momentum it needs
>>>>>>>>>>>>>>>>>>> to really kill
>>>>>>>>>>>>>>>>>>> these proprietary alternatives.  We need to change that.
>>>>>>>>>>>>>>>>>>> I'm going to
>>>>>>>>>>>>>>>>>>> change that.
>>>>>>>>>>>>>>>>>>> Stay tuned.
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>>>>>>>>>> es-discuss at
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>>>>>>>> es-discuss at
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>>> es-discuss at
>>>>>>>>>> _______________________________________________
>>>>>>>>>> es-discuss mailing list
>>>>>>>>>> es-discuss at
>>>>>>>>> --
>>>>>>>>> Jeremy Martin
>>>>>>>>> 661.312.3853 <(661)%20312-3853>
>>>>>>>>> @jmar777 <> / @j
>>>>>>>>> <>
>>>>>>>>> _______________________________________________
>>>>>>>>> es-discuss mailing list
>>>>>>>>> es-discuss at
>>>>>>>> _______________________________________________
>>>>>>>> es-discuss mailing list
>>>>>>>> es-discuss at
>>>>>>> --
>>>>>>> [ ]s
>>>>>>> *--*
>>>>>>> *Felipe N. Moura*
>>>>>>> Web Developer, Google Developer Expert
>>>>>>> <>, Founder
>>>>>>> of BrazilJS <> and Nasc <>.
>>>>>>> Website: /
>>>>>>> Twitter:    @felipenmoura <>
>>>>>>> Facebook:
>>>>>>> LinkedIn:
>>>>>>> ---------------------------------
>>>>>>> *Changing  the  world*  is the least I expect from  myself!
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> --
>> Jeremy Martin
>> 661.312.3853 <(661)%20312-3853>
>> @jmar777 <> / @j <>

More information about the es-discuss mailing list