7 ms·

Erlang Creator Joe Armstrong Wants to Ditch AJAX, Loves Chrome's New Web Sockets

116 points by xanados 17y ago

xanados 17y ago
It will be great once web socket support becomes more pervasive. True 2-way communication would be a great boon in the complexity department for a bunch of different types of web apps.
- ellyagg 17y ago
  Could I have a bittorent client running in Chrome?
  - xanados 17y ago
    Uh, I guess. They needed some way to support all the communication applications on their browser-OS after all...
  - daleharvey 17y ago
    they would need to provide a mechanism to allow connections to non origin domains, like crossdomain.xml I understand there are security implications, but I wish browser would stop creating prohibitively strict restrictions on web applications and make a somewhat sensible way too elevate permissions (same origin model, access to the clipboard, etc etc)
    - mlinsey 17y ago
      In addition, the NAT issues discussed elsewhere in this thread would also be a much bigger deal with P2P.
Jasber 17y ago
As they discuss, will proxies have to specifically enable Web Sockets to allow this to replace AJAX? I thought this was the same problem Flash sockets had, traffic being blocked.
- TimothyFitz 17y ago
  Yeah, I have absolutely no idea why Web Sockets aren't just an initial HTTP request and then a protocol switch (Upgrade header); that would work for the vast majority of proxies and make cookies/same domain/etc work seamlessly.
  - mcav 17y ago
    From the web socket spec: The protocol has two parts: a handshake, and then the data transfer. The handshake from the client looks as follows: GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: example.com Origin: http://example.com WebSocket-Protocol: sample The handshake from the server looks as follows: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo WebSocket-Protocol: sample
    - TimothyFitz 17y ago
      Well, that explains my disbelief. Thanks!
- daleharvey 17y ago
  I think the biggest problem with flash sockets was the flash part :)
  - adatta02 17y ago
    the biggest problem with flash sockets is the insane security policy file business.
jodrellblank 17y ago
> Websockets let you use RHTTP. The client connects, sends a request to switch to RHTTP, then becomes an HTTP server. This isn't going to be another SIP, is it? 'Yes we've all agreed on this protocol, off you go and use it. NAT? What's NAT? Is it important?'
- pmjordan 17y ago
  I believe the key is in the part that says The client connects. The client initiates the TCP connection (thus traversing NAT), which stays alive like any other HTTP 1.1 connection (which has a Content-length header). The server produces the requests, however. I suspect that in order to traverse proxies, the client establishes the original connection via the quasi-standard HTTP CONNECT method which is otherwise used for proxying HTTPS. This is conjecture, however, as I've yet to research RHTTP. EDIT: it seems my instinct on proxying was incorrect, other posts imply that the 'Upgrade' header is used. I'm a little surprised that this is widely supported by proxies. I suppose the proxy just keeps the connection open if there's no specified Content-length. Timeouts spring to mind as a potential issue.
- iamaleksey 17y ago
  Well, the NAT issue is almost solved with STUN [http://en.wikipedia.org/wiki/STUN http://en.wikipedia.org/wiki/STUN] and TURN [http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT] (in those cases where STUN is not enough). Together they make ICE [http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...]. But none of these is needed for websockets to work.
  - crux_ 17y ago
    N.b. --- those solutions only work for UDP traffic, not TCP; if you want to use them and have a reliable stream protocol you'll end up reinventing TCP atop UDP.
    - RiderOfGiraffes 17y ago
christofd 17y ago
Something new to play with. Joe hits the sweet spot, regarding powerful & pragmatic, again. Websockets + Erlang... nice.
cmelbye 17y ago
Am I the only one not excited by WebSockets? It seems like a nice layer over a new Comet method that's even more complex than the long-polling method that we're using today. The server still needs to handle tons of open long-running connections, but with WebSocket you have the added complexity of having to support a brand new protocol in your web server - whatever that may be - instead of one that your web server has supported since it was created. Personally, I'd rather someone just write a minimal interface (i.e. not Bayeux) to long-running Comet connections using XMLHTTPRequest. It should be trivial after that to make it compatible with the nice API that WebSocket has exposed.
- daleharvey 17y ago
  the Bayeux isnt accidental complexity, its hard bolting a bidirectional asynchronous protocol over plain http. the protocol is simple to implement (10 lines server, 10 lines client for an echo server), and is a completely natural extension to traditional socket programming. I am pretty excited by it.
- jerf 17y ago
  "It seems like a nice layer over a new Comet method that's even more complex than the long-polling method that we're using today." Exactly backwards. Comet is a thick, ugly layer that is way more complex than sockets. It adds staggering resource overhead to the real abstraction you want; it will in the end be way easier to support a ton of WebSockets than a ton of Comet connections. (That may not be true of pre-optimized implementations, but it will be true of final implementations.) You don't add Socket support to your HTTP server... you have to add HTTP support to your (TCP) Socket server! This is the minimal interface; it's Comet that's the hacked up hideous ugly kludge that should never ever have been born because when that dude at Microsoft went to add XMLHttpRequest, if he'd had a clue what that bastard monstrosity would become, he would have created WebSockets right then instead. I don't blame him, it would have taken a lot of vision at the time to understand that. But this is what we should have had from day one, and Comet should never have been. We have spent a truly astonishing amount of time in the web world deep in the woods, failing to take advantage of simple things that have been known since the 1960s. We've been in the woods so long that people have come to mistake the hacks for the right answer. They're still hacks. Sockets are the not-a-hack. (Though personally I'd still have gone for real sockets.)
tlrobinson 17y ago
Sometimes I'm glad I'm not famous enough to have everything I say scrutinized and re-broadcast.
- shawndrost 17y ago
  http://twitter.com/shawndrost/status/6547879113 http://twitter.com/shawndrost/status/6547879113
- alanthonyc 17y ago
  Just sometimes?
- ellyagg 17y ago
  To be fair, Joe Armstrong just adds interest and credibility. It's not as if this is gossip. When you click the link, you get a working example of an Erlang program connecting to Chrome's new web sockets interface.
InclinedPlane 17y ago
If the AJ in AJAX uses web sockets instead of XMLHttpRequest, isn't it still AJAX? Besides which, the X in AJAX is JSON often enough nowadays.
- jonny_noog 17y ago
  I guess it would be AJWS then. They're going to have to come up with a better acronym than "Adj-wuss" before this thing takes off.
axod 17y ago
I've just completed implementing WebSocket support into our Mibbit webserver. The interesting part is this: Currently, we use XHR long polling, keep alive. Basically a raw socket with some HTTP header spam mixed in. On the plus side, we can deflate/gzip the contents (unfortunately not across messages, but still does well). But on the negative, the HTTP headers are often about the same size or larger than the contents. So, webSocket will improve the situation, in that there won't be HTTP header spam. Also we'll be able to use a single connection instead of two (One for sends, one for recvs). On the downside, there also won't be any deflate/gzip (Unless implemented in js etc). The other big bonus with WebSocket is you can connect to a different port. Something that's not possible (For some idiotic reason) with XHR. It'll be interesting to see which one wins :) Pretty cool to see this in Chrome, I thought Firefox would be first to implement it.
- flashingpumpkin 17y ago
  Pretty cool to see this in Chrome, I thought Firefox would be first to implement it. If you wade through the thread, you'll see that someone posted that Firefox/Mozilla had it in trunk for nearly/over a year. Didn't check myself though.
GeneralMaximus 17y ago
Ah. So this is why Google built their own browser. I fully expect to see more goodies coming out of Mountain View in the future. Heck, even I might finally decide to play with web technologies :p

116 points by xanados 17y ago

It will be great once web socket support becomes more pervasive. True 2-way communication would be a great boon in the complexity department for a bunch of different types of web apps.

ellyagg 17y ago
Could I have a bittorent client running in Chrome?
- xanados 17y ago
  Uh, I guess. They needed some way to support all the communication applications on their browser-OS after all...
- daleharvey 17y ago
  they would need to provide a mechanism to allow connections to non origin domains, like crossdomain.xml I understand there are security implications, but I wish browser would stop creating prohibitively strict restrictions on web applications and make a somewhat sensible way too elevate permissions (same origin model, access to the clipboard, etc etc)
  - mlinsey 17y ago
    In addition, the NAT issues discussed elsewhere in this thread would also be a much bigger deal with P2P.

Jasber 17y ago

As they discuss, will proxies have to specifically enable Web Sockets to allow this to replace AJAX? I thought this was the same problem Flash sockets had, traffic being blocked.

TimothyFitz 17y ago
Yeah, I have absolutely no idea why Web Sockets aren't just an initial HTTP request and then a protocol switch (Upgrade header); that would work for the vast majority of proxies and make cookies/same domain/etc work seamlessly.
- mcav 17y ago
  From the web socket spec: The protocol has two parts: a handshake, and then the data transfer. The handshake from the client looks as follows: GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: example.com Origin: http://example.com WebSocket-Protocol: sample The handshake from the server looks as follows: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: http://example.com WebSocket-Location: ws://example.com/demo WebSocket-Protocol: sample
  - TimothyFitz 17y ago
    Well, that explains my disbelief. Thanks!
daleharvey 17y ago
I think the biggest problem with flash sockets was the flash part :)
- adatta02 17y ago
  the biggest problem with flash sockets is the insane security policy file business.

jodrellblank 17y ago

> Websockets let you use RHTTP. The client connects, sends a request to switch to RHTTP, then becomes an HTTP server. This isn't going to be another SIP, is it? 'Yes we've all agreed on this protocol, off you go and use it. NAT? What's NAT? Is it important?'

pmjordan 17y ago
I believe the key is in the part that says The client connects. The client initiates the TCP connection (thus traversing NAT), which stays alive like any other HTTP 1.1 connection (which has a Content-length header). The server produces the requests, however. I suspect that in order to traverse proxies, the client establishes the original connection via the quasi-standard HTTP CONNECT method which is otherwise used for proxying HTTPS. This is conjecture, however, as I've yet to research RHTTP. EDIT: it seems my instinct on proxying was incorrect, other posts imply that the 'Upgrade' header is used. I'm a little surprised that this is widely supported by proxies. I suppose the proxy just keeps the connection open if there's no specified Content-length. Timeouts spring to mind as a potential issue.
iamaleksey 17y ago
Well, the NAT issue is almost solved with STUN [http://en.wikipedia.org/wiki/STUN http://en.wikipedia.org/wiki/STUN] and TURN [http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT] (in those cases where STUN is not enough). Together they make ICE [http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ...]. But none of these is needed for websockets to work.
- crux_ 17y ago
  N.b. --- those solutions only work for UDP traffic, not TCP; if you want to use them and have a reliable stream protocol you'll end up reinventing TCP atop UDP.
  - RiderOfGiraffes 17y ago

christofd 17y ago

Something new to play with. Joe hits the sweet spot, regarding powerful & pragmatic, again. Websockets + Erlang... nice.

cmelbye 17y ago

Am I the only one not excited by WebSockets? It seems like a nice layer over a new Comet method that's even more complex than the long-polling method that we're using today. The server still needs to handle tons of open long-running connections, but with WebSocket you have the added complexity of having to support a brand new protocol in your web server - whatever that may be - instead of one that your web server has supported since it was created. Personally, I'd rather someone just write a minimal interface (i.e. not Bayeux) to long-running Comet connections using XMLHTTPRequest. It should be trivial after that to make it compatible with the nice API that WebSocket has exposed.

daleharvey 17y ago
the Bayeux isnt accidental complexity, its hard bolting a bidirectional asynchronous protocol over plain http. the protocol is simple to implement (10 lines server, 10 lines client for an echo server), and is a completely natural extension to traditional socket programming. I am pretty excited by it.
jerf 17y ago
"It seems like a nice layer over a new Comet method that's even more complex than the long-polling method that we're using today." Exactly backwards. Comet is a thick, ugly layer that is way more complex than sockets. It adds staggering resource overhead to the real abstraction you want; it will in the end be way easier to support a ton of WebSockets than a ton of Comet connections. (That may not be true of pre-optimized implementations, but it will be true of final implementations.) You don't add Socket support to your HTTP server... you have to add HTTP support to your (TCP) Socket server! This is the minimal interface; it's Comet that's the hacked up hideous ugly kludge that should never ever have been born because when that dude at Microsoft went to add XMLHttpRequest, if he'd had a clue what that bastard monstrosity would become, he would have created WebSockets right then instead. I don't blame him, it would have taken a lot of vision at the time to understand that. But this is what we should have had from day one, and Comet should never have been. We have spent a truly astonishing amount of time in the web world deep in the woods, failing to take advantage of simple things that have been known since the 1960s. We've been in the woods so long that people have come to mistake the hacks for the right answer. They're still hacks. Sockets are the not-a-hack. (Though personally I'd still have gone for real sockets.)

tlrobinson 17y ago

Sometimes I'm glad I'm not famous enough to have everything I say scrutinized and re-broadcast.

shawndrost 17y ago
http://twitter.com/shawndrost/status/6547879113 http://twitter.com/shawndrost/status/6547879113
alanthonyc 17y ago
Just sometimes?
ellyagg 17y ago
To be fair, Joe Armstrong just adds interest and credibility. It's not as if this is gossip. When you click the link, you get a working example of an Erlang program connecting to Chrome's new web sockets interface.

InclinedPlane 17y ago

If the AJ in AJAX uses web sockets instead of XMLHttpRequest, isn't it still AJAX? Besides which, the X in AJAX is JSON often enough nowadays.

jonny_noog 17y ago
I guess it would be AJWS then. They're going to have to come up with a better acronym than "Adj-wuss" before this thing takes off.

axod 17y ago

I've just completed implementing WebSocket support into our Mibbit webserver. The interesting part is this: Currently, we use XHR long polling, keep alive. Basically a raw socket with some HTTP header spam mixed in. On the plus side, we can deflate/gzip the contents (unfortunately not across messages, but still does well). But on the negative, the HTTP headers are often about the same size or larger than the contents. So, webSocket will improve the situation, in that there won't be HTTP header spam. Also we'll be able to use a single connection instead of two (One for sends, one for recvs). On the downside, there also won't be any deflate/gzip (Unless implemented in js etc). The other big bonus with WebSocket is you can connect to a different port. Something that's not possible (For some idiotic reason) with XHR. It'll be interesting to see which one wins :) Pretty cool to see this in Chrome, I thought Firefox would be first to implement it.

flashingpumpkin 17y ago
Pretty cool to see this in Chrome, I thought Firefox would be first to implement it. If you wade through the thread, you'll see that someone posted that Firefox/Mozilla had it in trunk for nearly/over a year. Didn't check myself though.

GeneralMaximus 17y ago

Ah. So this is why Google built their own browser. I fully expect to see more goodies coming out of Mountain View in the future. Heck, even I might finally decide to play with web technologies :p