> To answer your question, yes I've done async with classes. It poses no
additional challenge whatsoever.

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).

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.

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.

On Dec 20, 2017 3:02 PM, "Naveen Chawla" <naveen.c...@gmail.com> wrote:
>
> 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.
>
> Just use the one that's simpler to implement based on what your app is
doing!
>
> To answer your question, yes I've done async with classes. It poses no
additional challenge whatsoever.
>
>
> On Wed, 20 Dec 2017, 8:44 am kai zhu, <kaizhu...@gmail.com> wrote:
>>
>> On Dec 19, 2017 01:36, "Naveen Chawla" <naveen.c...@gmail.com> wrote:
>> >
>> > 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.
>>
>> @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.
>>
>> > On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <isiahmead...@gmail.com>
wrote:
>> >>
>> >> For one specific example, plain objects can be treated like C structs.
>> >> For most scenarios you'd want "methods", you could get away just as
>> >> easily with functions taking the instance as an argument (in
>> >> particular, you could still use `this`, although I don't in practice).
>> >>
>> >> I've used this pattern quite a bit when I have a bit of state that
>> >> needs accessed in several places, but actions are more easily
>> >> encapsulated. This isn't as elegant for things like DSLs, but it's
>> >> useful for more stateful programming.
>> >> -----
>> >>
>> >> Isiah Meadows
>> >> m...@isiahmeadows.com
>> >>
>> >> Looking for web consulting? Or a new website?
>> >> Send me an email and we can get started.
>> >> www.isiahmeadows.com
>> >>
>> >>
>> >> On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <naveen.c...@gmail.com>
wrote:
>> >> > Javascript won't lose plain objects. Classes simplify cases of type
>> >> > hierarchies that require overriden methods, and offer a memory
performance
>> >> > gain in the case of when there are many instances vs using plain
objects to
>> >> > do the same (which incurs a memory overhead for each instance's
functions
>> >> > even when they are the same as each other). The only encapsulated
way of
>> >> > doing this before ES6 was to use prototype, which is easier to get
wrong
>> >> > especially if there is more than two levels of depth of method
inheritance.
>> >> >
>> >> > You get to chose what works for you. You can even argue for using
plain
>> >> > objects in certain cases where somebody has decided to use classes.
That has
>> >> > nothing to do with what the language offers for those whose
applications are
>> >> > simpler and more performant using classes instead.
>> >> >
>> >> > On Mon, 18 Dec 2017 at 03:31 Frederick Stark <coagm...@gmail.com>
wrote:
>> >> >>
>> >> >> I appreciate hearing Kai's point of view and think that we've had
this
>> >> >> exact discussion enough times. At this point it just adds to inbox
weight
>> >> >> without changing any minds
>> >> >>
>> >> >> On Dec 18 2017, at 8:23 am, Terence M. Bandoian <tere...@tmbsw.com>
wrote:
>> >> >>>
>> >> >>> I appreciate hearing Kai's point of view and don't think he
should be
>> >> >>> silenced.
>> >> >>>
>> >> >>> -Terence Bandoian
>> >> >>>
>> >> >>>
>> >> >>> On 12/17/2017 2:03 PM, T.J. Crowder wrote:
>> >> >>>
>> >> >>> On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <ljh...@gmail.com>
wrote:
>> >> >>> >
>> >> >>> > Adding features in *no way* sacrifices simplicity or ease-of-use
>> >> >>> > for smaller web projects; as has been said many times on this
>> >> >>> > list, if you don't like any new feature, simply choose not to
use
>> >> >>> > it.
>> >> >>>
>> >> >>> And in many or even most cases, markedly *improves* simplicity and
>> >> >>> ease-of-use. As has also been repeatedly pointed out.
>> >> >>>
>> >> >>> Kai: Genuine questions are fine. Questions which are really just
you
>> >> >>> pushing your agenda of "don't change anything ever again" and
your personal
>> >> >>> -- and solitary -- claim that "all this new stuff makes life
difficult for
>> >> >>> people" are, at best, pointless. Your position has been made
crystal clear.
>> >> >>> There's no need to bang on about it.
>> >> >>>
>> >> >>> -- T.J. Crowder
>> >> >>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> 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
>> >
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to