Take the 2-minute tour ×

Ok, I am working up something like a chat environment, and I'd like to have near real time if not real time conversation. But I know browsers will only give up 2 threads at a time for transactions per domain. So I am trying to figure out a way to make a synchronous chat without really effecting the browser. I also know browsers tend to lock up with synchronous requests.

So whats the best approach at creating a chat like environment on a site from scratch, assume the DB and scripting concept is fine, its the managing of the connection, wondering how to keep a persistant connection that won't congest the browser and cause it to possibly freeze up.

Anyone have any ideas.. Im not looking for flash, or java based solutions. I'd prefer not to poll every second either. But what is stacks impression, what would you do.

share|improve this question
A synchronous chat without affecting the browser? The very definition of synchronous makes that impossible. Anyway, look into web sockets, specifically Socket.IO. –  minitech Jun 6 '12 at 1:32
add comment

2 Answers

up vote 2 down vote accepted

First off, the spec only suggests that two connections are allowed. Most modern browsers actually support up to 6.

There're three main accepted methods for creating a chat system out of pure Javascript:


The first solution is simple, and just involves polling the server every few seconds (5 is a nice number) to see what it's missed. It works simply and efficiently, but can lead to large amounts of unnecessary requests if not careful, which can cause unnecessary server load.

A better implementation of this involves polling to simply check if anything's happened since the last chat update, and if so, only then go through the process of finding out what's happened. Saves on the server load and bandwidth fronts.


This method's more commonly used, and involves the browser sending a request to the server which is never fulfilled, and instead keeps 'waiting for a response'. When something happens, the server outputs it and fulfills the request, and the client makes another request and the process repeats. This saves on the request front, but can end up with a backlog of ongoing processes on your server.



This involves creating a direct socket connection to the server, allowing data to be pushed to the client when needed. It's relatively new though, and can have some compatability issues, especially with older browsers.

Out of these, none of them is specifically the 'best method'; it depends on what you're aiming for, and what matters. If you've got a site designed for up-to-date browsers, then websockets could be your answer, but if you've got a small-ish server, then polling could be better, for example.

share|improve this answer
Good arguments on all cases. Seeing the 3 fronts presented like that makes it nicer overall to come up with a conclusion to then start doin a bit more research on. I appreciate it. Overall I would say our site is gonna be better suited for modern browser, we intend on supporting older browser to a point but the hope is a majority will come modernized. This is also generally a temp solution. Eventually its likely we will have a dual concept. One that works with Sockets as the primary and one that falls to either polling or waiting as a fallback. –  chris Jun 6 '12 at 1:42
Overall though this particular thing is to create a mobile chat that will be running upwards of 4 hours at a time when it is up, but there will be multiple rooms capable of housing up to maybe a couple hundred people per room (or thats the hope) –  chris Jun 6 '12 at 2:11
add comment

My own chat engine checks for new messages every five seconds. That's close enough to instant that nobody knows the difference.

It's as simple as setInterval(updateChat,5000);.

share|improve this answer
add comment

Your Answer


