I'm not sure why you're getting downvoted, because you're right. To be more specific, server code has very different responsibilities than client code, not to mention very different runtime characteristics (e.g. servers are both trusted and under total central control, unlike clients).

To say that the client/server split is "arbitrary" is rather silly.

(That's not to say I'm not a fan of an end-to-end language. Meteor shows what you can do with this. Maybe ClojureScript can do this, but with a better language.)

He is getting downvoted, and rightly so, because the person is replying to has clearly set up his system is such a way that some code runs on both the server and the client.

Which is very reasonable, btw, as it allows you to have a static site that renders for those whoes browsers doesn't run javascript and a more dynamic page for those whoes browser does run Javascript. You are guaranteed that everything renders the same way only if you excecute the same code (this can't be replaced by e.g a sensible template system because rendering might also be affected by how you, e.g, sort comments).

We're doing that too, but that's the boring part. That's just running client-side code on the server. It's still client-side code. You can do that in Rails too. See my other comment for more details.

If you are running client side code on the server you use a very different definition of client side code than most other people, which is bound to be confusing.

We have lots of code that runs on both the server and the client. It has the same responsibility whether it's run on the server or the client.

Can you provide some examples?

To oversimplify, if the user clicks on a button on our website, the app checks to see if the operation can be done client-side. If it can be done client side, it's done client side instantaneously. If it's too big to do client-side or requires access to resources that aren't available on the client, the app submits a job to the server, and shows the client a progress bar.

They're talking about the split of programmers, not of concerns. The client-server model is definitely here to stay but having separate groups of people handling each side is a sure way to greatly lower the quality of the product.

You mean that one needs competent developers? That is nothing new. At least a few of the developers should now both languages and sides.