First, no offense if this answer is too obvious or basic. Your use of "separated" instead of terms like Ajax or jQuery makes me assume less experience with this topic. Of course i could be misreading the question, so my apologies if that's the case.
Use both, but wisely
Think of your choice of server-side or client-side tasks in terms of where and how a task is most efficiently done. This will help you render pages quickly (on the server), but offload work to the browser where it makes sense to do so. And, there will be gray areas where you just have to make a judgment call. Your job is to find a smart division of labor.
What belongs server side?
(This is an extreme example to illustrate the point.) Say you're writing a web app that does some type of searching. You don't write browser-side Javascript to call a server-side PHP web service to retrieve an entire 2GB database to "free up your server" and offload searching to the user's machine. What you do is get the search terms from the user with a form, POST it back to the server to query the database directly, then send the results back from the server to the browser.
The logic here is that the DB itself knows how to best do the query, the server is closer to the source data, and less data has to be moved around between components. The browser only needs what it displays, so don't send it all to the browser. (Not to mention relative language performance.)
What belongs at the browser?
Browser side code is your "separated" scenario (if i understand correctly). But for the browser to do most anything intelligent, it has to have server cooperation.
Okay, you've got your search app working but you want to spruce it up with some fancy pants Ajax. Write a PHP web service to take a few letters and return matching search terms, a la the "search suggest" feature of Bing, Google, etc. Write your browser code to only suggest terms after the user's typed in three or four letters, so your suggest list is small. Back at the server, index your database on that field so the search is fast fast fast.
Here the thinking is that "search suggest" is a feature that must be split between the server and client. The browser can quickly deal with targeted, small-ish piles of data. The server can get that targeted, small-ish pile of data and give it to the client. A poor division would be for the server to render a monster list (of say, 500,000 items) of possible field values as an XML island embedded in the HTML page, then have the browser search that as the user types. (a) sending all that data to the browser is slow, (b) searching it in Javascript will never be as fast as letting the DB search it, and (c) you're likely to blow up a user's machine by cramming all that data into their browser app space. On the other hand, you need to make sure that the Ajax call to the server, and the subsequent query and return are super-fast. No dilly-dallying around.
Where's the gray area?
Here again it's a judgment call. Above, i talked about the server doing the search, then sending the results to the browser. But, the question arises, do you let the browser submit the search terms with the form and have the server render the result page, or do you use client-side Ajax/Javascript to send the search terms and retrieve the results, then render it in a DIV to avoid a page refresh? Both are valid. Resource-wise, there's no real benefit either way. The Ajax way can provide a better user experience but, depending on your app and the circumstances, might present some other challenges (e.g. security).
Bottom line
Use both appropriately. Don't skimp on thinking and learning about architectural performance and efficiency. Move less data, fewer times. You'll take a load off your servers, your databases, and your users' browsers.
