5 ms·

WebSockets in Firefox

49 points by nreece 17y ago

joshsharp 17y ago
Sensible response by Mozilla, but a shame that means we won't be seeing websockets included in the near future.
- Rauchg 17y ago
  I disagree. The argument is that it's under constant change and discussion. This is true for every single part of the development stack. It's important to just get it out there and iterate in response to what developers are _doing_ with WebSocket. The sample size to justify Content-Encoding: gzip, deflate in that mailing list post is two, and is very unlikely to grow if Firefox doesn't add support! We could discuss theoretical improvements to WebSocket for months on a mailing list. If you look at the initial discussions about the WebSocket protocol, much was said about reconnection negotiation, queues/batches support, meta headers, et cetera. Discussing a feature forever holds back progress. Firefox argues that there's "a lot of ongoing discussion", but that's been the case since Day 1. Firefox should do what Chrome 4 did, add it, then continue to improve it. There's a very low chance that the developer API will change anyway.
  - robryan 17y ago
    Having it in firefox and chrome would encourage a lot more development around it. As it stands I don't think people would want to invest to much past experimentation in taking advantage of a feature that is only present in chrome.
  - jamii 17y ago
    I like the chrome approach of including experimental features in stable builds but requiring a command line switch to turn them on. It makes it much easier to try out new features without making people expect future compatibility.
  - mbrubeck 17y ago
    "There's a very low chance that the developer API will change anyway." If you include server-side developers, then part of the developer API (the protocol) has already changed compared to Chrome's implementation.
agentultra 17y ago
Hopefully it becomes a widely adopted standard before we start inching backwards towards the good ol' days when sites were optimized to the browser. Web apps can be neat and useful, but do we really need a 250-300MB run-time for a thin client? Maybe I'm just getting old.
silviasaint29 17y ago
Thanks for all the awesome replies here http://bolcroatia.com/bol_croatia_apartments_brac_dalmatia.html http://bolcroatia.com/bol_croatia_apartments_brac_dalmatia.h...
Kilimanjaro 17y ago
Less talk, just ship it!
zokier 17y ago
This is one reason I'm not particularly fond of Mozilla. They care too much about ideology, PR and all that stuff. They have had the code but won't release it because it could make them look bad or annoy some web devs or doesn't fit their ideology. Why can't they just release stuff and see how it fares, and improve it based on public's response.
- mbrubeck 17y ago
  It's not just about ideology and PR... it's about keeping our users secure. And the "ideology" has a very pragmatic side: it's about keeping the web based on actual standards that can evolve rather than defacto standards that we will have to live with forever. We're dealing with this on the Mozilla Mobile team because of touch events. There is no standard for touch events in browsers. Mobile Safari and Android both implement touch events, and their implementations are partly compatible and partly incompatible. Mobile Firefox could choose to take one of those implementations and copy it. In the short term it would make us more compatible with some existing iPhone-optimized sites. But in the long run it would raise the barrier for getting web sites (and browser vendors) to switch to an actual standardized API. So we're going to try to get the WHATWG to agree on a standard for touch events before we implement them rather than after. The standards process is not just about ideology - it often catches significant design and security flaws, as it has with WebSockets. It's much harder to change an API once you've shipped it to a userbase like Mozilla's (hundreds of millions of people - around 30% of all internet users). Remember the story about Stuart Feldman when he was asked to make the Makefile syntax more sensible? He said he couldn't, because there were already over a dozen people using it.
- FooBarWidget 17y ago
  Not caring about ideology is what got us into the IE6 mess in the first place.
  - Shorel 17y ago
    I disagree. Not caring about ideology over technology is what got us Chrome. The Embrace, Extend, Extinguish destructive MS ideology is what got us into the IE6 mess.

49 points by nreece 17y ago

joshsharp 17y ago

Sensible response by Mozilla, but a shame that means we won't be seeing websockets included in the near future.

Rauchg 17y ago
I disagree. The argument is that it's under constant change and discussion. This is true for every single part of the development stack. It's important to just get it out there and iterate in response to what developers are _doing_ with WebSocket. The sample size to justify Content-Encoding: gzip, deflate in that mailing list post is two, and is very unlikely to grow if Firefox doesn't add support! We could discuss theoretical improvements to WebSocket for months on a mailing list. If you look at the initial discussions about the WebSocket protocol, much was said about reconnection negotiation, queues/batches support, meta headers, et cetera. Discussing a feature forever holds back progress. Firefox argues that there's "a lot of ongoing discussion", but that's been the case since Day 1. Firefox should do what Chrome 4 did, add it, then continue to improve it. There's a very low chance that the developer API will change anyway.
- robryan 17y ago
  Having it in firefox and chrome would encourage a lot more development around it. As it stands I don't think people would want to invest to much past experimentation in taking advantage of a feature that is only present in chrome.
- jamii 17y ago
  I like the chrome approach of including experimental features in stable builds but requiring a command line switch to turn them on. It makes it much easier to try out new features without making people expect future compatibility.
- mbrubeck 17y ago
  "There's a very low chance that the developer API will change anyway." If you include server-side developers, then part of the developer API (the protocol) has already changed compared to Chrome's implementation.

agentultra 17y ago

Hopefully it becomes a widely adopted standard before we start inching backwards towards the good ol' days when sites were optimized to the browser. Web apps can be neat and useful, but do we really need a 250-300MB run-time for a thin client? Maybe I'm just getting old.

silviasaint29 17y ago

Thanks for all the awesome replies here http://bolcroatia.com/bol_croatia_apartments_brac_dalmatia.html http://bolcroatia.com/bol_croatia_apartments_brac_dalmatia.h...

Kilimanjaro 17y ago

Less talk, just ship it!

zokier 17y ago

This is one reason I'm not particularly fond of Mozilla. They care too much about ideology, PR and all that stuff. They have had the code but won't release it because it could make them look bad or annoy some web devs or doesn't fit their ideology. Why can't they just release stuff and see how it fares, and improve it based on public's response.

mbrubeck 17y ago
It's not just about ideology and PR... it's about keeping our users secure. And the "ideology" has a very pragmatic side: it's about keeping the web based on actual standards that can evolve rather than defacto standards that we will have to live with forever. We're dealing with this on the Mozilla Mobile team because of touch events. There is no standard for touch events in browsers. Mobile Safari and Android both implement touch events, and their implementations are partly compatible and partly incompatible. Mobile Firefox could choose to take one of those implementations and copy it. In the short term it would make us more compatible with some existing iPhone-optimized sites. But in the long run it would raise the barrier for getting web sites (and browser vendors) to switch to an actual standardized API. So we're going to try to get the WHATWG to agree on a standard for touch events before we implement them rather than after. The standards process is not just about ideology - it often catches significant design and security flaws, as it has with WebSockets. It's much harder to change an API once you've shipped it to a userbase like Mozilla's (hundreds of millions of people - around 30% of all internet users). Remember the story about Stuart Feldman when he was asked to make the Makefile syntax more sensible? He said he couldn't, because there were already over a dozen people using it.
FooBarWidget 17y ago
Not caring about ideology is what got us into the IE6 mess in the first place.
- Shorel 17y ago
  I disagree. Not caring about ideology over technology is what got us Chrome. The Embrace, Extend, Extinguish destructive MS ideology is what got us into the IE6 mess.