Hacker News Reader

Comment by rplnt | Hacker News Reader

This is really bad news for Opera. Although they probably won't leave their 1st position in mobile browser market anytime soon, they will feel it. Even more so if Google will throw billions on advertising as it did with desktop version and people with older androids will switch too.

And this will deepen the new IE5+ era which came with* Chrome. Remember those sites which blocked you when you had other browser than IE? Now try to use some non-mainstream browser for a while and you will notice them again. Some might be subtle, just silently blocking features/redirecting you to other versions of sites. But it is the same nevertheless. (And no, I'm not talking about about various tech demos which really only work in Chrome.)

*edit: brought by -> came with

View on HN

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

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

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.

>new IE5+ era

Only that Chromium and G Chrome are W3C compliant and don't try to force their own DOM rules onto everybody, like MS did until recently.

That is true, but Chrome is not the problem (it's merely a cause). Problem are web developers blocking their sites. Funny enough, Google being in the lead.

-webkit prefixes have basically the same effect. Apple has been constantly encouraging the use of -webkit prefixes ever since the iPhone came out. Notice all the discussion lately about other browsers having to adopt -webkit prefixes. This is necessary to compete on mobile, because of the mobile web essentially being the domain of one rendering engine.

This is, again, problem which is very common. Developers add -webkit- and forget about others like -ms-, -moz-, -o-, -kthml-, ... and most importantly the unprefixed original (if it is a prefix that is a part of some pending standard). I would love if people didn't use these prefixes at all but with W3C being so freakishly slow it would really hold the web back.

The prefixes like -moz-, -webkit-, and -o- are specifically for NOT contaminating the DOM with objects that are not standard compliant. These prefixes mark proposed features that are still in discussion for W3C standardization and they are introduced so they can be tested in practice. Once they are standardized, the prefixes can be dropped. That is exactly how it should be.

The -moz- prefix was first, and -webkit- came later.

Are you implying Chrome will be the new IE on Android? It won't be if they keep it separated from the OS, like they do with all their other apps.

> and people with older androids will switch too

If they keep Chrome Mobile's size 17MB there's no way people with 'older' phones will able to switch.

Reply on news.ycombinator.com