The purpose of salting is to increase the effort required in brute force by a significant amount without increasing load on the end user. It also helps in combating the use of hash tables and rainbow tables for password cracking. Salt should never be reused because if salt is fixed then a new rainbow table can be generated using the salt.
Since the connection is over HTTPS, the only disadvantage of submitting the original password to the server is the risk of it getting leaked in logs. If logging is done properly with no traces of plaintext password then there is nothing to worry and most of the sites (Google, facebook, twitter, etc.) submit your original password on their servers and then hash it before storing.
Even if your database is compromised and all the salts are leaked, they'd be of no help if each salt is unique and generated randomly. So both of the options provide almost the same level of security with the only advantage in generating hash on the browser being the avoidance of password leak via server logs.
If you're talking about salt getting compromised over the network, it won't be possible since the connection is over HTTPS. Make sure your certificate is issued from a valid CA. In case the connection is over HTTP, the salt will be of no additional advantage for an attacker in cracking the password hash.