[gnufied]

> I want one language that works on both sides and in fact allows OOP code sharing between the two.

I think, having one language in both frontend and backend does not work in long run, regardless of your preferred language of choice.

we love ruby and yet where I work - we actively maintain Ruby, Python, Javascript and Java applications. Besides, I find it too hard to write OOP code which is reusable within same problem domain, writing OOP code that crosses the concerns between backend and frontend sounds like inviting lot of problems and lot of useless discussion on - which code goes where.

EDIT: I didn't mean business agnostic code can't be shared between frontend and backend btw. Date parsing, uri parsing etc are examples of such libraries. But overall aiming to write business code that can be shared between frontend and backend is problematic.

[zem]

there are some great frameworks that do do one language everywhere (my top choices would be om and hoplon from the clojurescript camp, and opa from the custom language camp). there is something to be said for being able to seamlessly pass data around between the frontend and backend, and letting the language and framework handle the low-level details for you.

[sbov]

I've always thought this would be nice, but whenever I actually design the theoretical code that would use this, the savings is much less than I would have thought. Real world actualities like security and privacy can either remove many of your gains or, if you ignore them, leave you with what I'd consider a buggy website.

[alttab]

This can happen with knockout and other libraries when you end up dumping data into an object to send over simply to render it view side. You end up with a lot of wires between your controller and the view template rendered on the client side.