SharePoint Framework – Initial Questions and Answers

It’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?