javascript vision thing

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

kai zhu

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#?

also, is another part of the vision to add features to javascript to solve special engineering-problems encountered by large companies like google/facebook/microsoft as a trade-off to simplicity and ease-of-use for smaller web-projects?


On Nov 29, 2017 02:45, "T.J. Crowder" <[hidden email]> wrote:
On Tue, Nov 28, 2017 at 7:41 PM, Isiah Meadows <[hidden email]> wrote:
>
> I think you pretty much hit the nail on the head here.
> Probably best if we can just let this thread die now.

Thirded. ;-)

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Pier Bover

I doubt there is a long term grand vision for JS. After all the focus is on small incremental changes.

Personally I'd love to see optional static typings implement into the language much like we had in ES4 but I feel it's too big of a change to be considered by TC39.

My hope now is on completely being able to replace JS by Web Assembly in a couple of years and write on whatever language I prefer.


On Sun, Dec 17, 2017, 3:42 AM kai zhu <[hidden email]> wrote:

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#?

also, is another part of the vision to add features to javascript to solve special engineering-problems encountered by large companies like google/facebook/microsoft as a trade-off to simplicity and ease-of-use for smaller web-projects?


On Nov 29, 2017 02:45, "T.J. Crowder" <[hidden email]> wrote:
On Tue, Nov 28, 2017 at 7:41 PM, Isiah Meadows <[hidden email]> wrote:
>
> I think you pretty much hit the nail on the head here.
> Probably best if we can just let this thread die now.

Thirded. ;-)

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Jordan Harband
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.

On Sun, Dec 17, 2017 at 6:21 AM, Pier Bover <[hidden email]> wrote:

I doubt there is a long term grand vision for JS. After all the focus is on small incremental changes.

Personally I'd love to see optional static typings implement into the language much like we had in ES4 but I feel it's too big of a change to be considered by TC39.

My hope now is on completely being able to replace JS by Web Assembly in a couple of years and write on whatever language I prefer.


On Sun, Dec 17, 2017, 3:42 AM kai zhu <[hidden email]> wrote:

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#?

also, is another part of the vision to add features to javascript to solve special engineering-problems encountered by large companies like google/facebook/microsoft as a trade-off to simplicity and ease-of-use for smaller web-projects?


On Nov 29, 2017 02:45, "T.J. Crowder" <[hidden email]> wrote:
On Tue, Nov 28, 2017 at 7:41 PM, Isiah Meadows <[hidden email]> wrote:
>
> I think you pretty much hit the nail on the head here.
> Probably best if we can just let this thread die now.

Thirded. ;-)

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

T.J. Crowder-2
On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Terence M. Bandoian
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Frederick Stark
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Naveen Chawla
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Isiah Meadows-2
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
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Naveen Chawla
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.

On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <[hidden email]> 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
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

kai zhu

On Dec 19, 2017 01:36, "Naveen Chawla" <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Naveen Chawla

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, <[hidden email]> wrote:

On Dec 19, 2017 01:36, "Naveen Chawla" <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >>> [hidden email]
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >>
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> [hidden email]
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

kai zhu

> 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" <[hidden email]> 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, <[hidden email]> wrote:
>>
>> On Dec 19, 2017 01:36, "Naveen Chawla" <[hidden email]> 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 <[hidden email]> 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
>> >> [hidden email]
>> >>
>> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >> >>> [hidden email]
>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >> >>
>> >> >> _______________________________________________
>> >> >> es-discuss mailing list
>> >> >> [hidden email]
>> >> >> https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > es-discuss mailing list
>> >> > [hidden email]
>> >> > https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Isiah Meadows-2
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
[hidden email]

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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> wrote:
>>
>> On Dec 19, 2017 01:36, "Naveen Chawla" <[hidden email]> 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 <[hidden email]> 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
>> >> [hidden email]
>> >>
>> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >> >>> [hidden email]
>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >> >>
>> >> >> _______________________________________________
>> >> >> es-discuss mailing list
>> >> >> [hidden email]
>> >> >> https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > es-discuss mailing list
>> >> > [hidden email]
>> >> > https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Pier Bover
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 <[hidden email]> 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
[hidden email]

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 <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> wrote:
>>
>> On Dec 19, 2017 01:36, "Naveen Chawla" <[hidden email]> 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 <[hidden email]> 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
>> >> [hidden email]
>> >>
>> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >> >>> [hidden email]
>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >> >>
>> >> >> _______________________________________________
>> >> >> es-discuss mailing list
>> >> >> [hidden email]
>> >> >> https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > es-discuss mailing list
>> >> > [hidden email]
>> >> > https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Naveen Chawla
In reply to this post by kai zhu

Front end.

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.

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.


On Wed, 20 Dec 2017, 10:34 pm kai zhu, <[hidden email]> 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" <[hidden email]> 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, <[hidden email]> wrote:
>>
>> On Dec 19, 2017 01:36, "Naveen Chawla" <[hidden email]> 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 <[hidden email]> 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
>> >> [hidden email]
>> >>
>> >> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >> >>> [hidden email]
>> >> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >> >>
>> >> >> _______________________________________________
>> >> >> es-discuss mailing list
>> >> >> [hidden email]
>> >> >> https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > es-discuss mailing list
>> >> > [hidden email]
>> >> > https://mail.mozilla.org/listinfo/es-discuss
>> >> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > [hidden email]
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

kai zhu
tldr - tc39 should focus more on JSON-friendly javascript-language-features instead of wasting-time on hard-to-serialize classes/meta-programming.

have you ever wondered why javascript is so popular? why you decided to become a nodejs/backend-javascript programmer?

javascript’s popularity is not because of any engineering/technical merits.  its entirely a derivative of the fact that browsers have taken over the world, and many new software-jobs are either frontend-related, or some [glorified] form of backend-support for the frontend.  the business-proposition for why your employer hired you as a nodejs-developer (vs. php, etc…), is likely because they thought using the same language as their frontend-developer, would allow you to better *support* the needs of the frontend.  and if you can’t do a better job at supporting the frontend than a cheaper php/etc… developer, then you honestly should be *fired* (or “promoted” to management).

my problem with tc39, is that they “claim” javascript is a general-purpose language (and try to design it as such), when industry-wise, its really not.  if javascript was not a browser-language, most employers could not justify hiring developers to create software with it.  if tc39 is sincerely interested in keeping javascript a dominant/relevant language in industry, they should focus on *practical* (vs *academic*) features that help it maintain its edge as a frontend/web-integration language over its competitors.

and the primary-edge javascript has over its competitors (in an industry dominated by web-programming), is that it can transparently manipulate-and-serialize JSON data-structures between frontend <-> backend systems, while competitors like java depend on clumsy, error-prone, class-constructors and custom-serializers.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

T.J. Crowder-2
On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <[hidden email]> wrote:
> tldr - tc39 should focus more on JSON-friendly javascript-language-features
> instead of wasting-time on hard-to-serialize classes/meta-programming.

This is a false dichotomy (the fallacy of the either/or choice). I'd
agree we're approaching, or at, the need for the next thing after
JSON, and that some focus on that would be a good thing. That doesn't
mean stopping work on other good things. Perhaps you could take the
lead on addressing the issues you run into. I'm sure constructive
input would be welcomed.

> my problem with tc39, is that they “claim” javascript is a general-purpose
> language (and try to design it as such), when industry-wise, its really not.

Yes, it is. Just because you don't see it that way doesn't mean others
don't. And others have been telling you they see it differently
repeatedly over a long period of time on this list.

> if tc39 is sincerely
> interested in keeping javascript a dominant/relevant language in industry,
> they should focus on *practical* (vs *academic*) features

`class` notation is practical (simplifying a common pattern and making
it less error-prone). (I know you don't use that pattern. That's fine.
But lots of people do, so it's practical for them whether you like the
pattern or not.) Promises are practical (simplifying and standardizing
callbacks, making them composable; again making them less
error-prone). `async`/`await` is HUGELY practical, massively
simplifying writing asynchronous code. Arrow functions, rest and
spread, default parameter values -- all practical. (NOT trying to put
words in your mouth, but if you were going to reply "Yes, but those
problems could already be solved in others ways.", then: Sure, and we
could all write assembly code, too. But it's *useful* to address these
in the language.)

All of them are useful beyond the web. All are also useful in web programming.

I have no problem with skepticism of specific proposals. What I would
find useful, though, would be a focus on the proposal's merits, rather
than constant re-raising of this claim that JavaScript is a web-only
language. You've made that claim, ad nauseum. My view is that it's
been rejected by the list membership and by TC39, but whether that's
true or I'm mistaken, please stop spamming the list with it. We all
know how you feel about it.

But again: I'm sure constructive, research-based input on how to deal
with JSON issues related to (for instance) BigInt would be welcome in
that BigInt thread and, ideally, eventually a proposal. There's no
need for some big conceptual argument over the course of the language
-- that *is* a waste of time.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Anders Rundgren-2
In reply to this post by kai zhu
On 2018-07-24 12:27, kai zhu wrote:
> tldr - tc39 should focus more on JSON-friendly javascript-language-features instead of wasting-time on hard-to-serialize classes/meta-programming.

JSON isn't really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place, including dealing with new data types like BigInt.

Personally I think the JSON WG should be rebooted but apparently I'm rather alone with that idea.

Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.

Anders



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Ranando King
Personally I think the JSON WG should be rebooted but apparently I'm rather alone with that idea.

You're not alone in wanting to see the JSON WG get back to work. I'd also like to see the addition of a syntax for serializing recursive structures.

On Tue, Jul 24, 2018 at 9:32 AM Anders Rundgren <[hidden email]> wrote:
On 2018-07-24 12:27, kai zhu wrote:
> tldr - tc39 should focus more on JSON-friendly javascript-language-features instead of wasting-time on hard-to-serialize classes/meta-programming.

JSON isn't really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place, including dealing with new data types like BigInt.

Personally I think the JSON WG should be rebooted but apparently I'm rather alone with that idea.

Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.

Anders



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Carsten Bormann
In reply to this post by Anders Rundgren-2
On Jul 24, 2018, at 16:31, Anders Rundgren <[hidden email]> wrote:
>
> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,

What is the best place where I should beat my wife?
No, that is not the question.

> including dealing with new data types like BigInt.

That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.

> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.

Indeed.

Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.  It is popular because it is extremely simple (at least on the surface), it is already familiar to users of most dynamic programming languages, and it hasn’t changed since 2002.  “Changing” JSON simply means no longer having JSON.

(And there are quite a few much better data interchange formats; maybe JavaScript can start to support some of them out of the box.)

> Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.

*Shudder*.   These are *not* needed for data interchange.  For configuration files and other data input by humans, DO NOT USE JSON.  If you need YAML(*) (which also has been fully stable for more than a decade, by the way), you know where to find it.  YAML also *is* the extended JSON that so many people are wishing for.

Grüße, Carsten

(*) and of course YAML supports graphs, binary (byte string) data, human-friendly input, etc.  It is approximately what any other effort to “humanize” JSON and fill in its shortcomings will arrive at eventually, just with some microdecisions you and I may not like but that are not relevant in the big picture.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12345