The engine is written in C# on the backend, and of course, JavaScript on the front end.

You can check out the sample chat client that leads you to the following code:

Each user asynchronously pings a url on the central server at a given interval, sending its changes and retrieving changes of other visitors. The retrieved changes are dispatched through the javascript library, so the clientside application may act upon it.

The client consists of a single 5k javascript file, and the server is a single C# class library that can be embedded as source, or as a dll.

Focus of the q42 multiplayer engine was to give developers full control and not come up with any restrictions to the type of application that is being developed.

Features

• Easy customization and full control. Example project included
• Easy grouping of users that can see eachother by means of virtual "rooms"
• Automatic room upscaling when a certain amount of users is reached
• Automatic cleanup of empty rooms and idle users
• Persistent user properties (for example: name, x or y position)
• Nonpersistent user events, such as chat messages
• Full control over rooms, names, properties, events and its values
• Moderating features can be implemented easily
• Optionally allowing multiple users per session, so each browser-tab can represent a new user.

You can see Todd's work via core.js, which is worth looking at to see the Event.onDOMReady(..) and the like.

Here is a new room:

It’s the only site that shows you where your friends are hanging out and lets you surf for other people based on location. It supports all the major networks: MSN, AIM/ICQ, Yahoo, and GTalk/Jabber. And you can use radiusIM from anywhere because there are no downloads.

It uses Ajax heavily, and is built on the Dojo Toolkit.

I hope that offline matters less and less over time, but for me connectivity can be very spotty indeed. It isn't just when you are on a plane. EVDO and friends often suck. Wireless often sucks. Hell, if they can't fix it so my calls don't drop all the time then how can I expect decent net access from anywhere? And all of this is from someone living in the bay area, let alone Lonely, Wyoming, or somewhere in the third world (yes they have internet too!)

The folks at Cerulean Studios (makers of Trillian IM) have blogged about their offline IM client that is Flash based, but can jump offline.

The current focus of the technology is to rip application-quality web software *out* of the browser and *on* to the desktop. It is (currently) technically impossible (for security reasons, at the very least) to magically invoke a real application on your desktop without a download of any sorts; the current demo you’re watching is using a small Firefox plugin to do its dirty work. The actual IM product is still the same web-based Flash that you’re invoking from your web browser. In a way, you can just think of this as a mini web browser (very mini :) ).

The client is XUL based, so requires Firefox 2 or can be run as a stand-alone XULRunner:

OneTeam handles presence, one-to-one chat, file tranfert, user business card and group-chat in realtime. Based on the XMPP protocol, it enables both secure and private chat inside the company, but can also be opened in a control manner to selected servers in partner organizations.

For example, it is possible to be interrupted only by people working on the same project at a given time. Other messages will be delayed until a moment you have chosen.

As a side effect of this project, the library & socket daemon framework used by the chat application is released as open-source at http://www.chabotc.nl/phpsocketdaemon

Check out the demo

We talked to Chris about his project, and asked him if he could share with us the biggest challenges. He kindly came up with:

The greatest challenge writing this was to make it scale up, and keep IO in check. The orignal plan was to layer out the http, irc and comet components, but the overhead of sending all the event trafic over local loops/connections when dealing with hundreds to thousands of connections, is just to much. All the memory bandwidth used would then be multiplied 3x, which was just a to high of a strain on the system.

Second challenge was that there were no decent comet implementations available (except for dojo's which i used as a reference), and there was definitely a challenge that there were no PHP (my preferred language) libraries or tools available which could deal with a large amount of always-on connections, even fast-cgi with something like lighttp just wouldn't scale to hundreds of live connections, and the memory needed would be horrendous, hence the new php socket daemon library was born, its a riskier model, if the program has a fatal crash (great care was taken to avoid this) the service has to be restarted again (happens automaticly), loosing the client connections in the process, however it now only takes 15Mb of memory under moderate load, and guarantees responses in under 0.15ms, something that would be unfeasible with a clasic apache/php situation.

Also most of the heavy lifting (such as link and color parsing, etc) has been lifted to the client, it would be way to heavy for the server to do all of this, and still be able to scale up

Likewise the javascript side of things took a bit of trial and error too, some channels can have thousands of messages, and hundreds of members, so browser speed has defiantly been an thing to optimize too.

Lastly the back-end uses a plain old IRC server, which is almost infinitely scalable, just add a server, link the IRC servers together, and run another web chat back-end on it, repeat ad infintum.. (irc networks are known to have many hundreds of thousands of people connected, using this as the backbone of the messaging provides guaranteed scalability)

Meebo made a huge splash when it came onto the scene. It was an example of a real world app inside the browser, in this case chat. From that we started to see chat everywhere :)

It also had the side benefit to proof that people would trust their passwords into a meta service like this, but that is another issue.

Meebo just had a large update that they call release XX: one giant leap.

With the pop-out feature you can see that it is hard to tell the difference between meebo and a native app.

Here is meebo and Adium side by side:

What's New

1) New visual design - Sandy and I were Photoshop newbies when we first designed meebo and we’ve been itching for an updated look. We’re thrilled to show off David’s latest work!

2) Pop outs - click on that little icon in your IM window to “pop” the window out of the main meebo browser (don’t forget to disable any pop-up blockers you have for meebo.com).

3) Drag and drop buddy list management - Harry A. wrote, “I’d like a way to easily consolidate and manage groups.” Mike C., Frank R., and Rafael F. agree. The ability to move buddies between groups has been our most popular feature request for a while. Enjoy!

4) Skinning - we understand a few of you might be attached to the meebo’s first look and feel. If you are feeling nostalgic, we’ve introduced the ability to switch back to the old skin - just go to the preference area and select the ‘Classic’ skin. Keep an eye out for more skins in the future.

More good stuff…

* Individual sign on and off - now you can manage your screen names one-by-one. Just click on the drop-down menu in the left-hand console area.

* Localization - In addition to Bangla, Creole, Esperanto, Iloko, Jawa, Latin, Malagasy, Marathi, Mongolian, Nias, Swiss German, Thai, Uzbek support - we’ve also translated other parts of the UI such as buttons, menus, and links. The language updates dynamically based upon your location and preference too. Thai looks really good on the new front page!

* Updated Chat Logs - Chatlogs just got a facelift. Power-users (like Sandy and Andreas) will appreciate the new design and speedier loading times.

* AIM Profiles - This has been one of the top three requests for many weeks. AIM users, check out the ‘Set Profiles’ in the console area. Mark recently got engaged, guess what he announced in his profile this week! Congrats!

* Optimization - We’re always trying to make meebo better and faster. Those of you with very large buddylists, like user rnbmelody, will appreciate the new performance enhancements.

It is a simple Ajax chat widget that allows people to leave notes.

It is implemented with the JSOLait library and you can place with a demo box.

Pyro embeds WebKit on OS X (which is very easy to do, enabling these applications nicely) to offer a rich experience on top of 37 Signals Campfire chat application.

Why would you want to do this? What if you want a dock icon to bounce when a message comes in, or show you how many messages are there, or do a good job at alerting you in other ways (e.g. could intergrate with Growl). Pyro does those things that a pure web application can not.

This isn't the first of these hybrids. Apple iTunes itself is kind of like this. A rich shell around a web engine. But iTunes doesn't offer a pure ajax application to go with it.

Wildfire is an enterprise instant messaging (EIM) server dual-licensed under the Open Source GPL and commercially. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Wildfire is incredibly easy to setup and adminster, but offers rock-solid security and performance.
Use Wildfire in your organization as a more secure and feature-rich alternative to the consumer IM networks. Or, replace your existing EIM server with a more open, easier to use, and much less expensive solution.

The system is similar to Quek, which does something similar but with little Quek avatars running around the page. Unfortunately, it's never been that stable.

Also, WizLite does web page annotation, but relies on either a bookmarklet or a browser extension. With both Wizlite and Gabbly, website authors can also choose to embed the special content on their pages by including some Javascript.

Update: The test is over.

Realtime on Rails is a RoR app using Ajax HTTP streaming to update browsers from the server.

It includes:

• A ruby HTTPD for mediating the push connections
• A JS Window system and two demo apps: Chat/IM with rich text editing (Dojo) MP3 player with shared playlist (using AFLAX)

This application will be published under an LGPL license at the beginning of February.

It offers a few differences, such as promoting the chat service rather than the just the chat client.

This means that you can be in any chat room, and click "Options" and "Share Chat" to get the code that you can embed in your own site.

Meebo is the top Ajax client, and is a fantastic example of what you can do with Ajax. It looks nice, acts responsive, etc. There is a reason that it gets mentioned in all of the lists of quality Ajax applications.

I think an interesting debate could be have on whether IM is the kind of application that should be implemented via Ajax versus a rich desktop interface.

Some things that come to mind for me:

• Does it help to have the IM widget within a browser?
• What does the browser add to the experience? (mashups?)
• It could be nice to be able to leave the web, but have the client stay logged in to IM
• Do you feel weird inputting your user/password for each service to a web page?
• Do you want offline access to your conversations
• It is interesting that a lot of students/workers use it to get passed firewalls and such, but is it enough for rich clients to HTTP tunnel?

What are your thoughts?

For more details and the full docs check out Martin's blog entry, or grab the source (GNU GPL). Or just go to the demo and play around with it - keep in mind its the first release so no guarantees about stability!

The responsiveness in Firefox was very impressive, better then any I'd seen from similiar Ajax chat apps. Very nice work, guys!

Wesley ends up wanting to have a <?JS ... ?> construct a la PHP. Why does he want this? So he can share code between the client and server side of the application.

He rewrote the same functionality for a couple of the features (although you could of course use XHR to run that functionality on the server side and get the result back to the client).

This is another example of how JavaScript on the server side is probably going to grow.

With tools like Mozilla Rhino, you can do this right now.

Are many of you using JavaScript on the server?

JWChat aims to be a full featured, web based Jabber client. It uses only JavaScript and HTML on the client-side. Currently it supports basic jabber instant messaging, roster management and muc-based groupchats.

JWChat is an advanced instant messenger (IM) just like AIM, MSN Messenger, Yahoo! Messenger or ICQ. This means you can manage your contacts, chat with other users directly or join a groupchat room for collaborative communication. Unlike other IMs you can use this with your web browser only without having to install any additional software at all. For a list of supported browsers see below.

All of your settings, bookmarks and your contact list are stored at the server side. This means that you have access to your personalized client from almost any computer as long as it's got access to the internet.

Check out the Demo Site

They just released an Ajaxian chat module.

The code exists here.

Wael implemented a magical diary, inspired by the magical diary in "Harry Potter and the Chamber of Secrets" using a chatbot, Ajax and some cool scripting :)

How about that for an ode to the new book coming out this weekend?

Type in questions, and Tom Riddle will answer them.