I am currently trying to learn how to build apps to add into SharePoint to extend its functionality and after a lot of confusion and reading all about SharePoint Add-ins I was met with this on the GitHub page:
SharePoint add-in model is considered as a legacy option for extending SharePoint user interface. Please see SharePoint Framework documentation and the SharePoint Framework samples for the future proven option to extend SharePoint Online. Possible backend services should be using Azure Active Directly based registration and related app models.
As well as this after going into the SharePoint framework I found this:
Historically, developers created web parts as full trust C# assemblies that were installed on the cloud servers.
However, current development models usually involve JavaScript running in a browser making REST API calls to the SharePoint and Microsoft 365 back-end workloads. C# assemblies don’t work in this world. Developers needed a new development model.
The SharePoint Framework is the next evolution in SharePoint development.
So my question is, Why don't C# assemblies work in that world and As a newbie into SharePoint development should I focus purely on SharePoint Framework?
I tried googling my question, but I am a bit lost/Overwhelmed with the information and not sure what is and what is not Legacy or what is a good practice. I did read this similar post from 2 years ago but I'm still a little confused and curious if anything has changed in those 2 years.
I've been developing solutions for SharePoint for 9 years now, beginning with server solutions on SharePoint 2010 and SharePoint 2013, with a major turn 5 years ago on full SharePoint Online with the SharePoint Framework (SPFx).
Add-Ins were created for SharePoint 2013 to isolate (better scope) developments as they were able to live independently from the site on which they were deployed. They were also created alongside the SharePoint App Store to give developers a marketplace on which they can upload their developments (and ultimately make money). As people were used to develop using serverside technology (C# and ASP.Net), Add-Ins were the perfect solution to allow server code while opening companies servers to external code.
Since SharePoint Online, and the creation of the modern experience (complete overhaul of pages from full ASP.net to ReactJS), a new way to develop was introduced: SharePoint Framework. It is full frontend (compiles into HTML/JS/CSS and declarative files usual to sharepoint solutions for provisioning, ...) and replaces indeed the SharePoint Add-In Framework, making the major turn of frontend development.
While I know some companies still use and create SharePoint Add-Ins, I believe most of them do so for one of the two following reasons:
As a new developer, the only reason you need to consider is which farms will you develop for. If you say SharePoint Online, my takeaway is to go directly for the SharePoint Framework.
Another interesting consideration would be the love Microsoft gives to both. While Add-Ins are completely forgotten and never moving, the SharePoint Framework is intended to fly alongside Teams and now Viva. It is now able to carry solutions for SharePoint, Outlook, Teams, Viva and I believe the remaining of the M365 Office (Word/Excel/PowerPoint) (to be verified).
Please note that some applications (consuming external services, backend process, planned tasks, event receivers, ...) will require the use of a backend, which may take the form of an Azure Web App or Azure Function (is you want to stay full Microsoft, but nobody forces you).
To finally answer your question
Why don't C# assemblies work in that world and As a newbie into sharepoint development should I focus purely on Sharepoint Framework?
You may develop interfaces generated in C#, hosted on your server or in the cloud, and use SPFx or the Add-In framework to package your solutions and deploy them on SharePoint. However, the Add-In framework was created for a specific reason, and then the SPFx was created for todays structure (cloud/frontend) and allows for more diverse deployment options, more integrated to the M365 eco-system. I believe this is were you should invest your time and effort. For the C#/React/Frontend subject, while I'm not going to raise this debate here, I will just say that Microsoft made it easier to frontend (especially React) using the SPFx which is the most supported/detailed/documented solution.