We've seen a great push towards using JavaScript in modern websites, using AJAX and JSON for dynamic websites which start to feel more like applications instead of plain boring pages. One of the problems which more interactive sites face is the constant polling of the web server due to the way HTTP works. Various web apps these days tend to poll for data with the server keeping the connection alive without sending any data, once data has been sent then a new request is sent asking for more data.
One particular web app which isn't that great is IRC web chat. Most IRC servers are keen on users connecting from their real connection, as it's hard to track abuse when connections are being proxied by a web server. Using AJAX or JSON with a web server isn't that ideal either, browsers have to constantly poll and refresh with the server to receive the data, this typically requires a light weight web server as Apache with PHP or Perl is hardly efficient for multiple users. The most common approaches over the years has been CGI:IRC, but this is just yet another inefficient Perl script which keeps the connection open. One of the oldest methods is using a hefty Java application, hardly friendly for users.
So, why not use sockets with JavaScript? Obviously JavaScript can't do it directly, but with Adobe Flash and something like socketBridge (or this improved version) you could control a socket with mostly JavaScript. The only problem with Flash and sockets is that it would have to connect to a policy port before being authorised to connect to that particular port, however it would be a much lighter solution for the server compared to all the polling techniques.
I'm tempted to try and create a web IRC client using JavaScript and the Flash socket bridge. Even if other IRC networks won't open a port for Flash policy requests, you could do something similar to the other web chat apps - use your server as a proxy.