Microsoft’s May 4 SharePoint Announcements and Client Side Development Futures

9 minute read

Bill Gates 1981

Image source:

In the beginning, there was Bill, and Bill was good. Bill revolutionized the concept of computing (along with a handful of others). But somewhere along the way, something happened. It’s not clear exactly what. Maybe it was the disaster of Vista. Maybe it was the reign of Ballmer. What it was exactly doesn’t really matter anymore.

Microsoft had become a monolithic, unresponsive thing, with few ways to penetrate its outer ranks. We felt like the chimps at the monolith; we had little control. We didn’t know what Microsoft was anymore.

Image source:

Image source:


Instead of listening to its customers, Microsoft responded with reasons why they knew best, why they would take care of us, even if it didn’t feel like they were taking care of us at all. When we asked for things, we didn’t get them.

I'm sorry, Dave. I'm afraid can't do that.

I’m sorry, Dave. I’m afraid can’t do that. Image source:

We no longer felt a connection with Microsoft. They weren’t watching our back; they weren’t listening to us; they didn’t seem to know what we wanted.

Then something changed. It changed very quickly. None of us really understood what was changing, but we knew it was good.

2001 Stargate

Image source:

Fast forward to today: May 4, 2016. Today’s announcements about SharePoint feel like the culmination of several years of recovery. It feels like things have come around again. Even an old cynic like me can be a Microsoft fan now without regretting it half the time.

Back to the Future

Image source:

Today Jeff Teper and his crew have both turned back time and looked forward to show us a wide vision of the new Microsoft and the #FutureOfSharePoint. It feels fresh; it feels right; it feels like we’re taking a wild ride together.

What were the big stories coming out of today’s event (which fell on a date with a science fiction theme from some other movie)?

Well, to me, the bullet points are:

  • SharePoint is alive and kicking – working out for a long marathon run. More than 200,000 organizations use SharePoint today, and an extraordinary community of more than 50,000 partners and 1 million developers make up a $10 billion solutions ecosystem around SharePoint.
  • The heart of SharePoint is the documents that make our work work. But rather than looking for the files you need, those files will find you. Almost any device – any time.
  • The modern intranet has evolved, and Microsoft is out ahead of it. The new mobile SharePoint app, the new SharePoint home page, and new modern team sites may well be ahead of the market. Many organizations will take years to catch up to what Microsoft has on offer.
  • SharePoint 2016 went to General Availability today, meaning it’s available in most sales channels.  That in itself is news but not unexpected. We heard more today about what SharePoint 2016 really is: a springboard to the future.
  • Security, security, security – This stuff fails to excite me, though I know it is exceedingly important to many.

The SharePoint Framework

It probably won’t surprise you to hear the single most exciting thing to me about today’s announcements is the new SharePoint Framework. One of the best things about this new development option is that it’s additive: it doesn’t replace anything or make anything obsolete. If you’re a server side developer, you’re not losing anything. If you’ve invested in the Add-In model, you can still make hay with that. But if you’re like me and have seen how your clients’ or customers’ faces light up when they see well-built client side functionality, then you can walk with pride now. What the new SharePoint Framework does is elevate JavaScript development on top of SharePoint to a first class citizen.

I was ecstatic to see an early iteration of the SharePoint Framework early this year at a Developer Kitchen (DevKit to insiders) in Redmond. What we put our hands on and built things with was the culmination of a journey I’ve had a lot of fun making. The ability to use JavaScript on top of SharePoint has always been there. What’s happened is that the general view of that approach has gone from ridicule to cautious interest to outright excitement. The SharePoint Framework is the right next step.

At the DevKit, senior members of the SharePoint Product Group – like Vesa Juvonen, Chakkaradeep “Chaks” Chandran, Luca Bandinelli, Dan Kogan, and many more –  worked side by side with us to understand the warts of the new approach, taking away notes on ways to fix it. The DevKit was no holds barred – when they didn’t have an answer, they said so; when they wanted to see if we had better ideas, they asked. They didn’t have all the answers then, and they probably don’t now. I actually think that’s a great thing for a few reasons:

  1. They realize that the Framework will evolve, and they want it to evolve based on our input and feature requests.
  2. Monolithic thinking is gone. The Product Group will be adding new bits and bobs fast.
  3. The Product Group will be using the SharePoint Framework to build out new “experiences” themselves. No more “secret” tools like in the past – they will feel the pain of any issues right along with us.

    In fact, we have built the new experiences for our new mobile app, SharePoint Online and OneDrive for Business, including the new document library and list experiences, using the SharePoint Framework.

  4. The Framework is framework-agnostic. It’s designed to support today’s hot development frameworks like KnockoutJS, AngularJS, and ReactJS. Because it is agnostic, the next shiny new framework that comes along should work just fine, too.

This is going to be the future of SharePoint, without abandoning the past. What it does is legitimize client side development to a level that hasn’t been possible before. We’ll have enterprise-grade tooling to build client side Web Parts and full scale solutions we’ve never had before. Even if you’ve been doing client side development already and have a reliable set of methods (as I do), you’ll appreciate the new focus and will be able to take advantage of it gradually.


We’ll have a page and part model that allows us to “take over” as much as we need. I expect many of you will simply build new client side Web Parts. Others will build full Single Page Applications using the SharePoint Framework. We’ll have several app “shapes” we can use to build even more robust solutions.


As I said, we get new tooling, including a new client side SharePoint Workbench to test our work. The SharePoint Framework will come out of the gate with many of the features we need, with more coming all the time. Remember, the SharePoint Product Group has committed to use the SharePoint Framework to build new features into SharePoint. If it doesn’t work for them – and thus us – they will fix it. We’ve never had that level of development parity before.

We get a canvas that is an evolution of the existing Web Part Zone. Within that canvas, we can take over the entire thing, or just parts of it. (You’ll recognize the canvas from the Delve Blog experience.) Microsoft takes care of the chrome and the services we need to make the components on the canvas sing, including the Data Broker, Caching, Authentication, and Telemetry. That’s right, we can even tap into the same telemetry engine that Microsoft uses so that we can understand how our solutions are being used. We even get responsive design right out of the box from the canvas. We need to be sure to build our stuff correctly to take care of that responsive nature, but we don’t need to set up extra stuff for that responsiveness.

We get a new property panel that’s the evolution of the Tool Pane in existing Web Parts. We can add our own properties and functionality to the property panel based on what we are building – all with commonly known client side tools.

Speaking of tools, there are some pieces of this that many current SharePoint client side devs probably aren’t using. There WILL be a learning curve, but it will be worth it. People who already know how to do Web Development – separate from SharePoint – will probably know at least some of these tools; others are new:

  • Yeoman for initial application setup
  • Visual Studio Code (you can probably insert your favorite IDE here at some point) and later Visual Studio
  • NodeJS to give us a local JavaScript development environment
  • NPM to grab existing open source packages
  • TypeScript to bring real typing to the JavaScript experience. We can also use plain old JavaScript if we’re more comfortable there. (I find that C# developers like TypeScript because it gives them the comfort of “true” classes.)
  • Gulp to build our applications, package them, and deploy them to our own CDNs
  • SharePoint Workbench for testing

SharePoint Framework Tool Chain

From my experience at the DevKit, some of this is still a little rough around the edges, but I expect that it’s becoming more polished on a daily basis. Remember, this isn’t that unfriendly Microsoft – they are shipping improvements weekly based on our input and requests. We’re going to be on this ride together, and it’s going to be really fun.

There’s plenty more to read about the SharePoint Framework and more in the official posts from today’s event on the Office Blog:

As Jeff said in one of the posts coming out of today’s event: The future starts today.

Roads? Where we're going, we don't need roads

Image source:



  1. Great post Marc… I’ll be catching up on all this later today or over the weekend… but it all sounds AWESOME… and exciting… When they released the new Document Library UI on O365 I automatically looked under the covers and the first thing that jumped out was: it is built with KnockoutJS…

    I’m especially interested in finding out more about the Eventing that is shown in the pick you posted above… With “hooks” and most importantly – websockets, that feature alone is going to open up an entire new new class of web-based apps…

    I’m excited and I don’t even do that much SharePoint anymore… This might give me some incentive to really pay more attention to it on the side… :)

    Thanks for posting…


  2. Every part of the SP Framework has me excited, but the real win for me is the SP Workbench. Pair that with gulp to watch for changes/auto refreshing and now I am so much more productive. Modern web dev for SharePoint with modern tooling!

  3. Hi Marc

    Great Post – but as far as the event went I was very disappointed that very little (comparatively) was said about On-Premises SharePoint. This was supposed to be the SP2016 launch and all Jeff and co talked about was what was coming up in SharePoint Online !!!

    They also forgot to mention that the SharePoint part of OfficeDevPnP was coming under the Product Group Wing.



  4. Thanks for the write-up – it was 2.30am local time for me – so I skipped it. The SharePoint Framework sounds great – good for dev’s – that screenshot of the ‘modern toolchain’ is great ! SharePoint dev’s have always suffered for appl-dev – eg. couldn’t do MVC, etc – and bringing it closer to web dev is a great goal. Can’t wait till I can get my customers to start upgrading to SP2016 !

  5. I did my math; Jeff says that every company using SharePoint needs 5 Developers.

    I got most excited about Flow and Power Apps (and still am about PowerBI)
    My predication is that these ‘end-user’ tools will make the ratio drop to 1:4

    Add to that the new JavaScript Fronteers entering the SharePoint Development domain.

    And I wonder what those 400.000 oldskool Developers are going to do in the Future ;-)

    • Danny:

      The richness of some of the new functionality may well reduce the *traditional* developer load. But to me that means we can then focus on the higher value-add kind of development. Rather than needing to wire up basic stuff, we can build more high value, business-focused solutions. That’s better work, IMO, though to some it might just look harder.

      “Enterprises” may need 5+ devs, but smaller shops should be able to get by with 1 or less; there are a lot more small shops.


  6. Great article as usual Marc!

    I am working as front-end developer within a SP2013 on-premise environment. I already use modern js frameworks for developing new applications (angular js for the win). But how will I be able to leverage the Sharepoint Framework on our on-premise 2013 system? Are there any restrictions? Is this only for 2016?

    The possibility of doing local development in real time seems like a giant leap compared to the cumbersome (front-end) development process of which I am used to now.

    Best Regards and greetings from Denmark

    • @Karsten:

      As with most SharePoint improvements and enhancements, we’ll see the SharePoint Framework first in Office 365. The plans don’t seem too firmed up yet, but I would expect that we’ll see the SPX in a SharePoint 2016 feature pack not long after it shows up in Office 365. I’m not sure about the SharePoint 2013 story, but there may well be one.



Have a thought or opinion?