- no real issues with performance or usage (see benchmarks section in the README, that being said Common Node isn't in production anywhere yet), Common Node runs at about 70% throughput (in req/s) of plain Node and uses around 10% more memory in high throughput benchmarks; comparing Node and CommonJS implementations like for like is difficult though, since for example Node doesn't clear its Buffers
- Node's insistence on reserving the "fs" module name & removal of exports.paths has been a slight issue - it means the users either have to set NODE_PATH manually or need to run apps via the bin/common-node wrapper script to retain compatibility with other CommonJS platforms
From a community point of view:
- as you say, people are pretty resistant & I spend a fair amount of time one on one trying to convince (ex) front end Node.js developers why a sync programming style isn't "magic" and is easier to work with; hoping to remedy that by doing a few talks at various events over the next few months and might write a blog post or two
- lack of clear CommonJS proposals for Sockets and Subprocesses
- the whole sync ServerJS scene is very fragmented - it would be nice to have a project like commonjs-utils or a subset of narwhal which implemented the JS only modules (like base64 etc.) and became the de facto standard lib that they would all use rather than reinventing the wheel and making it impossible to write portable webapps
The Node community seems pretty resistant to alternative concurrency models like fibers, etc, which I think is unfortunate.