Sure, any large code base needs to be modular, but why impose an arbitrary split?
We've got a large Node.js codebase. Some of the code runs only on the server, some runs only on the client, but the majority runs on both. Our code is split into modules for functional reasons.
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.
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.
I tend to agree with you, but there are things that can/should run on both - validation of input for one. But I'd like to hear other things - I hear "use the same code on the server and client" all the time, but I haven't found a lot of use for that personally.
Turning a reactive web application into a regular "web site" -- ie. allowing you to use the bulk of the application without Javascript enabled. Great for SEO, too, at least until Google gets Javascript execution further along (which it's certainly doing, and getting better every day).
The Meteor framework [1] uses this to good effect to support latency compensation.
You can optionally choose to include Meteor methods (ajax-style remote endpoints) on the client. Then when the method is called, the client-side version is run in addition to the real, server-side one being kicked off. If the server-side returns an error, such as due to insufficient permissions, the changes made client-side are rolled back. Combined with Meteor's client-side mongo implementation and reactive UI updates, it gives impressive "perceived performance" benefits.
Aside from things like general libraries (e.g. serializing/deserializing data to/from the client), anything you want to happen client-side that you don't trust the client for, you will need to re-run on server side.
A simple one is validation of forms, but also doing rapid UI updates without having to do network round-trips.
We've got a large Node.js codebase. Some of the code runs only on the server, some runs only on the client, but the majority runs on both. Our code is split into modules for functional reasons.