Passing variables or data via the querystring in the URL is standard practice for GET requests, but represents a security risk when transmitting sensitive information. Since the script is hitting a URL, that hit would be recorded on a webserver’s access logs, so by extension, any data in the query string would also get recorded. This is not a big deal if the data is something like a record ID, but could be a big deal if transmitting data like passwords, bank accounts, ssn’s etc. The proper way to send data in these scenarios is to use a POST request instead, which jQuery can handle. To my knowledge, there is no way to initiate an HTTP POST with the above approach.

I would not recommend placing javascript code in a server-side script in this fashion because it is a poor separation of concerns with regards to code maintainability. Most web developers expect to both find and work with javascript on the client side of things. As a practical example, suppose the above script is more complicated than simply changing the HTML string of a particular DOM element. A sufficiently complicated script will take time to develop and debug properly, and this process would be made unnecessarily more complicated by having the code reside on a server-side script. My recommendation would be to keep all client code defined on the client side, and have the server scripts do only what they are required to do–in this case, to return a string based on an input string. Then, the client side parses the return data and acts accordingly.