You know that JSON is a "stringified" version of an object, and you know that this stringified version is used to preserve the object across boundaries where raw, binary data transmission is not practical (or possible). However, one thing I didn't really touch on, and so I'll now explain, is exactly why someone would transmit an object to some other environment anyway. Objects are nice ways to not only pack functionality, but also state - so in the case of browser-based programming, for example, you could easily see yourself creating an object that represents the behavior of a button element, setting some state (such as color, what happens when the button is clicked, etc) and sending it down to the client. So, the reason you'd do such a thing as send an object down to the client is because that object represents state and functionality specified by you on the server; once downloaded to the client browser it can then be used to reflect that state to elements within the browser in a nice, packaged form.
Let's step back a bit and make up a quick example.
Say you have a DIV tag on your page and this DIV tag is to do something when you click it. You could set the div tag's onclick handler to run some kind of javascript:
<div id='mydiv' onclick='doSomething();"/>
