The answer is yes, but not with all situations and not all types of sandbox solutions. SharePoint sandbox solutions were introduced with SharePoint 2010 and provided a mechanism to execute code outside of the ISS worker process. The sandbox solutions do not affect the entire farm, they are installed per site collection and they can be installed by the site collection administrator.

What should you avoid?

Code-based sandbox solutions should be avoided. On SharePoint 2013 they still work, it’s still possible to run them on SharePoint 2016 with a few tricks, but on SharePoint Online they are no longer supported.

Since July 2016 it is no longer possible to activate code-based sandbox solutions on SharePoint online; if you try to do it you will see the message bellow.

Any sandbox solution that uses the server-side API is deprecated since 2014 and should be replaced by the App/Add-in model. This means you no longer can create solutions with:

• Web parts that use sandbox code (this even affects web parts that only use code to store the properties)
• Event Receivers
• Feature Receivers
• Workflows

What can you keep using?

No-code sandbox solutions (NCSS) are still available and were not deprecated by Microsoft. In this type of solutions, you can use declarative markup and JavaScript and they are still valid for:

• Web parts that use only JavaScript
• Site Templates
• Lists
• Custom Actions
• Branding elements (like custom master pages and alternate CSS files)

By default, all sandbox solutions created with Visual Studio templates include a .net assembly which needs to be disabled to get a fully declarative solution.

To disable the assembly in the project with Visual Studio, you can set the property “Include Assembly in the Package” to false, as shown in the image below.

In conclusion

It’s important you know the difference between the two types of Sandbox Solutions. Before starting a new project make sure you will be able to develop the solution only with declarative code and JavaScript.

For complex scenarios, you can use the App/Add-in model and the Office PNP is full of good examples that you can use as a starting point; the PNP repository is kept updated by the community and by Microsoft.

If you are planning to start developing SharePoint solutions in the upcoming months, the SharePoint Framework (SPFx) is the way to go. It didn’t reach the final version yet and is only available for SharePoint Online, but it will be available for SharePoint 2016 during 2017 with a feature pack, although it is not granted that it will be released for SharePoint 2013.

With all supported methods available to build solutions, SharePoint developers are becoming to be more like web developers… this is the time to invest in your future and learn new methods and technologies; you can start by reading this article.

Bellow you have a table with all the development methods that you can and cannot use in 2017 in your SharePoint environments.

* At the time I’m writing this article, Apps/Add-Ins for SharePoint 2016 are not supported, but it's expected to be supported during 2017.