>
> 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.
foo.bar.listen(callback) is not an event but a signal.
On Wed, Dec 20, 2017 at 2:44 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:
> 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
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
