I strongly suggest that your movement has nothing to do with rendering.

I usually have one function called logic, and that function basically calls all the objects' update methods, and gives them the time passed. The player class, then, has an input listener, and in its function it checks which keys pressed, and depending on the time, reacts accordingly.

if (player.input.right)
{
    velocity.x = const;
}

//Do some physics.

position.x += velocity.x * dt

I call this logic function ~30 times per second, so it's responsive enough. As for the netcode, it's best to record input and only send that to the server. The server only sends back the difference in the game state since the last message (see: Backbone.js diff).

Edit: there's a bug in your code.

At the new Date().getTime() part (you can write it like that, no need for extra parenthesis).

1. Not all your clients are going to have the same time.
2. One could easily change the date values being sent to your server.

So, that value isn't very reliable (in case you plan to use it for something important), you better calculate it on the server side.

Never, ever trust the client with anything other than their current state of input.

I strongly suggest that your movement has nothing to do with rendering.

I usually have one function called logic, and that function basically calls all the objects' update methods, and gives them the time passed. The player class, then, has an input listener, and in its function it checks which keys pressed, and depending on the time, reacts accordingly.

if (player.input.right)
{
    velocity.x = const;
}

//Do some physics.

position.x += velocity.x * dt

I call this logic function ~30 times per second, so it's responsive enough. As for the netcode, it's best to record input and only send that to the server. The server only sends back the difference in the game state since the last message (see: Backbone.js diff).