Hacker News Reader

Comment by wodencafe | Hacker News Reader

It sounds like some Google employees on TC-39 had significant resistance to the idea, and it is worrisome that employees of a private company can block proposals in favor of "their" way, in what is supposed to be an open and transparent Technical Committee, for a language that is supposed to be for all of us.

Google trying to strong-arm control of JS for themselves.

View on HN

From the Github comments:

"One of the important priorities in TC39 is to achieve consensus - which means that any employee of any member company can always block any proposal. It's far far better for anyone to be able to block, than to arrive at a spec that "not everyone" is willing to implement - this is, by a large large margin, the lesser evil, I assure you."

This is why you don't do development by standards committees. It never ends well.

You miss the point that TC39 uses a champions model: 1 or 2 people who do design, with the committee reviewing.

That broke down here, to the extent that the champion, Domenic, withdrew under some kind of internal (to Google if not his own state of mind) duress. TC39 never had a chance to consider the argument or whatever it was that caused this.

More to say after January's meeting, I'm sure. I'm not going to throw stones at Google but it would not surprise me if there were backroom objections. If so, they should be brought to the committee cleanly. There is still time.

This is a great summary of the situation Brendan, thanks for the clarification about TC-39 committee not actually getting to review the proposal.

The main issue regarding the proposal and its sudden withdrawal seems to be an all-around lack of transparency.

Do the champions provide an implementation of the proposal for the committee to review?

See https://tc39.github.io/process-document/. To get real engine implementations may take cooperation among champion and one or two browser vendors, as the "real engines" (meaning ones that can be tested against the Web at scale) are all owned by browser vendors.

Examples:

* SIMD started from Dart's proposal, which John McCutchan then championed at first for JS, and later handed off to others. Intel, Mozilla, and Google all cooperated.

* ES6 Proxies, where Mark Miller and Tom Van Cutsem were the champions and did a terrific job covering the design space and finding the sweet spots. Andreas Gal implemented in SpiderMonkey and then the spec changed, based on the implementation (but in a mostly co-expressive way, for wins beyond expressiveness; the new proxy implementation layered on the internals of the old). Proxies were quite challenging as they exposed observable internal order of operation details and required reformulating spec-mandated invariants that matter for not only interoperation but also security.

They could, but I'd expect that they generally do not.

What's the alternative, sell your software in a box at Best Buy?

I guess for language like Javascript there is no real alternative. If you want to push the language further without creating multiple dialects, you simply must have consensus among the major parties writing implementations. These parties most certainly would not give the language to hands of (benevolent) dictator and agree to implement what ever he comes up with.

If you're delivering software in 2016 in any language you're probably dealing with standards at some level. Are you using HTTP? Using a standard with a committee. Using TCP? There's an RFC for that too.

Standards committees work best when standardizing something that already exists. That's why the IETF has a policy that any standards track technology has to have two interoperable implementations (although that policy isn't always followed all that closely in recent years).

Is there any implementation of this, or any, proposal? Or do the proponents bring a paper spec to the committee to discuss theoretically, evaluate, compromise, and accept; only then implemented with no particular guarantee that it can be done usefully?

No, implement a proposal, demonstrate that it is worthwhile, and then standardize it.

Anything by committee, really.

I also read that as Google will refuse to implement features if it doesn't get it's way in how they are designed.

Perhaps the people providing the Environment shouldn't be the people designing the language?

Google is very quickly turning into 1990's Microsoft.

> I also read that as Google will refuse to implement features if it doesn't get it's way in how they are designed.

There's no reason for Google to do this, in general, since there are enough Googlers in enough standards groups (all of which operate by consensus) that they can simply object to changes they don't like (like other members of the committee).

> Google trying to strong-arm control of JS for themselves.

The person championing the proposal was from Google too; this narrative doesn't make sense. Let's not conjure up conspiracy theories if "programmers disagreeing about something" adequately explains the data.

To be completely honest, they are the maintainers of one of the largest Javascript implementations.

It really only makes sense for them to have significant input on the features that make it into the language.

Mozilla, Microsoft, and Apple could have done the same thing, as they all write the software, and that only seems fair. If there is a significant reason why something won't work in one or more of the major engines, it might need to be rethought.

I'm not sure why everyone is jumping on this like it's some kind of nefarious thing. What would google have to gain from killing this proposal?

When the people designing the language are the same people providing the implementation, it leads to vendor lock in.

Remember Microsoft in the 1990's, remember the massive Antitrust case about IE?

The antitrust case about IE was related to Microsoft using their position in the operating system market to give them an unfair advantage in the browser market. It had nothing to do with the embrace-extend-extinguish which they attempted on JavaScript.

They couldn't feasibly attempt EEE on JS without Internet Explorer's dominant market share.

Plus the advantage they wanted in the browser market (to strangle Netscape dead, in their own words) was purposefully to artificially maintain their monopoly in the OS market.

I like to complain about big companies too, but Google isn't trying to strong arm control of JS. They hire a lot of smart programmers with strong opinions who express them and it seems like a lot of those were vocal enough to make this happen. Just how it is.

And did so behind the scenes within Google rather than in public?

Right, this exactly.

Also, why is every response with a hint of negativity towards google getting down voted?

If Google was doing the right thing, they wouldn't have to be shielded from online criticism.

Because clearly right now isn't when the transparency is going to come. It might come soon. If we don't hear anything then yes that's a problem, but clearly even the person who wanted this proposal doesn't want to talk.

This does not appear to be avoiding transparency, but just some people had a VERY heated discussion about this and are burnt out.

Mine you, I'm a big user of Go for personal projects and so I've seen Google make it's unilateral decisions before. I just don't think this is one of those situations.

I half-agree. If this issue was discussed in public rather than in private, perhaps the details could have been worked out without the whole proposal being withdrawn.

But because of the Github thread and HN thread, this proposal is finally getting a fair shake by the public dev community. So, that's good at least :)

> this proposal is finally getting a fair shake by the public dev community

This says a lot about the pain of getting anything standardized, honestly. The proposal has been in the works for two years, essentially in its current state for over 6 months, and it wasn't given what you consider a "fair shake" until there was some (imagined or not) soap opera drama.

Didn't some high-ranking Googler basically adopt "if you have nothing to fear, you have nothing to hide" a while ago? Wonder what they're afraid of.

It's only a coincidence that the most vocal opponents to this proposal each receive a paycheck from Google?

I'm starting to wonder why these TC's have so many Google employees, and you can claim it's because "they hire a lot of smart programmers", but the ratio of Googlers to not is way too high to represent the web development community as a whole - the majority of whom do NOT work for Google.

Google is honestly not alone in this, tail call elimination is being blocked by safari, websql was blocked by Mozilla.

In both of those cases you mention I'm in agreement with them, but there was a bit of "shock and anger" when I first heard about them.

And I'm treating this the same way. I'm gonna reserve judgement until after Google have spoken about their reasoning.

This is emphatically NOT true about tail calls and Safari -- the JSC has already implemented proper tail calls, and they were the first to do so.

Safari was against an explicit tail call syntax [0], and as part of that were against "TCO" as an optional optimization, however they are the first to implement PTC.

[0] https://github.com/tc39/ecma262/issues/535

To be fair, Google could easily kill the feature by refusing to implement it in Chrome, TC39 or not.

Yeah it's getting pretty worrying, they're just trying to turn the web into their platform in every way.

Reply on news.ycombinator.com