By: +David Herron; Date: 2011-05-27 19:16
Event driven I/O: As I wrote earlier (see: COMET as a justification for using Node.js?) Node.js seems perfectly architected to solve a problem we expect to be more prevalent. Long running connections between web server and every client browser that's touched the server recently. Thread-per-connection systems don't scale well for this use scenario, non-threaded event driven systems do.
This architectural decision contributes to the high performance numbers claimed for it.
It's also a simpler programming model than highly threaded thread-per-connection systems.
Loosely defined objects: This I think is a mixed blessing. Yes it's way convenient to be real loosey-goosey with your objects. For example just check if it has a function named suchAndSo to give you a clue whether you can use the object for something or other. But I think this is a bit of a panacea and can lead you to hairball systems as complexity grows larger.
There's an argument circling around Java for years along these lines. That because Java is so highly rigid it was inconvenient to program in, and that the rigidity hurts programmer productivity. I'm not convinced, especially when you consider all the time saved because the Java compiler knows a heck of a lot of information about each object and can directly tell you about misuse of methods, improper type combinations, and IDE's that know exactly what you're doing and can provide a drop down list of all possible method completions as you're typing code.
These are a few thoughts. I'm interested in hearing what others have to think.