 My name is Paul Papanik-Stork. I'm the owner and principal architect at Don't Papanik Consulting. I specialize primarily in consulting on Office 365, SharePoint, SharePoint Online, and Dynamics CRM. So I've been working with SharePoint since 2004. We won't count in the predecessor products. I work all the way back to site server, commerce server, the first edition. But I've been working with SharePoint since SharePoint 2003, and I've always kind of straddled the fence. So I've been both an IT pro and a dev all these years and do a little bit of both. 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. And so 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. 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-Sharp and all of that. And this comes a little bit closer with TypeScript, 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. And 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 an arrangement. It doesn't really work if you're working with a team or working in an enterprise kind of an environment. And SharePoint Framework is going to 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. 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 a lot 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 really enjoy using that part of the framework. The piece that I'd really like to see them add is something that plugs into the traditional tooling. Not so much that it would be nice if they could develop something where you could actually write in C-sharp 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. And I know there's a community effort at this point to do some stuff for Visual Studio, but it would be nice if that was officially supported. So the one thing I would change is essentially what I just said. I'd really like to see direct Visual Studio support for the ability. Yo and Gulp and all of the new tool chain is just, it's 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. And it's not that they're bad tools, but as soon as the first time that I looked at Yo 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. I think the biggest challenge, and this has been for me, and I think it is going to 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 going to go through a fairly steep learning curve already just to get off of server side languages and onto TypeScript and then to throw a whole new IDE, a whole new development tool chain at them just really makes it insurmountable. And a lot of people just don't go there because it's just too much to take in. 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 going to 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 at remote event receivers, some better story to tie into server side code in remote systems like provider hosted apps. That's where I think you're going to 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 soon they not go. So my advice to a developer who's just starting in, and this is assuming that you're a developer coming kind of from my background of server side development, is I would really encourage you to stick to learning at first using just straight JavaScript without any kind of an additional framework like knock out 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 knock out or one of the other frameworks to get a lot of additional kind of stuff. The other thing that I would really encourage and this kind of 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 kind of 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 got to be there for some reason and so you've got to 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.