[HeyImAlex]

Because most server side languages take a "throw away the world" approach to web programming; none of your objects persist in memory through requests, which means every time a request comes in you have to reload a part of the user's world from the db, service the request, and then destroy the world you've just created. For structural things like MVC, objects are great, but you really don't see much of the "object as vehicle for data encapsulation" that's drilled into every new programmer when they're first taught OOP.

The client, on the other hand, can persist data and objects through requests, and the only time it needs to be fully refreshed is on a full reload.

[cwp]

Ah. But that isn't an issue of language or object-orientation. There are server-side frameworks that don't throw away the world, and client-side frameworks that do. (Notice how your javascript state is thrown away everytime you load a new page in the browser). That's a design decision that's made possible by the statelessness of HTTP, but not required by it.

[gbog]

Certainly, but throwing away the world is natural on server side code and it means that your carefully crafted object don't live long and many of them don't need too be objects, they are micro namespaces for a set of methods. I never tried node.js for real but one good side off it could be that you are not pushed towards objects like you are with Python, Ruby, Java, etc.