There is a wide range of ways to handle this, starting from the obsolete use of sprites up to fully rigged bodies with inverse kinematics and everything in between.
So, to begin with, you can have textures. Recoil and reload animations are of course 2D animations. They can even be made to look good in a modern setting by having high resolution and using prerendered deph buffer... however that is likely not worth the effort in modern games.
For good while, weapons in first person view where designed only to look good from that first person view (could even have partial geometry and not be fully textured), and if hands where visible, they would be just floating there... in fact, there would be no body in first person view... if you were to hack the camera position you would only see some hands and a gun floating around.
This makes it very easy to animate recoil, reload, even having the weapon lag behind the direction you aim, adding shake and other effects. In fact, good animation will also include walking animation that serve as a form of character expression.
You can figure out if you have no body in a first person shooter game very easily: look down. Where are your feets? Can you find them by turning around? What if you go to a corner? If they are not there, the game does not have a body for the player in first person.
That of course is only true for the player in first person, not for enemies, nor for other players connecting via network or couch multiplayer.
I would suggest to start here if you are working on a single player first person shooter game. Mainly because the situations where you would need to worry about the first person view of another character or the third person view of the player avatar would be scarse.
Next step up is to use the same animations for single player and multiplayer. Old implementations would turn the head of the avatar in first person view invisible to avoid accidental clipping (some would use other tricks like make it small or turn out of view). That is only really needed if the game will run in platform that may not handle face culling properly, however these kind of tricks are still in use when they are needed for only a brief moment, often in cutscene.
Games of this age would often rely on turning the torso of the avatar to follow the cursor. It is a very distintive animation look were the avatar have a fluid walk cycle, their torso turns randomly, and their hands and head are very stiff.
For a multiplayer game, I would suggest to start with this approach, you can then upgrade if you have the means to. Just using the third person animations for first person view will allow you to prototype faster.
Games from this last decade has been able to fluidly animate arms and head to adapt to the direction where the player is pointing. That can be done with a large library of animations※ with parametric adjustments, or with a good inverse kinematic system.
※: keyframe and interpolations, either for rigged skeletons or for morph targets, either recorded from mocap and tweaked, procedurally generated, or designed by animators.
With this approach you can have all the flexibility you want without swapping models depending on whatever or not the character is in first person. However, as you can imagine, it is much more expensive.
It can sound odd given how expensive good inverse kinematic systems can be, however: inverse kinematics is the cheap option. Doing a lot of mocap having distinct and expressive animations for each character is the expensive option... yes, I know you cannot possible record the character aming at every angle, however it is possible to tweak animations in runtime, or, well, if you invested in mocap, you might aswell add inverse kinematics. However, if you only use inverse kinematics then every character will move the same way, with mocap it is possible to do better than that.
About recoil et. al. by using rigged skeletons, the character can always be a physics entity that react to external forces that offset it and springs back to target position dictated by the skeleton. So, you can have actual recoil as an applied force on the body, and your inverse kinematics will solve the rest. Ragdoll also becomes simply disabling those systems instead of switching gears, because the ragdoll is actually always there.
By the way, remember to use placeholders. Is is better that development does not have to wait on assets and animations, and often it is not clear how much polish you will be able to get with whatever budged you have. Also, the quiker you can start testing the better.
