Yes, your trouble is quite understandable!
First, you should read that "controversial" discussion we had here a few days ago: SharePoint development past and "future": how to keep calm?.
This will give you a history/backgroung about the different dev approaches for SharePoint.
And here's another (more technical) overlook:
- Farm solutions (aka WSP) are packages physically deployed on the SharePoint server. They contain server-side code (C#) that has access to the entire SharePoint server API, meaning it can do a lot of things. A lot of components can be developed with this model: Web parts, event receivers, jobs, workflows, applicative pages, custom field types, custom forms, ... Almost no limit. This also means a "poorly-developed" application can highly impact the server (performance and security risks).
- Sandbox solutions do use the same concepts but are limited, mainly in terms of the API you can use (+ they are resources-throttled by the system). So, it's a kind of subset of farm solutions. But same concepts, etc. They were introduced in SP2010 to allow developers to leverage their farm-solutions knowledge, while allowing some sorts of customizations in cloud-versions of SharePoint.
Then came the "Apps", now called add-ins. They appeared with SP2013, and sandbox were deprecated at the same time.
Add-ins are categorized into different types:
Auto-hosted add-ins: they do not exist anymore, Microsoft stopped them short after SP2013 release. Like a provider-hosted (oAuth) add-in, but with automatic deployment of the "third-party server" into Azure.
But we're now told add-ins are not that great, and a new (!) framework is released by Microsoft these days, called SPFx. For the moment it allows Web parts development only, but no more crappy concepts like app-web, IFrames, or else. But still "all client-side". And a lot of "new" tools, beside Visual Studio, to know about.