Do we still have a chance to stop private fields (with #)?

[SCLeoX]

It is clear to me that this "consensus" in the committee is against the majority of the community other than tc39.

I just want to know, what people like me, who really do not want this private fields thing (with #) to be added into JavaScript, can do to prevent it from happening.

[littledan]

Honest question: How do you think we in TC39 should assess how the majority of the community will feel about a proposal once they try it out a bit? I want to figure out how we can improve the process for future proposals.

(I suggested that we require a transpiler implementation earlier in the process, but this suggestion was rejected by the committee; anyway, just an implementation isn't enough without a mechanism for collecting feedback.)

[mbrowne]

Just FYI to anyone who isn't aware, private fields using # are now available in Babel 7. I agree it would have been good if this had happened much earlier.

...and I just noticed that the readme of this repo has been updated as well, with the status of several implementations in progress, including a native one in Chrome (behind a flag).

[littledan]

Yes, delaying the Babel implementation was definitely an error on my part in this proposal.

[SCLeoX]

@littledan I think there should be a vote or something of similar nature when a proposal is controversial.

I had a discussion in a JavaScript group with a couple experienced JavaScript developer. We come to a consensus very quickly that the idea of having private fields are awesome, but # is just too ugly and weird.

Usually, when there is a new feature being add to JavaScript, we really get hyped but it is just not the case this time.

[jhpratt]

@SCLeoX And what is the alternative to #? The private keyword was rejected because it didn't meet all of the TC39's requirements.

[mbrowne]

@SCLeoX regarding developers who would vote solely based on their initial reactions of finding it "ugly and weird", without taking the time to deeply understand the technical considerations, I am glad that just the average developer cannot vote (and just to be clear, I am not a member of the committee). If the committee just had 2 or 3 members and/or they were totally disconnected from the community, that would be a real problem, but fortunately I think the community is overall pretty well-represented on the committee. At least 95% of the complaints about the syntax are coming from people who haven't really considered the technical issues involved, including those mentioned in the FAQ.

[SCLeoX]

@jhpratt
That is my problem though. I am saying it will be better if there can be alternative, but if not, I would rather not having this than having it.

[SCLeoX]

@mbrowne However, if you think about it, most of other proposal will not have any problem if any average developer can vote. On the other hand, I am almost certain that this # thing will have a hard time passing 50%.

Yes, I understand there is technical difficulties, but shouldn't we try not to disrupt the overall beauty of JavaScript at the same time?

[slikts]

There is a deeper ugliness in not being able to hide implementation details while still taking advantage of delegation. It complicates API design and implementation and invites poor practices. This should outweigh the syntax just being unfamiliar.

On the topic of voting: it's a bad idea simply because it's so open for manipulation and reflexive reactions. What's needed is thoughtful consideration, not counting upvotes or downvotes or sloganeering.

[mbrowne]

@SCLeoX

However, if you think about it, most of other proposal will not have any problem if any average developer can vote.

I highly doubt that is true. I haven't been very much involved in discussions about proposals other than this one (and a little bit with decorators), but I'm sure people can give examples of other proposals where making decisions just based on the community's initial uninformed reaction would have been disastrous.

Regarding the ugliness, that seems to be the common reaction and the committee members have said they don't find it aesthetically pleasing either and would have preferred to use a more intuitive syntax if possible. (I seem to be in the minority; I never disliked it for aesthetic reasons since I appreciated the conciseness, which is kind of handy if you believe as I do that encapsulation is really important and that "private" should be the starting point rather than just making things public without thinking about it. But I understand why others don't like it.) Anyway, it's not as if the committee deliberately chose this syntax against the wishes of the community. As explained in the FAQ and in past discussions here, significant problems were found with every other alternative that was presented.

[hax]

@SCLeoX @jhpratt

Alternatives without # existed. Check https://github.com/zenparsing/js-classes-1.1

Classes 1.1 proposal is created and presented by: zenparsing who is one of the champion of this proposal but do not agree # solution, awb who is the editor of ES2015, Brendan Eich who you must know.

But classes 1.1 is rejected, mainly because not include "public field", and I believe that is a big mistake.

You could check whether you like classes 1.1 and check recent issues in the repo for further discussion.

[hax]

@littledan

How do you think we in TC39 should assess how the majority of the community will feel about a proposal once they try it out a bit?

Simple.

I'd like to invite you, or any other champion who can represent this proposal to the one of the biggest front-end and JavaScript conference in Hangzhou, China on Jan 6, 2019. You can introduce this proposal, and I would like to present classes 1.1 proposal, and let them vote. 😂

Or, if you think I use my mother language in China is unfair to you ... it seems you will go to Tokyo next month give a speech. Just ask the organizer invite me too. Remember my English is very poor, but I still like to have a try.

[littledan]

I'd be really happy to attend a conference in China and discuss these sorts of issues (even though I only speak European languages--sorry!). I'm a bit overloaded on travel right now, and was thinking to try to take it slow after the Japan trip, but maybe some time later in 2019 would be good. Is there another conference in China that you'd recommend (or I could attend this one in 2020)?

[littledan]

I'd also be happy to have a video call to discuss this topic further, if folks would be interested.