> Just so I get your argument straight, you're saying that launching a proprietary competitor to the standard means you're helping the standard?
No, I'm saying that launching a nonstandard solution to a problem without a standard solution or where there are discontents with the standard that are not being addressed is the usual way new standards are motivated, whether the new standard is based on the nonstandard solution or developed in reaction to it.
Standards (and even moreso, standards that are actually implemented rather than being mere paper triumphs) somewhat backward-looking rather than out-of-the-blue.
A commitment to standards isn't about not implementing nonstandard things, it's about engaging in the standards process to help get to a robust standard and then implementing it (replacing nonstandard solutions, if any) when it is clear what the consensus standard will be.
(And I use "nonstandard" rather than "proprietary" because standard/nonstandard is a different axis than open/proprietary.)
> Because then we owe Microsoft and Apple a shitload of thanks.
Well, yes, a lot of current web standards were originally either nonstandard solutions from Microsoft or Apple or alternatives developed in response and motivated by such nonstandard solutions, so, sure, they've driven a lot of the progress. I think they've generally been less good about (at last, slower) participating in standardization of an alternative when their original solution isn't acceptable to other players, but they have definitely been change drivers.
Actually a commitment to Web standards does mean a commitment to not launching nonstandard extensions to the Web platform, usually. Many of Chrome's own Web standards people would tell you this. For PNaCl and some other features Google's official excuse was to designate them "not part of the Web platform" ... which doesn't really make sense from anyone's point of view other than Google's.
In this case, the desirability and feasibility of running C/C++ code on the Web was not something that needed to be demonstrated by enabling PNaCl for Web content. In fact, uptake of Web-PNaCl has been extremely low --- fortunately. If significant Web-PNaCl uptake had been a prerequisite for WebAssembly, then WebAssembly probably wouldn't have happened!
No, I'm saying that launching a nonstandard solution to a problem without a standard solution or where there are discontents with the standard that are not being addressed is the usual way new standards are motivated, whether the new standard is based on the nonstandard solution or developed in reaction to it.
Standards (and even moreso, standards that are actually implemented rather than being mere paper triumphs) somewhat backward-looking rather than out-of-the-blue.
A commitment to standards isn't about not implementing nonstandard things, it's about engaging in the standards process to help get to a robust standard and then implementing it (replacing nonstandard solutions, if any) when it is clear what the consensus standard will be.
(And I use "nonstandard" rather than "proprietary" because standard/nonstandard is a different axis than open/proprietary.)
> Because then we owe Microsoft and Apple a shitload of thanks.
Well, yes, a lot of current web standards were originally either nonstandard solutions from Microsoft or Apple or alternatives developed in response and motivated by such nonstandard solutions, so, sure, they've driven a lot of the progress. I think they've generally been less good about (at last, slower) participating in standardization of an alternative when their original solution isn't acceptable to other players, but they have definitely been change drivers.