Question of the Day: What about all this asynchrony?

Michael Lewis mike at
Tue Nov 7 11:39:16 UTC 2017

*Side note about loading/defining Modules *(somewhat related to asynchrony)
I've been writing a Module loader that's a hybrid between require.js and
webpack.  And in doing so, the obvious end-game solution for modules is a
*GUI*.  A GUI to help you scaffold the folders, files, import statements,
package.json, and even the `var thing = require("thing")` statements.
Click a [ + ] button in the folder where I want my module, and browse
through a list of available modules to require, or go browse external
package managers to find additional modules.

This is sort of that AST stuff I was talking about over the weekend.
Instead of typing all this info into the file, it should be encoded.  So
webpack doesn't have to scan through and find your require statements, and
parse them.

Just one small piece of the big picture...  GUI all the things for the
ultimate developer experience!

On Tue, Nov 7, 2017 at 5:18 AM, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list