Question of the Day: What about all this asynchrony?

Naveen Chawla naveen.chwl at
Wed Nov 8 14:10:28 UTC 2017

I did help you. I answered your question: I said async functions are
preferable over all the other alternatives. And I said others can weigh in
with their own perspective if they disagree. Of course TC39 justifies their
decisions: but it's left up to us, as the developers, to find out what the
best way is. For example, I use "const" almost everywhere, but nobody at
TC39 told me to do that: they just introduced it and explained the
reasoning for its introduction. The same with boolean expressions: I use
things like `car &&` instead of `if(car)` but
nobody told me to do so: I just find it terser.

On Wed, 8 Nov 2017 at 19:30 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list