Hacker News Reader

Comment by fl3tch | Hacker News Reader

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.

View on HN

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?

Both of those and Safari: http://www.windows7hacker.com/index.php/2010/02/how-to-enabl...

Firefox, Chrome, Safari, and soon Opera.

Reply on news.ycombinator.com