The reactor is explicit. "Explicit is better than implicit." You don't have to always be in the reactor, if you don't want to. It lets people use Twisted to bui

The reactor is explicit. "Explicit is better than implicit." You don't have to always be in the reactor, if you don't want to. It lets people use Twisted to build GUIs and other things, without always being in the reactor's context. Twisted is a general-purpose networking library, not a tiny-web-servers-only networking library. An example used to illustrate and educate does not necessarily result in the shortest code sample. That sample does not use twisted.protocols.wire.Echo, because it was decided that things should be explicit and obvious in the samples on the front page. The reason for separating protocols and factories is simple: Sometimes you need to store per-connection state, sometimes you need to store per-server state. The separation permits developers to store things in factories instead of in global objects. Node doesn't have this distinction, and as a result, things like tracking all connections currently made on a server are cumbersome. Another thing is testing. How should a person test the Node example? Every bit of the Twisted example is trivially instrumentable; I can access the protocol, the factory, the reactor. I could, if I wanted, replace the reactor with something mocked. There's no place to do that in the Node example. I was gonna type out an IRC bot, the favorite exercise of novice coders, but I felt that would be petty, since there's no IRC library included in Node.