I was one of the privileged few developers who were invited to Microsoft's Dev Kitchen for SharePoint and played with an early version of the SharePoint Framework. Like many others, I am excited about what is coming. And like many others, I was a bit disappointed that the online event did not spend much time on the developer story. (I think they ran long on some of the earlier items and cut the developer demo to ensure they ended on time.) I want to take a few minutes to explain my thinking in regards to the new SharePoint Framework and how we arrived here.
There is a lot written about the framework, but since we don't have anything to look at just yet I thought it may be helpful to put it into context with what we've seen before. Yes, there are shiny new things that are exciting. But these things need to co-exist with the core of SharePoint: web pages that present lists of lists. Lists (and document libraries) are the things that make SharePoint powerful many organizations. They allow the storage and classification of mostly unstructured data, that is relevant to teams or groups of individuals. The ad-hoc nature of many of these lists is handled by SharePoint's user interface in a way that users understand. They get their job done and move on.
SharePoint pages have evolved from "portals" that had "webparts." These parts of the page were considered a window to another system and were quickly adopted. SharePoint naturally provided web parts that were a view to the lists/libraries in the site. Over time, the number of web parts grew to cover the many different capabilities of SharePoint and further by ISVs and corporate developers to include external systems. With the proliferation of web parts, a catalog was established to help users discover and install them. It was, in a way, the first App Store.
All of the development frameworks since: the Sandbox, the App (Add-in) Model and the new Framework, were not really revisions to this web part/catalog model. The Sandbox and App Model were created in response to the need for better code security in the SPO service. Naturally, us developers encountered barriers to what we wanted, so we found another way. And most SharePoint users don't want to focus on security, they just want to do their job. And so, the Script Editor Web Part became the extensibility point of choice! In casual conversations with other MVPs and engineers, I learned that the most popular web part used in SPO is the Script Editor Web Part (SEWP). It is being used to provide functionality to a page without the restrictions of the App Model IFrame. To their credit, Microsoft has noticed this (and listened to us tell them at various events!) and has built something to address this usage pattern.
This new base web part class is (in the early previews, it is called the ClientSideWebPart) an evolution of the web part class we know and love. It provides for Properties, allowing us to adjust the rendering based on user input. The Properties are set using a PropertyPane, which has a default rendering that we can customize if we which. The ClientSideWebPart can be added to the Web Part Gallery, making them discoverable to users. The other big part of the new Framework is the Canvas. The canvas is analogous to Web Part Zones. The Canvas will use the Web Part Gallery as part of its content adding functionality, thus closing the loop.
So, while the SharePoint Framework is new, the concepts have been around for quite a while. Microsoft has said that nothing we have done is going away, but the new implementation is what is driving the innovations that were announced: the responsive web design and mobile capabilities. I'm sure there are gaps to fill (wide-scale deployment and the ISV/Store aspects to name a few) and the key is whether Microsoft will fill them or leave us wanting more.