最近几天，我正在研究在Web技术上实现chatting的更好方法。
做了研究，我发现node.js也有一些问题，如下所示
- 跨浏览器支持（旧版本的IE不支持），因为
web sockets。 - 作为其新工具，仍然不发达，因此API不稳定。
- 他们没有很好的文档可以跟进（但是是的，有很多文章可以提供帮助）
然后我决定在小程序中进行操作，以便于制作，但像往常一样，我做了一些研究，这个链接真的帮助了我。
它也有一些问题，例如
- 某些组织仅允许管理员安装软件。因此，默认情况下，许多用户无法查看小程序。
- 小程序可能需要特定的 JRE。
- 在 Java 虚拟机运行之前，它无法启动，并且首次使用它时可能会有很长的启动时间。
我也问过这个问题，但我只得到了 1 个解决方案，而且实施起来有点复杂，而且它也使用 Web 套接字。
我想使这个应用程序至少IE6，IE7用户不会有任何问题。
我的问题是，什么是更好的实施方式？
除了这两个之外，还有什么东西我们可以实现同样的事情，或者我们只需要选择这两个中的一个？
我没有使用任何框架。仅JSP + SERVLET
使用 Node.js 不会以任何方式限制哪些浏览器可以用作客户端。Node.js"只是"服务器。您可以使用普通的旧HTTP请求进行所有通信并忽略websocket，您将能够构建一个甚至可以与IE5一起使用的聊天客户端。
如果您决定使用 websockets 作为通信协议，那么这将限制可用浏览器的数量，但该决定不会强加给您。
另一方面，使用 Java 小程序会严格限制运行应用程序的浏览器数量：虽然大多数浏览器都可以运行小程序，但并非所有计算机都安装了 Java 运行时（坦率地说：很少有人会安装它只是为了运行聊天应用程序）。您还将排除几乎所有移动平台：它们通常不能运行小程序（对于支持 Java 作为其主要编程环境的移动平台也是如此）。
我不得不不同意 Node.js 文档的质量。文档很小，但非常完整：Node.js没有一个巨大的API。对于基于 Node.js 的库来说，情况可能会有所不同：其中一些是有据可查的，而另一些则不是。这通常是它们使用广泛程度的函数。
最好的解决方案是一个框架，当 WebSocket 不可用时，它将传输逻辑抽象出来并优雅地降级到其他传输（例如长轮询、闪存 websocket 等）。
Socket.IO 这样的解决方案，无论传输层如何，您都有相同的 API，并且您的应用程序即使在 IE6 中也能运行（因此，无处不在）：http://socket.io/