Hacker News Reader

Comment by gardaani | Hacker News Reader

If you think that the # syntax for private fields needs to be improved, then go to JS Committee's GitHub Issues and give feedback about it:

https://github.com/tc39/proposal-class-fields/issues

There's at least three specifically about the #:

https://github.com/tc39/proposal-class-fields/issues/177

https://github.com/tc39/proposal-class-fields/issues/149

https://github.com/tc39/proposal-class-fields/issues/142

Remember to be constructive or just give a thumbs up to comments you like.

View on HN

There were hundreds of comments against this, both constructive and otherwise, alas the committee knows better and will do whatever they want.

I think the water is somewhat muddied by the fact that the committee actually _does_ know better than the vast majority of people in opposition, as evidenced by the many uninformed comments in this thread suggesting alternatives that are objectively untenable.

This is not to say that there aren't other viable solutions which would avoid the use of the current proposed syntax, but how do you weigh the advantages of avoiding a subjectively "ugly" syntax against the many other, much more concrete concerns that the TC39 has to evaluate when choosing a proposal? Should "the reflexive reaction of many devs when they first see the feature (without taking any time to try it out) is that the syntax is ugly" just be an automatic veto? If not, how strongly should that concern be weighted? Should an otherwise inferior proposal be accepted instead merely because the syntax is slightly prettier?

Ultimately, I think you need to have a person or group of people in authority who will look at all available options and make an informed decision, even over the objections of the uninformed majority. Right now, the TC39 _is_ that informed authority.

The solution that TC39 voted is based on requirements that can only be satisfied by having the ugly `#`.

Namely they voted for encapsulation / hard-private [#33] as well as comparing private properties of two classes [2], which as a result makes the only possible syntax the one with the `#`.

Unfortunately this comes at the price that once browsers implement this it will become history ( same as the `with` statements [3] and `labels` with `continue` [4] ). Because of backwards compatibility these will never be removed.

Maybe in 2022 TC39 will decide that "use static-type;" will be a mode, such as strict mode, where you can write statically typed JS ( great idea, btw ), where this proposal will make no sense. Another "use class-inheritance;" mode would also finally end the abuse of prototype inheritance with syntax sugar. In this future the `#` will be just a huge annoyance.

#33 : https://github.com/tc39/proposal-private-fields/issues/33

2 : https://github.com/tc39/proposal-class-fields/blob/master/PR...

3 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

4 : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I can sort-of understand the desire for the values to be hard-private, but I think even that would be achievable without new syntax[1]. However, they also want the existence and names of the properties to be hard-private, which seems excessive. (And linguistically inconsistent with the choice of non-hard-privacy for symbols.)

[1]: https://github.com/tc39/proposal-class-fields/issues/177#iss...

May be by actively making Javascript Shorter and uglier, to steer people away from it, and making JS a compiling target only?

I mean whenever I see # I thought I am either on tweeter or the code was commented out.

For those of us who don't follow closely, how diverse is the membership of TC39? Are Mozilla, Safari, Edge, or other facets of the community well-represented, or is it just a front for the Chrome team?

Different subcommittees have different representation, but it’s generally diverse at least amongst the browser vendors. Often non-vendor web companies like Facebook take part in discussion too, and the current spec editor is Kevin Smith, who works at Microsoft. I believe a major proponent of this specific proposal was Daniel Ehrenburg, who used to work for V8 but now works at a different company that contracts for all of the JS engines.

TC39 has representatives of all major browser makers and various other companies doing web stuff.

Any company on this list[1] can send a delegate to a TC39 meeting, and at most meetings there are generally around 45ish people, from lots and lots of different companies and perspectives.

A particularly important member to point out is the JS Foundation, which sends devs of babel, lodash, etc to TC39 meetings as well.

1: http://www.ecma-international.org/memento/members.htm

It feels like in this instance the reflexive reaction of the developers is what made the passing of the proposal more likely by putting the committee in a psychological position where they're dismissing large amounts of feedback, making them more likely to throw out the proverbial baby. Had there been no discussion about the syntax, maybe the comments saying "we don't need this feature" would have been listened to.

It also didn't help that library authors are over-represented in the committee relative to the regular users of the language.

Ultimately, I agree that we need to have an authority to make the final decision and it helps if it's informed, but we need to be aware that it's not going to be perfect and it will have blind spots, so perhaps a way for people to veto those decisions should exist.

> It feels like in this instance the reflexive reaction of the developers is what made the passing of the proposal more likely by putting the committee in a psychological position where they're dismissing large amounts of feedback, making them more likely to throw out the proverbial baby.

Thank you for putting that into words. That's what I was initially trying to express when I talked about "mudding the water", but the second paragraph sorta took my train of thought in a different direction.

I can't help but think that if there weren't so much discussion about the syntax, and consequently so many people willing to throw their support behind any alternative proposals merely because they avoid that particular syntax, some of the more substantial concerns about this proposal might have gotten a bit more consideration due to the higher signal-to-noise ratio.

There is even an issue [1] that counts the votes for stopping this proposal.

IMHO "No solution" would be better than "bad solution" in this case.

1 : https://github.com/tc39/proposal-class-fields/issues/100

If you don't want the solution to exist, why do you care what it ends up being? You won't use it. You have no horse in the race.

Reading / maintaining / working with other people's code?

@gaardani that clearly will work, as evidenced here https://github.com/tc39/proposal-class-fields/issues/100#iss...

Reply on news.ycombinator.com