The SharePoint Framework (SPFx) Is Here!

There’s no official blog post to point to yet (I’ll add it when it appears later), but today is a big day for SharePoint! The new SharePoint Framework is ready for its developer preview.

UPDATE: Here’s the REAL post.

SPFx Workbench To Do Web Part

I’ve been watching the Twitter feed from SharePoint Fest Seattle, and Jeff Teper (@jeffteper) announced the preview in his keynote – or someone else did when they were talking.

In case you missed it, the SharePoint Framework was announced publicly at the big May 4 The Future of SharePoint event in San Francisco.

When it’s available, you will see it on Github/SharePoint:

SharePoint on Github

In case you get confused by all the new terminology for “software release” these days, I’d call the developer preview a pre-alpha. The Microsoft folks would say it’s more solid than that, but they do say that things may change, you should not use it in production (and truthfully, you can’t unless your Office 365 tenant supports it), etc. In other words, it’s ready, but not THAT ready.

As someone who can realistically claim to be one of the early client side developers for SharePoint, I’m really excited about the possibilities here. When we build client side code, we’re giving users of SharePoint a much better user experience (UX) – if we do things right. Rather than the old school “conversation” with the server – and the attendant postbacks – we bring the responsiveness right behind the glass of their device. The UX becomes far more intimate. People are used to this sort of UX from everywhere but classic SharePoint. The consumer Web and most other Web-based enterprise products have been there for a while.

If you’re coming from server side development, I think this Brave New World is going to feel pretty weird for you. What I’d ask is that you give the SPFx more than one chance. If you dig into it today and find things confusing, or the documentation a bit light, or the tooling pretty weird, or the examples not quite up to snuff, stick with it. These are early days.

This is the first time Microsoft has put a development model out there and agreed that it will be how THEY build things in the future. No chicanery; no trickery. In fact, they claim that many of the new “experiences” we are seeing are built with the SharePoint Framework. I have some doubts that they are playing by the rules on this quite yet – the SPFx seems a bit lean to get to the types of “experiences” they are giving us – but they will abide by this pact.

Those of us who were able to attend one of the the Developer Kitchens earlier this year and play with the early versions of the SPFx came away energized and impressed. Not ecstatic and blissful – most of us a realists after all – but energized and impressed. There are many holes to fill and we will encounter bumps in the road. But given the open source foundations of the SPFx, we can help drive this Brave New World forward with Microsoft. Now that’s a new thing, for sure.


If you’d like to know more about the SharePoint Framework, check out my previous posts:


SharePoint Framework – Initial Questions and Answers

The Future of SharePoint - May 4It’s been almost a week since the #FutureOfSharePoint event in San Francisco, and as usual, there are a lot of questions flying around. Wictor Wilen has started a post SharePoint Framework – Initial Questions and Answers and I thought I’d start my own. I’m not going to rehash Wictor’s answers, and will instead focus on the questions that I’m getting. Some questions have come to me publicly (perhaps as comments on my previous post Microsoft’s May 4 SharePoint Announcements and Client Side Development Future), some privately, or I’ve seen them in private forums. I’ll keep the latter two anonymous, of course.

As with Wictor’s post, this is entirely unofficial and will contain some of my opinions, as well as some things that may turn out to be rumors. I have no intention of misleading anyone, but a lot of things are in flux as the Product Group is working to finalize the first release of the SharePoint Framework (SPX). I also have no intention of pandering to Microsoft here. Some of the answers may not be exactly what we’d like and I’ll say so if I feel that’s the case. No crying and try to keep the teeth-gnashing to a minimum.

If you have questions, feel free to add them in the comments here (or on Wictor’s post if you’d like his take). I’ll add new FAQs as they seem useful.

Is the SharePoint Framework “Yet Another Development Model”?

I don’t see it as such. The SharePoint Framework is a new development option. Nothing else has been deprecated and the SPX doesn’t replace anything per se. There are times when it will be the right way to build things and other times when the other development models are more appropriate.

Can’t I just do this stuff in a Content Editor Web Part?

Absolutely, and many of us have been doing so for years. (I’ve been building things with KnockoutJS and AngularJS, even in SharePoint 2007!) Each of us has our own way of making this all work.

What the SPX will give us that’s new and good is:

  • Isolation between client side Web Parts. We’ll be able to run different frameworks on the same page without any cross- Web Part “pollution”.
  • We’ll all be using the same approach and we can improve upon it as a community.
  • The SharePoint Product Group is going to use the SPX to build their “experiences”. That means they will feel the same pain we do if it doesn’t work well; no more pulling rabbits out of hats for them by using secret tricks.

What versions of SharePoint will get the SharePoint Framework?

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.

Won’t this just be replaced by another model in a few years?

Everything is replaced sooner or later. However, the SharePoint Framework will bring SharePoint development into the mainstream, allowing us to use the tools most Web developers have been using for years now. As goes the Web, so shall we go. We can “chase the shiny penny” of new tools and the SPX ought to support us in doing that, within reason. I expect the SPX will evolve rather than being replaced.

What do I need to do to get up to speed?

JavaScript. If you learn JavaScript, you’ll be laying the foundation of using the SharePoint Framework. No, JavaScript is not a baby tool, or a joke, or whatever other disparaging thing you’ve heard. People outside the SharePoint world have know that for years now. Get over it. See my comments in this video a few of us MVPs made up in Montreal at Sharegate: MVP Thoughts: What Should SharePoint Developers Focus on.

What about jsLink?

(See Marcel’s comment below for the question) I don’t recall hearing anything specific about this at the Dev Kitchen, but I may have. To me, jsLink and some of the other client side rendering (CSR) techniques were almost stop-gap measures. They moved people closer to client side development, but did it in often clunky ways. (Try editing JavaScript that has to be in a comment – no fun!) Using jsLink will still be a valid approach with the existing .NET style Web Parts, but I expect many people will decide to go all the way to the client side, calling SharePoint’s Web Services themselves instead. It gives you more control over time, and will become de rigeur, IMO.

SharePoint’s Future?

Ray Ban Shades