criticizing tc39 for the current problems in frontend-development is fair-game.
many of theses issues wouldn't exist if tc39 had responsibly gatekeeped es6 with a more modest feature-set of languages-changes, instead of creating an entirely new language. On 11/9/17, Michael Lewis <m...@lew42.com> wrote: > On Wed, Nov 8, 2017 at 10:00 AM, Jeremy Martin <jmar...@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 <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 >>> >>> >> >> >> -- >> 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
