The Authorization Code grant provides additional security, but it only works when you have a web server requesting the protected resources. Since the web server can store the access token, you run less risk of the access token being exposed to the Internet, and you can issue a token that lasts a long time. And since the web server is trusted, it can be given a "refresh token", so it can get a new access token when the old one expires.
But -- and this is a point that's easy to miss -- the security of the Authorization code flow works only if the web server is protected with a session, which is established with user authentication (login). Without a session, an untrusted user could just make requests to the web server, using the client_id, and it would be the same as if the user had the access token. Adding a session means that only an authenticated user can access the protected resources. The client_id is just the "identity" of the JS webapp, not authentication of said webapp.
It also means that you can end the session before the OAuth token expires. There's no standard way to invalidate an access token. But if your session expires, the access token is useless, since nobody knows it but the web server. If an untrusted user gained access to your session key, they would only be able to access the protected resources for as long as the session was valid.
If there's no web server, you have to use the Implicit grant. But this means that the access token is exposed to the Internet. If an untrusted user gains access to it, they can use it until it expires. This means they'll have access to it for longer than with an Authorization Code grant. So you may want to consider making the token expire sooner, and avoid giving access to more sensitive resources.