You have now announced that no-code sandbox solutions are supported after all. Then you should logically (and quickly) add support for uploading and activating sandbox solutions in the CSOM.

If you at MS are planning to NOT add that support in the CSOM, you should reconsider because:

1. Customers want to use Save Site As Template. For example, they want to save an OOB team site with some extra lists into a .wsp (=sandbox solution). Then we need to be able to programmatically upload and activate that in a new site collection. Now not possible in the CSOM (except with HTTP Post tricks).

2. Using sandbox solutions allows a faster transformation of farm solutions to CAM for developers, because the features and their SP items (the declarative parts) will be reusable in the sandbox solution.

3. The feature framework is documented and standardized. If you force us partners to drop the feature framework because of this one missing thing in the CSOM, you are in fact forcing each partner to develop their custom substitute for the feature framework. A huge amount work with no tangible benefits to the customer. Yes, we have some code samples for this now on CodePlex, but come on.

4. Sandbox solutions have localization support with feature resx files (which work better than MSDN implies). Even this would have to be built custom.

5. When using the feature framework with sandbox solutions, there is no dependency on XML files on the disk, because it's all in the content database. So what is your reason for not fully supporting no-code sandbox solutions?

All in all, you at MS should not force all SP dev shops to reinvent the feature framework. If you have some issues with the feature framework and sandbox solutions, fix those issues, document the changes, and most importantly add the upload and activation support in the CSOM.

All the things are related to SharePoint Online development:

1. SharePoint CSOM model is too complex for using with leading technologies, such as AngularJS, Backbone, Sencha ExtJS and so on. And there is a lack of documentation for "built-in" CSOM/SharePoint JS API function, for example user name extraction from user field). You have to google a lot to find if anyone has found any solution how to solve it.

2. There are lots of useless JavaScript that does a lot of functionality/processing that is available using pure CSS or native browser functionality (I'm not talking about HTML5 and CSS3 right now). For example - main menu, that has 2 levels, and if You want to expand the 2nd level you have to hover the mouse pointer and that hover event is fired by JavaScript instead of using CSS hover ant the worst thing is that the mentioned JavaScript that fires hover event is built-in the core functionality JavaScript file and You cannot just simply detach JavaScript event listeners by forcing not to load JavaScript file (cause the same file has required for core functions to work).

3. The OData constraints are really complicated, cause they are oriented to CRUD operations (i.e. working with one list/list view), it is really hard to expand list with joined list (using lookup field) to join multiple fields. And there are still problems with responsive design and user experience, You just cannot mate SharePoint design whatever You want - I always have to keep in mind all the masterpage and placeholders constraints (like search control delegate placeholder and so on).

4. There are also a lot of JavaScript solutions, that is oriented to cross browser functionality, but usually those functions were oriented to IE8, which nowadays is not supported anymore, so I would suggest/recommend using simple and native JavaScript functions, like el.querySelector(selector) and so one.

5. Another thing is Responsive SharePoint design stuff and related things. SharePoint Document Object Model is too complex - I would recommend simplifying it and leave SharePoint Designer, otherwise lots of User Experience professional developer would choose another platform.

6. Problems with anonymous authentication and list view pagination. Pagination does not work, because it requires some extra permission that prevents from functioning.

7. SharePoint Online API is really complicated: the functionality for Event Receivers, Time Jobs, WebParts and so one creates really big challenge, which causes System Architects to consider other platforms and so on. For example: if You have to create solution for On Premises solution it would take few months of development, but if You would have to do the same functionality on SharePoint Online – some of the solutions event Would be almost impossible or would be much higher cost (not only cost of money), but lost of performance and other issues and some of the functions would be almost impossible (like incoming emails and so one – consider scenarios where You can’t use 3rd side solutions or Hybrid architectures).

Enhance the Office JS API to allow apps to read the cell address of selected cells so a better experience can be provided for users who need to see cell references made via their app. Top priority items should include:
1. The ability to read the cell address of cells a user has selected when using addFromPromptAsync pop up. (e.g. Sheet1!$A$1). This is effectively the same address which shows within the addFromPromptAsync textbox currently.
2. Ability to read cell references of any selected cell/cell range.

This enhancement will be useful as currently apps can create a binding to a selection via the addFromPromptAsync pop up form however apps cannot show users where they previously bound to. A common use case of where this employed is where a user needs an app to keep track of certain cells to perform calculations based on their values but the user themselves will forget where those cells are. If apps can access the cell references then they can tell users where their previously bound cells are.

I have this scenario where users are performing reporting and their reporting parameters are inside Excel cells. When a single report can have multiple parameters, my users are finding it difficult to remember where they placed their bound parameters.

I work in the Real World with SharePoint 2013 daily. You could call me a "PowerUser" and "FrontEnd SharePoint Programmer" Can you PLEASE offer (Starting with SharePoint 2016) A "SharePoint Certification Path that will actually be worth something? In large corporations only a very, very few will be allowed to use PowerShell, and set up Site Collections, and design server farms... You need SharePoint Certifications for the person who uses it in the office daily a "power user cert", and you need some that certify you on programming SharePoint using (JavaScript, HTML5, CSS3, jQuery, BootStrap, etc...) for those of us who have to "customize" SharePoint for apps for dept level etc.. Please consider re-vamping your SharePoint Cert offerings in this direction. Thanks!!