Thank you for this, Jeremy.
-Terence
On 11/8/2017 10:00 AM, Jeremy Martin 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.
>
> Lambasting TC39 for not formalizing and centralizing these educational
> resources -- a task that exists far outside of their charter -- is not
> productive.
>
> 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 (https://developer.mozilla.org/en-US/docs/Web/JavaScript). 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.
>
> */For non-formal discussion of cutting-edge, emergent features:/*
> */
> /*
> Axel Rauschmayer's blog (http://2ality.com/). As it pertains to some
> of your specific questions, there is a lot of great material here on
> Promises in particular.
>
> 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/.
>
> */If you want to search past es-discuss threads:/*
> */
> /*
> https://esdiscuss.org/
>
> */For "why doesn't this code work?" or "how do I do this?" questions:/*
> */
> /*
> StackOverflow (https://stackoverflow.com/). Still the gold standard
> here, IMO.
>
> */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.
>
> There are clearly many in addition to these, but that's a short list
> of some that I've personally found to be useful.
>
> ------
>
> 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.
>
> 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.
> 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.
>
> 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.
>
> On Wed, Nov 8, 2017 at 9:00 AM, Michael Lewis <mike at lew42.com
> <mailto:mike at lew42.com>> 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
> <https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/> 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
> <https://lew42.com/test/view42/View1/Clean/> 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 lew42.com
> <mailto:mike at lew42.com>> 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 <https://github.com/tc39/agendas/issues/272> 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 gmail.com <mailto:naveen.chwl at gmail.com>> 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 lew42.com
> <mailto:mike at lew42.com>> wrote:
>
> Hi Felipe,
>
> I read and generally understand your points (while I
> don't fully understand all the new async syntax and
> best practices
> <https://stackoverflow.com/questions/47178411/custom-thenables-can-i-create-my-own-objects-with-a-then-method>).
> 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
> <https://esdiscuss.org/topic/web-docs>. 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 gmail.com
> <mailto:felipenmoura at gmail.com>> 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 lew42.com <mailto:mike at lew42.com>> 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
> <https://medium.com/@benlesh/rxjs-observable-interop-with-promises-and-async-await-bebb05306875> 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 gmail.com <mailto:jmar777 at gmail.com>>
> 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?
> * ...do they work with Promises?
> * ...do 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 gmail.com
> <mailto:naveen.chwl at gmail.com>> wrote:
>
> Correct, `for..of` instead of `forEach`
>
> On Wed, 8 Nov 2017 at 01:21 Logan
> Smyth <loganfsmyth at gmail.com
> <mailto:loganfsmyth at gmail.com>> 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 gmail.com
> <mailto:naveen.chwl at gmail.com>> wrote:
>
> ... that should be `await
> doMoveAsync()`
>
> On Wed, 8 Nov 2017 at 01:16
> Naveen Chawla
> <naveen.chwl at gmail.com
> <mailto:naveen.chwl at gmail.com>>
> 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
> }
> );
> }
>
> ...so 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 lew42.com
> <mailto:mike at lew42.com>>
> 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 lew42.com
> <mailto:mike at lew42.com>>
> 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 gmail.com
> <mailto:naveen.chwl at gmail.com>>
> wrote:
>
> For me the
> future is
> async
> functions (the
> present
> actually). I
> asked a
> question about
> possible
> support for
> async streams
> / observables
> here:
> https://esdiscuss.org/topic/stream-async-await
> <https://esdiscuss.org/topic/stream-async-await>
> 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 lew42.com
> <mailto:mike at lew42.com>>
> 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 gol.com
> <mailto:rtm at gol.com>>
> 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 lew42.com
> <mailto:mike at lew42.com>>
> 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
> <https://esdiscuss.org/topic/promises-vs-streams> is
> an
> interesting
> thread
> (from
> es-discuss)
> regarding
> asynchrony,
> which
> references
> Kris
> Kowal's
> General
> Theory
> of
> Reactivity
> <https://github.com/kriskowal/gtor/>,
> 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
> <https://developers.google.com/web/fundamentals/primers/promises>.
> 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 mozilla.org
> <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
> _______________________________________________
> es-discuss
> mailing list
> es-discuss at mozilla.org
> <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853 <tel:%28661%29%20312-3853>
> @jmar777 <https://twitter.com/jmar777> /
> @j <https://stream.live/j>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
>
> --
> [ ]s
> *
> *
> *--*
> *
> *
> *Felipe N. Moura*
> Web Developer, Google Developer Expert
> <https://developers.google.com/experts/people/felipe-moura>,
> Founder of BrazilJS <https://braziljs.org/> and
> Nasc <http://nasc.io/>.
>
> Website: http://felipenmoura.com
> <http://felipenmoura.com/> / http://nasc.io/
> Twitter: @felipenmoura
> <http://twitter.com/felipenmoura>
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> ---------------------------------
> *Changing the world* is the least I expect from
> myself!
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
>
> --
> Jeremy Martin
> 661.312.3853
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>