Kai, I'll come at this from a full stack perspective - I've done a lot of
both front-end and Node.js work, and I know how they compare.
1. Promises are useful for pretty much any one-off async action. They're
*way* easier to manage than callbacks for anything substantial, and they
take less code.
2. Event emitters and callbacks are easier to manage for anything async
that's not one-off. They're much simpler than classes for most things.
3. Sometimes, if your view is a class, it's easier to add a `handleEvent`
and use the instance itself with multiple event handlers.
4. Node.js work usually requires a lot more one-off async actions (like
reading files) than the front end.
5. "JavaScript fatigue" has more to do with the mass of library options
(and is especially prevalent in React circles) than anything actually about
the language.
C#'s event model is like the DOM's or Node's if you were to factor event
names to separate variables, like `foo.bar.listen(callback)` instead of
`foo.on("bar", callback)`. Android's works similarly to JavaScript,
although it uses enums instead of strings.
Also, JavaScript idiomatically prefers classes without much inheritance,
and it prefers using promises/observables directly over wrapping them.
Don't confuse it with the typical Java/C# idiom of subclassing.
-----
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 Wed, Dec 20, 2017 at 12:04 PM, kai zhu <kaizhu...@gmail.com> wrote:
> > 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
