Question of the Day: What about all this asynchrony?

Michael Lewis mike at lew42.com
Wed Nov 8 20:28:42 UTC 2017


Wow dude... Again, you're trying to pick a fight.  I'm not "publicly
shaming" anyone, that's ridiculous.

All I have to say is, just watch.



On Wed, Nov 8, 2017 at 1:22 PM, Jeremy Martin <jmar777 at gmail.com> wrote:

> I don't represent TC39, and I don't like adding so much noise to this
> list, so this will be my last reply on the topic.
>
> There's nothing fundamentally wrong with what you want, but you're barking
> up the wrong tree to get it:
>
>
>> This (not concerning themselves with the end users experience) is a
>> mistake (an opinion).
>
>
> This group is acutely aware of, and concerned with, the end user
> experience. As previously stated, many (if not most) of the members
> actively contribute from their personal time to assist in these areas. But
> that *doesn't* mean that as a committee they are obligated to all aspects
> of the developer experience.
>
> 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.
>
>
> Whether scarce or abundant, when the "resource" is someone else's time and
> effort, you simply don't have any claim to it. If you want to help, then do
> it! Publicly shaming people who are *already* helping, simply because
> they're not helping where and how you want them to, is not ok, though.
>
> 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.
>
>
> I wasn't going to respond until I read this part. Someone has already
> spent hours upon hours researching and compiling a useful resource (*A
> General Theory of Reactivity*), and instead of reading it, you're
> demanding *more* time from complete strangers to distill it into the
> exact level of verbosity that *you* want. That's not ok, and not what
> this mailing list is for. People in this list dedicate countless hours to
> save other people time, but their efforts aren't at your beck and call.
>
> Visual development is inevitable.
>
>
> Even if I am 100% in support of that statement, that doesn't mean that the
> visual development facilities are a part of the language itself. Again, I'm
> not trying to say that you have bad ideas, just that you've found the wrong
> mailing list for some of these.
>
> There's no need for a governing body that's not doing their job.
>
>
> The abundance of new features in the language is prima facie evidence that
> they are doing their job. Their job just isn't what you want it to be.
>
> 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.
>
>
> That's fine, there's no harm in trying. But when the people you reach out
> to suggest that it's off topic or out of scope for the venue you've chosen,
> then it's not fine to start ranting and publicly shaming them.
>
> The problem is real.  The conclusion:  "won't fix".
>
>
> Yes, there is a real problem (at least a challenge, anyway). But the
> existence of a problem isn't a license to demand a solution from whomever
> you deem responsible. Even when members in this list have tried to offer
> some help, primarily by referencing relevant reading material, those
> efforts have been rejected because we didn't create the cliff notes for
> you. Again, I'm not the authority on what is or isn't within scope of this
> list, but the sum total of these demands, shaming, and wandering subject
> matter do not seem to be appropriate here.
>
>
> On Wed, Nov 8, 2017 at 1:05 PM, Michael Lewis <mike at lew42.com> wrote:
>
>>
>>
>> On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin <jmar777 at gmail.com> 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 (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.
>>>
>>
>> MDN is great, I find myself here frequently.
>>
>>
>>>
>>> *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.
>>>
>>
>> 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:
>>> http://exploringjs.com/.
>>>
>>> *Regarding the "closed" nature of TC39:*
>>>
>>> Most discussion happens here on this mailing list, in public. Copious
>>> meeting notes for all in-person meetings are available here, as well:
>>> http://tc39.github.io/tc39-notes/.
>>>
>>
>> So this mailing list is it, and it seems my efforts here are failing.
>>
>>
>>>
>>> *If you want to search past es-discuss threads:*
>>>
>>> https://esdiscuss.org/
>>>
>>>
>> 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 (https://github.com/kriskowal/gtor/).
>>> You obviously already mentioned this, but I encourage you to please go and
>>> read it. While this isn't a general resource for the language, it is the
>>> most comprehensive and useful exploration of this specific topic that I'm
>>> aware of, and I genuinely believe you would find it illuminating on why
>>> this complexity exists around asynchrony.
>>>
>>
>> If I get time, I might head back there.  Honestly, though, I'm looking
>> for simple summaries as opposed to exhaustive histories.  Give me the
>> takeaways.  Save me some time.  And, more importantly, what will the future
>> be like?  That's what I was in search of.  What has this committee
>> concluded on is the vision for the future (in terms of all the various
>> async solutions, and creating interoperable adapters)?  I don't think the
>> answer to this is in that document.
>>
>>
>>
>>>
>>> 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 <https://tc39.github.io/process-document/>
>> and this <https://github.com/tc39/proposals> and this
>> <http://tc39.github.io/tc39-notes/>.  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 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> 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>
>>>>> 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> 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> 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>
>>>>>>>> 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>
>>>>>>>>> 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> wrote:
>>>>>>>>>>
>>>>>>>>>>> Correct, `for..of` instead of `forEach`
>>>>>>>>>>>
>>>>>>>>>>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth <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> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> ... that should be `await doMoveAsync()`
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <
>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>> 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> 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> 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/to
>>>>>>>>>>>>>>>>> pic/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>
>>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>>>> 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> 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
>>>>>>>>>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> es-discuss mailing list
>>>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jeremy Martin
>>>>>>>>>> 661.312.3853 <(661)%20312-3853>
>>>>>>>>>> @jmar777 <https://twitter.com/jmar777> / @j
>>>>>>>>>> <https://stream.live/j>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> es-discuss mailing list
>>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> es-discuss mailing list
>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>> 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://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
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853 <(661)%20312-3853>
>>> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>>>
>>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853 <(661)%20312-3853>
> @jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171108/e7f5b656/attachment-0001.html>


More information about the es-discuss mailing list