[gbog]

As noted somewhere else learning node is not learning front-end. Something that bothered me recently is that on the back-end we are used to big oop frameworks when in fact the stateless nature of http do not match oop so well. On the front end however we have a gui so oop is a good paradigm.

[cwp]

Huh? What does the statelessness of HTTP have to do with OOP, particularly on the server, but not the client?

[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.

[antihero]

I guess because you effectively have to re-initialise most things on a per-request basis or run into race-conditions etc.