Hacker News Reader

Comment by chime | Hacker News Reader

> And this will deepen the new IE5+ era which was brought by Chrome. Remember those sites which blocked you when you had other browser than IE? Now try not to use Chrome for a while and you will notice them again.

The big difference is that Chromium is open-source while IE was not. Also Chrome devs work with Mozilla and others to create new features, unlike IE vs Netscape at the time.

View on HN

Recently Google has shown little interest in working with others; witness Dart (which essentially nobody but Google wants) and NaCl (which no other browser manufacturer wants).

There's also SPDY and WebM, which certainly both have shown to be desirable outside of Google.

You write software, right?

Sometimes the user doesn't know they want something until they see it in front of them.

So should Google be working with other browser manufacturers or not? It seems like there's a double standard here.

The option for other vendors to implement those features has not been removed from the table. Unlike something like ActiveX, these companies have a choice to implement, even if they dont want to.

Firefox could have implemented ActiveX, of course. The spec wasn't a secret.

Sorry but I don't see that as them not showing interest in working with others at all. There is a NaCL plugin for firefox written by Google, in both case the specs a open and the code in WebKit is open source. They can't force others into using their stuff. They've been proactive in taking in Firefox's new tech like WebGL and they killed their own effort (O3D) in the process(I depended on O3D for one of my work projects but they did make the transition pretty painless by rewritting O3D's api on top of WebGL). There are many more examples.

First of all, NaCl is now Pepper-only, so it is no longer compatible with Firefox. Firefox uses the NPAPI, not the Pepper API. Pepper is itself an instance of Google not showing interest in working with the other browser manufacturers. The other browser manufacturers considered it unnecessary to add two incompatible plugin APIs when the NPAPI already exists and could just be extended.

Second, the position of every other browser manufacturer is that NaCl is undesirable because (a) it's not compatible with JavaScript, so it requires another language runtime and (b) that it locks the Web into x86 and ARM. As bzbarsky of Mozilla posted here [1], if Google had made and pushed NaCl a decade ago, the iPhone would be unable to browse the web. Google ignored the other browser manufacturers' concerns and are now pushing NaCl to gain a competitive advantage.

[1]: http://news.ycombinator.com/item?id=3391747

I appreciate your reply. As far as the Pepper API my understanding is that it was an extension to NPAPI to improve it, not an attempt at creating an incompatible API. I can't find any source on why Mozilla decided to not use it. From the Pepper wikipedia page it looks like some of the goal of Pepper would be very useful to every browser.

  > The big difference is that Chromium is open-source
  > while IE was not.

While certainly laudable -- how does that matter in practice? The drama surrounding IE5 would have unfolded in a similar manner if Microsoft's browser had been open source. It's about control and pushing for non-standard features, not development strategies...

Your second point stands, of course.

  > It's about control and pushing for non-standard features,
  > not development strategies...

I guess the point he's trying to make is that if IE was open source, then MS would have much less control over pushing non-standard features. If chrome tries to pull the same tricks today, people will just build chromium without it and compete. So I agree with chime, that chromium being open source makes a big difference.

It's not really possible to compete with Chrome just by building the source. For one, Google has an exclusive OS deal that can't be replicated -- which is the main point of this article.

  > If chrome tries to pull the same tricks today, people
  > will just build chromium without it and compete.

I doubt that. As ootachi mentions, this isn't a purely technological race. Far from it. Chrome succeeds for multiple reasons, one of them of course being Chromium's engineering; however, without Google backing the browser heavily, it'd die.

You make developing and maintaining a viable Chromium-fork sound like a trivial thing, but it isn't. (Plus, this fully ignores community inertia -- shit would have to hit the fan before people "just build chromium without it." The community took Dart and NaCl in stride!) So in the end, open source doesn't give you much immediate protection from IE5-ification. Look at how long it took to make Mozilla/Firefox competitive.

Except that Mozilla was a completely separate code base from IE and had to do reverse-engineering, while WebKit is itself open source and can be forked directly. (WebKit itself in fact was a fork of KHTML)

There is at least some form of publication and consultation these days, though. When Google comes up with SPDY or NaCL, or Apple comes out with HTTP Live Streaming, they publish specs and sometimes submit them to standards, with the result that they're often adopted elsewhere; HTTP Live Streaming has been picked up by Chrome, Android and WebOS, for instance. As far as I remember, Microsoft tended to just make up new things and add them to IE, without a proper spec, and sometimes with no real documentation.

Opera has strong roots in W3C as well, does it help them not getting blocked? No. And I'm not blaming Chrome. I said it will only deepen the problem. Web developers are the ones to blame. With Chrome taking huge majority of the market they will have it easier to justify themselves.

uhm,no.. for example the tech behind ajax was created out of thin air??

Reply on news.ycombinator.com