5 ms·

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 proposal

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.

0xCMP 10y ago
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.
- wodencafe 10y ago
  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.
- mcguire 10y ago
  And did so behind the scenes within Google rather than in public?
  - wodencafe 10y ago
    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.
    - 0xCMP 10y ago
      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.
      - wodencafe 10y ago
        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 :)
        magicalist 10y ago
        > 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.
      - ubernostrum 10y ago
        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.
jpalomaki 10y ago
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."
- wodencafe 10y ago
  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.
  - wycats 10y ago
    > 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).
- mcguire 10y ago
  This is why you don't do development by standards committees. It never ends well.
  - Touche 10y ago
    What's the alternative, sell your software in a box at Best Buy?
    - jpalomaki 10y ago
      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.
Klathmon 10y ago
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?
- wodencafe 10y ago
  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?
  - uiri 10y ago
    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.
    - snerbles 10y ago
      They couldn't feasibly attempt EEE on JS without Internet Explorer's dominant market share.
    - euyyn 10y ago
      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.
  - deleted 10y ago
    [deleted]
65827 10y ago
Yeah it's getting pretty worrying, they're just trying to turn the web into their platform in every way.
Gaelan 10y ago
To be fair, Google could easily kill the feature by refusing to implement it in Chrome, TC39 or not.
fenomas 10y ago
> 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.
cwmma 10y ago
Google is honestly not alone in this, tail call elimination is being blocked by safari, websql was blocked by Mozilla.
- Klathmon 10y ago
  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.
- samth 10y ago
  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.
  - Klathmon 10y ago
    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 https://github.com/tc39/ecma262/issues/535

0xCMP 10y ago

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.

wodencafe 10y ago
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.
mcguire 10y ago
And did so behind the scenes within Google rather than in public?
- wodencafe 10y ago
  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.
  - 0xCMP 10y ago
    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.
    - wodencafe 10y ago
      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 :)
      - magicalist 10y ago
        > 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.
    - ubernostrum 10y ago
      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.

jpalomaki 10y ago

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."

wodencafe 10y ago
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.
- wycats 10y ago
  > 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).
mcguire 10y ago
This is why you don't do development by standards committees. It never ends well.
- Touche 10y ago
  What's the alternative, sell your software in a box at Best Buy?
  - jpalomaki 10y ago
    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.

Klathmon 10y ago

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?

wodencafe 10y ago
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?
- uiri 10y ago
  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.
  - snerbles 10y ago
    They couldn't feasibly attempt EEE on JS without Internet Explorer's dominant market share.
  - euyyn 10y ago
    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.
- deleted 10y ago
  [deleted]

65827 10y ago

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

Gaelan 10y ago

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

fenomas 10y ago

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

cwmma 10y ago

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

Klathmon 10y ago
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.
samth 10y ago
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.
- Klathmon 10y ago
  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 https://github.com/tc39/ecma262/issues/535