<p dir="ltr">Front end.</p>
<p dir="ltr">You wouldn't create the uploader in a JavaScript class. You would do so in a component HTML template and use its associated JavaScript class as the model/controller layer. Async stuff is really easy. This doesn't change whether you use the class / a static function / another class.</p>
<p dir="ltr">Isiah - JavaScript has no idiomatic preference in terms of depth of inheritance for classes. In fact that's where classes become really useful in the first place.</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, 20 Dec 2017, 10:34 pm kai zhu, <<a href="mailto:kaizhu256@gmail.com">kaizhu256@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">> To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever.</p>
<p dir="ltr">did you do async with classes on the frontend or backend? because its generally more difficult to do when working with the ui (and also why javascript-fatigue is so prevalent among frontend developers).</p>
<p dir="ltr">for example (and this is a great frontend interview question btw), how many proponents on this mailing-list who envision transforming javascript into c# know how to implement a frontend-class to upload images/files (encompassing the ui-element, ajax form-uploader, progress-indicator, and post-upload previewer), that can be made re-usable across different use-cases such as facebook and gmail?  if you don't know how to implement such a re-usable class, then your opinion on the design and architecture of javascript classes doesn't mean much from a frontend-perspective.</p>
<p dir="ltr">i suspect most backend nodejs programmers would not know how to implement such re-usable code.  frontend-engineers otoh, are now constantly being asked to write such stuff using es6 classes (but its so simple! frontend! easy compared to backend!).  if many of the javascript new-comers transitioning from backend c# were put in such frontend-shoes, it wouldn't be hard to imagine them developing javascript-fatigue and burning out as well.</p>
<p dir="ltr">On Dec 20, 2017 3:02 PM, "Naveen Chawla" <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
><br>
> Aynchronicity has nothing to do with whether you use class instance methods or static functions. The only difference is whether `this` or an arg is the instance, and the ability to override in type hierarchies, and whether you can use a plain data object (without functions/methods) as the instance. Every other logical necessity when things change is the same.<br>
><br>
> Just use the one that's simpler to implement based on what your app is doing!<br>
><br>
> To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever.<br>
><br>
><br>
> On Wed, 20 Dec 2017, 8:44 am kai zhu, <<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>> wrote:<br>
>><br>
>> On Dec 19, 2017 01:36, "Naveen Chawla" <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
>> ><br>
>> > Using static methods with plain objects can be cool if you don't want method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish.<br>
>><br>
>> @naveen, have you tried adding asynchronous features (e.g. typeahead search or typeahead input-validation) to a frontend-ui that primarily relied on classes?  you generally cannot implement these features like you would for BLOCKING code (as taught in college cs) by simply updating a class-method or two.  in practice, you oftentimes have to rewrite the entire class to accomodate a "simple" ui feature-request that changed the async data-flow.  classes normally end up being a non-reusable pile of async-hacks as a frontend-ui evolves, which makes them no better than writing throwaway static-functions from the start.  at least there's no pretension for re-usability when writing throwaway static-functions, with the more realistic expectation they will be constantly re-written as async-feature-request get added.<br>
>><br>
>> > On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:<br>
>> >><br>
>> >> For one specific example, plain objects can be treated like C structs.<br>
>> >> For most scenarios you'd want "methods", you could get away just as<br>
>> >> easily with functions taking the instance as an argument (in<br>
>> >> particular, you could still use `this`, although I don't in practice).<br>
>> >><br>
>> >> I've used this pattern quite a bit when I have a bit of state that<br>
>> >> needs accessed in several places, but actions are more easily<br>
>> >> encapsulated. This isn't as elegant for things like DSLs, but it's<br>
>> >> useful for more stateful programming.<br>
>> >> -----<br>
>> >><br>
>> >> Isiah Meadows<br>
>> >> <a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br>
>> >><br>
>> >> Looking for web consulting? Or a new website?<br>
>> >> Send me an email and we can get started.<br>
>> >> <a href="http://www.isiahmeadows.com" target="_blank">www.isiahmeadows.com</a><br>
>> >><br>
>> >><br>
>> >> On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
>> >> > Javascript won't lose plain objects. Classes simplify cases of type<br>
>> >> > hierarchies that require overriden methods, and offer a memory performance<br>
>> >> > gain in the case of when there are many instances vs using plain objects to<br>
>> >> > do the same (which incurs a memory overhead for each instance's functions<br>
>> >> > even when they are the same as each other). The only encapsulated way of<br>
>> >> > doing this before ES6 was to use prototype, which is easier to get wrong<br>
>> >> > especially if there is more than two levels of depth of method inheritance.<br>
>> >> ><br>
>> >> > You get to chose what works for you. You can even argue for using plain<br>
>> >> > objects in certain cases where somebody has decided to use classes. That has<br>
>> >> > nothing to do with what the language offers for those whose applications are<br>
>> >> > simpler and more performant using classes instead.<br>
>> >> ><br>
>> >> > On Mon, 18 Dec 2017 at 03:31 Frederick Stark <<a href="mailto:coagmano@gmail.com" target="_blank">coagmano@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> I appreciate hearing Kai's point of view and think that we've had this<br>
>> >> >> exact discussion enough times. At this point it just adds to inbox weight<br>
>> >> >> without changing any minds<br>
>> >> >><br>
>> >> >> On Dec 18 2017, at 8:23 am, Terence M. Bandoian <<a href="mailto:terence@tmbsw.com" target="_blank">terence@tmbsw.com</a>> wrote:<br>
>> >> >>><br>
>> >> >>> I appreciate hearing Kai's point of view and don't think he should be<br>
>> >> >>> silenced.<br>
>> >> >>><br>
>> >> >>> -Terence Bandoian<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> On 12/17/2017 2:03 PM, T.J. Crowder wrote:<br>
>> >> >>><br>
>> >> >>> On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <<a href="mailto:ljharb@gmail.com" target="_blank">ljharb@gmail.com</a>> wrote:<br>
>> >> >>> ><br>
>> >> >>> > Adding features in *no way* sacrifices simplicity or ease-of-use<br>
>> >> >>> > for smaller web projects; as has been said many times on this<br>
>> >> >>> > list, if you don't like any new feature, simply choose not to use<br>
>> >> >>> > it.<br>
>> >> >>><br>
>> >> >>> And in many or even most cases, markedly *improves* simplicity and<br>
>> >> >>> ease-of-use. As has also been repeatedly pointed out.<br>
>> >> >>><br>
>> >> >>> Kai: Genuine questions are fine. Questions which are really just you<br>
>> >> >>> pushing your agenda of "don't change anything ever again" and your personal<br>
>> >> >>> -- and solitary -- claim that "all this new stuff makes life difficult for<br>
>> >> >>> people" are, at best, pointless. Your position has been made crystal clear.<br>
>> >> >>> There's no need to bang on about it.<br>
>> >> >>><br>
>> >> >>> -- T.J. Crowder<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> _______________________________________________<br>
>> >> >>> es-discuss mailing list<br>
>> >> >>> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> >> >>> <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> es-discuss mailing list<br>
>> >> >> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> >> >> <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>> >> ><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > es-discuss mailing list<br>
>> >> > <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> >> > <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>> >> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > es-discuss mailing list<br>
>> > <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>> > <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>> ><br></p>
</blockquote></div>