I've had a lot of games where I tried implementing a 'vehicle'-type of movement.
My approach to designing this is not to consider the end-position, but rather these 2 key elements:
- Direction (angle)
Your input should always modify one of the two (either a speed increase/decrease, otherwise known as acceleration/deceleration, or an angle modification by a specific amount of degrees).
As a general rule, I find radians to be more efficient than actual degrees for this as most of the APIs have worked with had much simpler ways of handling this, but I'm not foreign to building such a system from scratch on HTML5 notably, so everything is possible, if you remember your trigonometry!
So you should essentially "listen" for these input, knowing that with every game tick, you're going to modify the position of the ship or vehicle based on what you currently know (direction/speed) regardless of everything else.
In an environment where you don't control the ship via WASD, and would rather prefer using waypoints (click where you need to go, such as in an RTS), the same heuristics will apply, the only difference is that the "AI" will determine its own rotation and speed modifications.
This can be achieved by using a targetRotation variable which stores the direction you're trying to go, and determining what is the fastest rotation to achieve this (not as straightforward as I make it sound as all angle representations have a 'dead point' where it takes a little know-how to find the easiest path when wrapping over 0 or the likes).
As for suggestions on improving your current script, I would question the capitalization of your variables, but they appear to be consistent at least. But capitalizing all but the first word is good practice for readability (I almost missed the 'T' in shipTSpeed).