A common technique to prevent XSS attacks is to encode untrusted data before displaying it on the HTML page. Inside the page there are different contexts that it can appear in, every one requires different encoding.
Encoding the responses on the server-side doesn't make sense because at this layer we don't know where in the HTML page the data will appear.
So it is convenient and more reasonable to encode on the client-side. The question is if it's safe. On a first impression it sounds unsafe because the attacker can modify the client-code (say JavaScript). But when you think about it, the modified code will be available only to the attacker's browser. Other visitors of the web site won't be affected by the changes.
Is it still safe or am I missing something?
In theory, encoding client-side is no more dangerous than encoding server-side. The key to making it secure really is in how rigourous you are in putting suitable encoding in all the places which renders your data. You can certainly create a good implementation for rendering user submitted data safely on client and server sides. Practically though, a drawback of implementing output encoding client side is that a potential attacker can easily examine your source code for flaws. This means that if there are bugs in your client-side encoding implementation, it will be easier to find than say on the server-side (assuming a closed source system). If you are developing open source software, then this point is moot.
Also as you said, an attacker modifying your client-side encoding code is a non-issue as they will only be modifying their own copy of the code and will not affect other visitors.
IMO it is actually cleaner to let the client handle encoding especially if you are developing an API which is shared by web and native mobile applications. You don't want your mobile application to have to convert HTML encoded values back to it's original form.