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 && car.drive()` instead of `if(car) car.drive()` but nobody told me to do so: I just find it terser.
On Wed, 8 Nov 2017 at 19:30 Michael Lewis <m...@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 <m...@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.c...@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 <m...@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 < >>>> felipenmo...@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 <m...@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 <jmar...@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.c...@gmail.com >>>>>>> > wrote: >>>>>>> >>>>>>>> Correct, `for..of` instead of `forEach` >>>>>>>> >>>>>>>> On Wed, 8 Nov 2017 at 01:21 Logan Smyth <loganfsm...@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.c...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> ... that should be `await doMoveAsync()` >>>>>>>>>> >>>>>>>>>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <naveen.c...@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 <m...@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 <m...@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.c...@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 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 <m...@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 <r...@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 < >>>>>>>>>>>>>>>> m...@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@mozilla.org >>>>>>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> es-discuss mailing list >>>>>>>>>>>>>>> es-discuss@mozilla.org >>>>>>>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> es-discuss mailing list >>>>>>>>>> es-discuss@mozilla.org >>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> es-discuss mailing list >>>>>>>> es-discuss@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@mozilla.org >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> es-discuss@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@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
