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?
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.
Where's the gray area?
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.