4 ms·
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 do
by fl3tch 15y ago
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.
- TomOfTTB 15y agoI 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.
- AshleysBrain 15y agoActually, WebGL is held up by all browsers except one.
- ootachi 15y agoFirefox and Chrome both support it, no?
- hnal943 15y agoThat'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.
- baddox 15y agoThat'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.
- notatoad 15y agowebapps 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.
- tomjen3 15y agoThat 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).
- throwaway32 15y agoI 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.
- dangoor 15y agoFWIW, someone is working on an implementation for Firefox. There was just a blog post on HN the other day about it.
- nl 15y agoI 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 http://www.chromium.org/spdy [2] http://en.wikipedia.org/wiki/WebSocket http://en.wikipedia.org/wiki/WebSocket [3] http://code.google.com/p/mod-spdy/ http://code.google.com/p/mod-spdy/
- deleted 15y ago[deleted]