Everyday a little bit closer, Google the new Microsoft. Not surprising.
As I got to this point in the lecture, I paused, and realized for the first time that Google is often playing a similar game with Chrome.
Everyone agrees that standards are time-consuming, bureaucratic, and prone to all sorts of compromises. But the goal of standards isn't the speed of the process, but rather the inclusiveness of the process. (And yes, you can make a case for the W3C not being so inclusive...)
It's great that Google is interested in treating Chrome as a laboratory for new Web technologies, but I think that some added humility would be in order. It's one thing to say, "We think that this might work well, and are throwing it out there to see what will stick, keeping the good stuff and throwing out the bad." But instead, they seem to be saying, "We think that this is good enough for a standard, never mind the process." And that can't be good for the Web.
The problem in the browser wars was that they were trying to be incompatible, which is not really the case with Google. (Remember, Microsoft's model was not "Embrace, extend, evangelize.")
This is sometimes the case for Google's technologies as well. PNaCl is pretty much impossible to embed into other browser engines because of the dependency on Pepper, which is very Chromium-specific and there has been no attempt at all that I'm aware of to standardize it. (Pepper even has undocumented stuff that Flash uses!)
It's not like Mozilla doesn't do things for expediency when they need ability to iterate quickly, e.g. The WebAPIs effectively ignoring the existence of similar DAP efforts, and then having to turn around and rationalize them with the previous work. If you need to ship a physical phone with Firefox OS, and the manufacturers are waiting, are you going to block on W3C, or ship with proprietary or un-ratified device APIs?
There was a thread on plugin-futures about Pepper way back in 2010, when this effort was getting underway. Every other browser manufacturer suggested using the Web APIs instead of Pepper. Google ignored the consensus and did Pepper anyway. Looking back, from everything I saw the other browser manufacturers were right—asm.js now has an advantage in that it can use the standardized Web APIs. If Google had listened to the other browser manufacturers, it might have turned out better for PNaCl.
I don't know what the reasoning then was, but it seems to me that if you goal is to get games to port C code, it's a lot less re-engineering if you have threads and blocking ops. I've ported multithreaded apps to the web and de-threading them is a major headache.
Again though, if there were no pepper, do you really think Mozilla would have adopted NaCL?
On a side note, Firefox 27 finally killed the last vestige of NPAPI exports that we needed to make GWT Dev Mode work (side side note: Chrome killed us first deprecating NPAPI). Here's a case where WebAPI equivalents don't work. Not even PPAPI can work. GWT Dev Mode very specifically relied on synchronous access to JS APIs. Point is, shoe-horning everything in the browser event loop is not the ideal location or design for every API. Sometimes you do need something outside the WebIDL bindings.
If PPAPI were not as tied to Chrome's internals as it is, we might in fact have implemented it.
As far as being invested in JS, I think it's more being invested in managed code. Our experience with NPAPI is that you end up with the unmanaged code depending on all sorts of implementation details because it can. The classic example is that all NPAPI Flash instances across have to be in a single process, because they assume they share memory. And the browser can't do anything about it, since it's not involved in the memory sharing bits in any way. Similarly, the fact that NPAPI plug-ins can do their own network access makes them hard to align with CSP and the like. Managed code can start to depend on internals in weird ways too (e.g. sync access to cross-origin window bits), but you have more chances to pull the wool over its eyes in some way (e.g. blocking cross-process proxies).
Once you accept managed code, JS seems like as good a place to start as any, with at least the benefit of being there to start with. ;)
There are, of course, obvious drawbacks to the all-JS approach, starting with the fairly lacking parallelism story. At least now we've grown Workers, and there's work on things like SIMD, ParallelJS, etc. Then again, the one major language addition to a browser VM recently (Dart) didn't exactly address this need either....
I'm not going to be calling you names, but if you've been looking this has been obvious for at least a year now.
Chrome was released to enable all the bad stuff Google is doing now.
The original problem with Microsoft's behavior was that Microsoft simply ignored standards that did exist and replaced them with subtly different standards of their own, so that they broke standards-compliant pages. They also pushed for proprietary technologies that they wouldn't allow others to use, like ActiveX and VBScript, but their breaking standards was worse.
The second problem was that once Microsoft had achieved dominance, it stopped adding anything at all to IE. This made the Web platform largely stagnant for years.
At no point was the problem "Microsoft came up with this cool new idea and implemented it before the standards bodies had the requisite seven years to agree on it." That's what Firefox and Safari were doing, and most people agreed that it was pretty good. These ideas Firefox and Safari came up with became HTML5. In fact, so did one idea Microsoft had that didn't break existing standards — XMLHttpRequest.
Now, as everyone is always "citation needed" on this, as maintaining this myth is a much stronger goal for most people than doing even minimal backing research, here are some places I've talked about this before in more detail, the second link containing a very large number of citations if you go through to the bottom of the thread.
https://news.ycombinator.com/item?id=5216141
https://news.ycombinator.com/item?id=5716787
Your comment about VBScript is silly, given that JavaScript was also non-standard Netscape-specific Java-laden ludicrousness that also "broke the web" (script elements were implemented in a way that required special hacks to an HTML parser to even parse due to nested < having a different meaning, and done without any requirement for backwards-compatibility to ones that would see the content as part of the document). It was only due to Microsoft's JScript (ehich went hand-in-hand with VBScript and ActiveX in the same way JavaScript worked with Java as "LiveScript" in Netscape) that ECMAScript got standardized at all.
Seriously: I simply don't understand why everyone perpetuates this madness when you can't substantiate any of it if you look at the actual history... every comment bashing IE always repeats this stuff, so everyone thinks of it as gospel truth, but it really is all just myth at this point: "citation needed".
My point is not "Netscape rules, Microsoft drools." My point is that implementing new ideas that haven't been fully standardized — as both Microsoft and Netscape did — was never really the big problem. The problem with IE that made people come to hate it was that Microsoft broke the standards, left them broken for years and years and refused to implement anything new. Netscape was corpsified by the time this really came to a head, so I don't know what they have to do with anything. The alternatives I brought up were the later browsers like Firefox and Safari that got tired of waiting and started implementing new things and slowly eroding IE's marketshare.
Microsoft didn't replace some standard with a subtly different standard when they did ActiveX and VBScript... what was the standard you claim existed that they were ring subtly different from? JavaScript? Java? (Again: not a standard.)
You claim Microsoft ignored standards, but Microsoft actually cared a lot about being on top of standards and were involved in the standards process; if anything their fault was shipping stuff too early (which would be something you could pick on, but didn't; it would even be a powerful and apropros argument, as that's what Google is doing today): they cared about CSS when no one else did, and later they cared about XSL/T when no one else did.
You also claim that Microsoft stopped working on IE6 when they obtained dominance: I directly touch on that in my expanded comments, pointing out that it makes more sense that Microsoft stopped working on IE when they ran into legal opposition and the project became demoralizing and dangerous. Microsoft does not have a history of simply not releasing updates to products they have dominated: their updates are at times problematic to others and sometimes even self-defeating, but something really weird happened with IE6--where there was only a single service pack release during a nearly five year hiatus from any form of update--that simply isn't well-explained by their dominance.
The only situation I can come up with similar to your arguments is DHTML Behaviors, which is amazingly similar in goal to that of this new Web Components stuff ;P. I will claim this is exactly the kind of thing chadwickthebold is talking about when he said "MS pushed for adoption of proto-standards before there was any sort of agreement on how they should actually be interpreted/implemented". Here is the proto-spec:
http://www.w3.org/TR/1999/WD-becss-19990804
Microsoft submitted DHTML Behaviors to the W3C in 1998, spent a bunch of time with them talking about how it would work, and in the end shipped it in 1999 as part of IE5. Maybe the timeline is tighter than Web Components today with Google, but it seems like the same story. (Note that I haven't researched this to the same extent as my earlier comments, but I am definitly basing this off of historical sources; if you disagree with this comparison, I would be interested in hearing some similarly-historically-based arguments for how the timeline played out and why I this fundamentally different than Google today.)
Finally, now in this comment you talk about "broke the standards": I would appreciate some citations and examples; the primary things I know that people like to argue about are issues with CSS and XSL/T that are entirely explained by "pushing proto-standard"... the IE box model being the prototypical example.
So, each one of your comments are incorrect. It thereby doesn't matter what your conclusion is; in my earlier comments I'm arguing against people comparing Microsoft to Netscape, but in this thread I am just pointing out your statements about Microsoft are unsubstantiated. It doesn't matter what your opinion of Netscape is, and if you reread the comment I made on this thread, my response to you, you will see that I don't bring that idea up at all... you decided to transplant the conclusion from my citations to here, I am guessing because that is easier than addressing any of my actual complaints about your facts one-by-one? Again: none of these facts you are stating fit the history, and if you are going to keep repeating them I'd like some primary source material for them (mailing list posts or comments by developers from back when Microsoft was actually dominant or before the did, not after they lost and abandoned the web entirely).
I agree. I called out ActiveX and VBScript as not being examples of this because I thought somebody might bring them up if I didn't. I don't think those really contributed much to IE's poor reputation on standards. You list some of the examples I was thinking of later on.
> You also claim that Microsoft stopped working on IE6 when they obtained dominance: I directly touch on that in my expanded comments, pointing out that it makes more sense that Microsoft stopped working on IE when they ran into legal opposition and the project became demoralizing and dangerous. Microsoft does not have a history of simply not releasing updates to products they have dominated: their updates are at times problematic to others and sometimes even self-defeating, but something really weird happened with IE6--where there was only a single service pack release during a nearly five year hiatus from any form of update--that simply isn't well-explained by their dominance.
I'm not sure if you think I claimed otherwise, but I didn't. The reason for Microsoft's stagnation wasn't relevant to my point, so I didn't address it. Remember: The purpose of my comment was not to slag Microsoft. The purpose of my comment was just to illustrate that making progress was not what got Microsoft its bad reputation for web standards.
Why Microsoft did things is interesting (and I think you're probably right), but it's beside the point when we're just asking "What did Microsoft do?"
> Finally, now in this comment you talk about "broke the standards": I would appreciate some citations and examples; the primary things I know that people like to argue about are issues with CSS and XSL/T that are entirely explained by "pushing proto-standard"... the IE box model being the prototypical example.
CSS was still newly finalized when IE released support, but I don't believe there was ever a draft specifying the behavior IE used. Here's a draft from a year before IE 3 that specifies the standard box model: http://www.w3.org/TR/WD-css1-951117.html#horiz
I can't find any evidence that Microsoft had reason to believe the behavior they implemented was what would be in CSS. As far as I can determine, they simply diverged from the spec. Maybe they misread the spec, maybe they liked their model better and chose to ignore the CSS standard they had available to them — and I mean, hey, I liked their version better too — but the fact is that they just created a competing standard and were reluctant to adopt the real standard, and this caused people to feel that Microsoft had poor support for standards.
I always thought that was because the DOJ went after them. And MS said, roughly, "You don't like IE? You think it's 'bad' for everyone? Well, fine then. We won't touch it. See how you like that."
Point being, I think we were stuck with a shitty IE for so long primarily in retaliation for the Justice dept.'s anti-trust suit.
But that's entirely conjecture...