Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Less important IMHO than Chrome vs. Firefox vs. IE is the fact that we now find ourselves in a world where there are three serious competitors for browser mindshare instead of one dominant one. That makes collaboration on standards a winning strategy instead of a losing one: any two browsers can agree on something and push it with majority support, pulling the third along. When it was IE vs. the world, the existence of a standard (a sane standard, anyway) that could be implemented by its competitors was a losing stratagy for MS.

Bravo!



Or it could mean that each browser effectively has veto power over any innovation. If developers know that 25% of their visitors will be using a browser that doesn't support a particular standard or technology, that may prevent them from implementing it... at least "for now". That will prevent widespread adoption, thus justifying the outlier browser to never support it.


That depends on the feature in question.

Some features, like SPDY, can be implemented even though not all the browsers support it -- which means that those that don't will find that their users think their browser is slow.

Some features can be emulated with things like long-polling.

And some (WebGL) can't.

I doubt you will be right about those features that can be replaced or emulated but you are properly right about those that can't.

Then again every day we choose to exclude some customers (you only speak Japanese? Well sorry then).


I doubt many sites are going to bother with all the complexity of implementing and utilizing SPDY when only chrome supports it. To see significant advantage with SPDY vs something like long-polling you need to build your app around it, and if you need to support long-polling methods anyways, not very many sites are going to bother.


I think you are confusing SPDY[1] with WebSockets[2]. SPDY is Google's experimental replacement for HTTP. You don't build your app around it at all - from the application layer it should be mostly invisible.

SPDY can be implemented as an Apache module[3] which could be used only when the browser supports it.

It is true that WebSockets replace long polling, but there are plenty of libraries that abstract the differences out nicely.

[1] http://www.chromium.org/spdy [2] http://en.wikipedia.org/wiki/WebSocket [3] http://code.google.com/p/mod-spdy/


FWIW, someone is working on an implementation for Firefox. There was just a blog post on HN the other day about it.


That's possible, but any browser that refuses to implement a sufficiently great technology will also risk losing users to browsers who give them a better experience. It will be turbulent, but the consumers will win in the end.


That is only true if web authors use that feature. If they do not, there is no penalty for failing to support it.


If web authors don't use the feature, should it be in the standard at all?


webapps help a lot with this though. with websites, where pageviews are king, you can't afford to exclude any big browsers. when you are developing a webapp, especially something that your customers are going to use to generate revenue for themselves, you as a developer are in a much better position to exclude browsers that don't implement standards.

obviously it's not an ideal situation, but i have no qualms about using webGL to implement something labeled an "advanced feature" in my app, and give IE users an error saying their browser isn't supported.


That's why I wish my idealistic notions were practical in the real world. Ideally, web developers would design according to standards, which would force browsers to adhere to the standards or risk losing market share. Unfortunately, pragmatism has to win out, and developers have to utilize every hack and bad practice imaginable to get their content to be accessible on every browser.


I want to agree with ajross but thus far the pattern seems to support fl3tch. WebGL, SPDY, and WebM are all technologies being held up by one browser.


Actually, WebGL is held up by all browsers except one.


Firefox and Chrome both support it, no?



Firefox, Chrome, Safari, and soon Opera.


Yep, great times for the web! They've all been trying to one up each other with performance too - good times for web developers.


> Less important IMHO than Chrome vs. Firefox vs. IE is the fact that we now find ourselves in a world where there are three serious competitors for browser mindshare instead of one dominant one. [..] Bravo!

I like the sentiment and agree with most of it. But we are definitely not in a good place quite yet.

It looks like Chrome will overtake Firefox this year on desktop. It will likely also overtake IE on desktop, simply because the number of people forced to use IE - in big corporations - is small compared to the number of normal users. So IE will continue to go down quite a lot more.

So Chrome will be the #1 browser on desktop. But that's just one side of things. Chrome will also be the #1 mobile browser because it will be bundled on Android, the #1 mobile OS. Combine desktop and mobile, and Chrome will get a dominating majority. (ChromeBooks might also take off, making the control even more complete - but it's hard to say if they will.)

Chrome's rise is the result of a great product and a truly massive marketing campaign. But it looks like it will succeed far too much, potentially replacing the currently open and competitive space with one dominated once again by a single player. And just like the previous dominator, this one has other products it can and will leverage with the browser (as we saw indications of in the leaked Dart memo, and as we currently see with Chrome-only features of gmail and google docs).

Yes, Chrome is mostly open source, so that by itself makes it less evil than the previous browser monopoly. But even an open source project that is controlled by one company, and used to further its own ends - which legally it must as a for-profit - can be a very bad thing. We can't blindly assume that what is good for Google will always be good for everyone else - if that ever was the case.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: