Webinar recording
Summary
This is one installment in our series “In Own Words” by Voitanos asking experienced SharePoint developers to share their thoughts on the new development model for SharePoint - the SharePoint Framework . In this series, we ask each person a series of questions and let them share their thoughts.
Paul Stork
My name is Paul Papanek Stork. I’m the owner and principle architect at Don’t PaPanic Consulting. I specialize primarily in consulting on Office 365, SharePoint, SharePoint online and Dynamics CRM.
What’s your background as a SharePoint developer?
So, I’ve been working with SharePoint since 2004. We won’t count in the predecessor products… I went all the way back to Site Server, Commerce Server, the first edition! Been working with SharePoint since SharePoint 2003 and I’ve always kinda straddled the fence, so I’ve been both an IT pro and a “dev” all these years and do a little bit of both.
How much time have you spent with the SharePoint Framework?
So, I haven’t spent as much time as I would like. Most of the work that I do nowadays is more architecture and governance and best practices. But, in order to do things like migrations from older systems to newer systems you have to keep up to date with how you do customizations and how you do development work in the new environments. I’ve been playing around with the SharePoint framework since it came out in beta about a year ago … Haven’t actually done a full project on it yet, so it’s all been playing with it in the lab, just trying to learn how it works.
What is your impression of SharePoint Framework today?
So, I really think this is probably one of the spots where Microsoft is starting to get the development story right. Most of my background is in the server side, coding section of the world and so I’ve spent a lot of time working with C# and all of that. This comes a little bit closer with TypSscript, a little bit more familiar territory than some of the other stuff. I think also it’s a nice replacement. What I’ve tended to see in a lot of my clients is instead of using add-ins where you are kind of segregated off into your own little piece, they’ve started moving more in the direction of using JavaScript Injection using content editor web parts to put things on the page.
In an enterprise environment, that just really doesn’t scale as a development effort. It works, but it works in a one-off kind of arrangement. It doesn’t really work if you’re working with a team or working in an enterprise kind of environment. SharePoint Framework is gonna provide the ability to actually manipulate the document object model directly on the page, access it with direct JavaScript, and do a lot of stuff that you need to be able to do within the context of the site, without having to go to something that’s not really long-term supportable, like, inserting script into a content editor web part on the page.
What is your impression of the SharePoint Framework roadmap?
So, I like the Roadmap. I’m really looking forward to the release of what the Roadmap calls Feature Pack 2 for on-premises. I think that’s one of the spots where things are really missing at this point. SharePoint Framework has been out in beta and now released for over a year, and there still isn’t even a preview beta for on-premise that I’m aware of. I do a lot of work in the hybrid side of the world and having a different development story for on-premises versus in the cloud is a real problem in a hybrid kind of environment. So I’m really looking forward to the release of that particular piece. Also, looking forward to having the extensions go full term. A lot of the work that I have done in the past in server side development, leaned in the direction of event receivers and really looking forward to being able to do some more things with things like web hooks and so forth, using extensions to get into that kind of Framework.
What is your favorite part of the SharePoint Framework?
So I would say my favorite part of the Framework is probably … I gotta list two things. One, I really am enjoying learning TypeScript. I’ve played around with JavaScript since they started to use it for client-side development in SharePoint. And for the most part I’ve just found it a hard go. I come out of a background with strongly-typed languages and object-oriented procedures and moving to TypeScript just feels more familiar to the object orientation and the strongly-typed model and so forth than JavaScript has ever felt. The other piece that I really like is the ability to implement and manipulate directly the Document Object Model. The ability to actually work directly with the HTML, I think, is a really strong piece of this and I really enjoy using that part of the Framework.
What is the one thing you would add to the SharePoint Framework?
So you’ll hear this again when we get to talking about if you have any complaints about it. The piece I’d really like to see them add is something that plugs into the traditional tooling. Not so much that … it’d be nice if they could develop something where you could actually write in C# and have it translate, but I won’t hold my breath for that. But at least the ability to work directly in Visual Studio and have it compile and deploy from there instead of having to go to a completely different tool chain. I know there is a community effort at this point to do some stuff for Visual Studio, but it would be nice if that was officially supported.
What is the one thing you would change to SharePoint Framework?
So the one thing I would change is essentially what I just said, I’d really like to see direct Visual Studio’s support for the ability … Yeo and Gulp and all of the new tool chain is just … It’s just too much of a learning curve. It’s bad enough that you’re having to learn a whole new language with TypeScript, but then to throw in a whole new set of tools … It’s not that they’re bad tools, but the first time that I looked at Yeo and I saw that little face sticking out at me from the character arrangement, I’m going wait, when did we go back to the mainframe world, because that’s the way we used to do things. It would be nice to have something that was implemented in an IDE instead of being completely command line driven.
What is the biggest challenge with SharePoint Framework?
I think the biggest challenge and this has been for me and I think it is gonna be the biggest challenge for most developers, is the tool chain. It’s just a very, very steep learning curve. Developers, especially traditional developers, are gonna go through a fairly steep learning curve already just to get off of server side languages and on to TypeScript and then to throw a whole new development tool chain at them, just really makes it insurmountable. A lot of people just don’t go there because it’s just too much to take in.
Predict the future - Where do you see the SharePoint Framework Going?
So, I have mixed feelings about the future of SharePoint Framework. I do think it’s going to stick around. I think it is headed in the right direction. One of the pieces that I would really encourage Microsoft to look at is moving it out of the realm of just doing document object model manipulation of web parts and being able to do something that can manipulate the entire page. I don’t think you’re going to see that, but I do think you’re gonna see a lot of additional extensions to extend the tooling out to other things, like the extensions that are currently in preview, something to get it remote, event receivers, some better story to tie into server side code and remote systems, like provider hosted apps. That’s where I think you’re gonna see it headed. I think they’re going to avoid going to manipulation of the full page object model, which is kind of a shame, but that would lead people to start doing complete rewrites of the look and feel of the page. Which is where I think a lot of people want to go and where Microsoft would just as soon they not go.
Do you have any Advice or Words of Wisdom?
So my advice to a developer who’s just starting in, and this is assuming that you’re a developer coming kinda from my background of server side development, is I would really encourage you to stick to learning it first using just straight JavaScript, without any kind of additional framework like Knockout or React or anything like that on top of it because I think that just adds to the amount that you have to learn and there’s enough of a steep learning curve already.
Once you’ve learned to do the SharePoint Framework with just pure JavaScript, then you can start throwing in the bells and whistles of adding React or Knockout or one of the other frameworks to get a lot of additional kinds of stuff. The other thing that I would really encourage, and this kinda goes back to the old days when I first started teaching SharePoint development, back when we first started teaching people how to write web parts, Microsoft came up with these wizard driven systems, which usually worked, the problem was that they were kinda black boxes. And if it worked, it worked and if it didn’t work, because people never dug into the black box and figured out where the components really resided and what they did, they didn’t know how to troubleshoot things. So, I would really recommend people to take that project template that Yeoman generates and make sure that you go through that entire list of files and try and figure out what each of those files is there for because there’s a pile of files that are in that project that nobody ever talks about, nobody ever touches, but they’ve gotta be there for some reason. And so you’ve gotta get behind the scenes and figure out how the black box is put together or when something doesn’t work, you’ll never be able to troubleshoot it.