For example, say you're building a Plex/Kodi-like web app. Your backend consists of a database with a CRUD API on /movies, so GET /movies returns all movies in the db, GET /movies/:id returns a specific movie by ID, etc. Now you want to implement the ability to sort the movies by genre, title, release date, etc. Should the front end just GET /movies and then do the sorting, or should the backend provide a new API method like GET /movies/{byTitle, byGenre, byReleaseDate} that returns a sorted list?
This is a specific example but I would also be interested in knowing how to decide where to put code in general when working with a full stack. Should things only be client side if they absolutely must be?
To answer your last question: yes, in general, put logic on the client-side only as a last resort, or to make UX more responsive (but do provide an alternative!).
In your specific case, you are probably thinking of a rather small sample set of movies. In practice, with something like IMDB, it would be absolutely impossible to send the entire movie database to the client, since (even without any media like thumbnails), it would be hundreds of megabytes in size.
This is the job of a database system – not only to store data efficiently, but also to query, sort, filter, and retrieve it efficiently and quickly. Doing filtering and sorting on the front end was not done in the past until recently, when framework became more powerful as a result of JavaScript being widely supported and more performant in all mainstream browsers.
Another thing to consider is accessibility. Even though JS is widely supported in mainstream browsers, there are devices besides desktops / laptops / phones. E-readers with Internet support, screen readers for the visually impaired, older browsers; people who choose to disable JavaScript with e.g. NoScript to improve privacy (see TorBrowser). These may be small fractions of the market, and your target audience might not include them at all, but it is something to consider. A well-designed website uses JavaScript only when available, falling back to a non-JS solution when necessary (less true in recent years, unfortunately).