 I'm Mark Anderson. I'm a SharePoint consultant and I do other stuff, but pretty much everything I do is SharePoint. So I say it that way. I have my own little company outside Boston with Julie Turner called Sympraxis Consulting. Well, it's a little varied, right? I never did the server-side stuff. And that was actually sort of an election on my part. I saw some interesting things that I could do in other ways. Plus I had some clients where deploying stuff to the server was just never going to happen. And so we came up with other ways to do things. And that's where the development on the client side came from doing things like data view web parts, which actually execute on the server, but we can work on from the client. So that whole sort of set of tool usage came from necessity as much as anything else. Plus I really liked the way we could, you know, make some really useful stuff that was right in front of people. Well, I'll be honest. I don't use it really at all. The good thing is I went to the first developer kitchen, which we do talk about these things, even though we don't talk about what happens in them necessarily. So I got to see some of the early versions of things, got to understand what the tooling was, got to understand, you know, sort of how it was going to be built, which changed some of my approaches to things. And then I was just at a dev kitchen where you also were. You'll cut that out. And so I've seen where it is. What I struggle with is a use case for it in the work that I do with my clients. You know, I tend to build full page applications or at least applications that take over the majority of the page. So a web part itself doesn't really have much interest to me unless that web part can expand and take up a lot more space. So we're doing a lot of things that will be able to be turned into SPFX things later. We're developing toward that, but we're not actually using the SPFX to put stuff into client instances. I think it's an excellent starting point. You know, I think SPFX is the right answer. I think that Microsoft is finally catching up to a way of development that the rest of the world has been doing for quite some time. So I'm incredibly bullish on it, you know, which sounds sort of silly given that I just said that I don't use it. But I'm incredibly bullish on the way they're approaching developing with SharePoint now. I think this is the right way to go. I think it provides a better UX. I think it's going to change the way we think about building solutions for the better for end users, which is actually the point. It's not about the developers. So I think it's an awesome thing. I'd love to see it keep going. You know, I want to see where it heads. It's a version one. Version ones don't have to be bad and this one isn't, but it only does a certain amount of things and, you know, we'll see more. I think the roadmap is good in that it's hitting the things that most people want. I think that they're doing a good job of prioritizing use cases and understanding what people will use next. So that's good. I also think in some cases they're sort of missing the boat. You know, give us something for a full page app. That to me should have been part of the first release. I think probably there's some confusion about what that even means and we'll get that straightened out. So, you know, I think that what's there is great. But again, we're sort of, let's keep going. Let's keep going. It's interesting. It's not a development answer. We can do better stuff for end users. We can put that functionality right on the glass. I talk about this a lot at sessions at conferences. The reason that client-side development is good is not some sort of, you know, what language you use, prejudice or religion on my part. I think we can build better solutions. I think that SharePoint developers are going to have to learn how to build those better UXs. I think there's a lot of catch up there from, not the post-back world, but, you know, we're sort of bridging now between the post-back world and the, it's running as JavaScript in the browser world and the way you interact with a user and what you can let users do and what kinds of things you can develop is very different than what you could do without thinking that way. So I think that it's not just a tooling challenge. I think it's a, you know, understanding what UX means. You know, what it really means, not the definition of it and thinking about how you can get closer to your users and use that tooling that's in SPFX to actually build better stuff because I really think that's possible. I think it's, right now I call it overwrought. It's very complicated to look at and to use. I'd love to see something like an SPFX light and I don't know what that exactly looks like. I don't know if it takes TypeScript out or it makes the build process more straightforward or whatever but I talk a lot about the spectrum of people who build stuff in SharePoint. Everything from, you know, somebody who's just adding columns to a list to hardcore server developers. There's a lot of room in between and I think that SPFX can help address the needs of some of the people in the middle. Right now I think it's really catering to the server-side developers coming down from the server. That's a good strategic move. I think that that's what SharePoint, that's what Microsoft needed to do in order to make this shift. But at the same time you've got people sort of coming up from the JavaScript world or coming from, you know, sort of the power user, citizen developer. You know, we've got lots of words we like to kick around for this stuff and we need to think about how to help them accomplish what they do too. So I'm hoping that there's some way to sort of use this technology stack to bridge that in the middle. Having that single page app, sort of, I just want to drop some script into a page idea will help, but we need to keep that surface wide for those citizen developers or whoever we want to call them. We need to keep that surface as broad as possible so that they can continue to do the good stuff that they've been doing to make this platform successful. Well, it sort of follows from what I said about, you know, SPFX Lite. I think that the learning curve to get to the way that SPFX is constructed right now it's not insurmountable, but you really do have to work. Anytime you start with a new paradigm, you've got some climbing to do. And I think that a lot of people coming from the traditional SharePoint development world are going to struggle with that. Good training is always a good thing. But training only gets you so far. You really have to shift your mindset. The Malcolm Gladwells 10,000 hours doesn't happen without 10,000 hours passing, right? We can't get to a tipping point until we tip. So I think that we need to think about ways to socialize and facilitate that learning curve as fast as possible. This stuff is not going away. This is not, you know, even if they decide SPFX sucks, let's do the 17th development model. It's going to be client-side. I'll say that flat out. I don't think they'll ever go back to a server-side model on Office 365 or SharePoint. I just don't think it'll ever happen. So we have to make that shift. We have to get everyone along on that train. I think one of the biggest challenges that I hear, especially talking to traditional devs, is this fear of what happens on a client and confusion about how JavaScript works and what actually happens in a browser when you're using an application that's built on this stuff. I talked to very smart people, people like you, and we have discussions about what happens when a JS file is cached or it's not cached or we make a change and it doesn't load in the page. You and I are having a discussion on one level, but then I have a discussion with somebody else and there's a lot of confusion. There's a lot of sort of misunderstanding and it's not stupidity or anything. It's just a lack of experience working with this stuff. I've learned a lot of this stuff because stuff doesn't work and I have to figure out why. So I've gone through that shadow of the valley of death enough times that I don't get as angry and I think we've got to get a lot of people through that and it's going to take a while. Well, I do think that client-side development for SharePoint is here to stay. That's not going away. We can't read tea leaves the way we used to be able to. Roadmaps used to be secret. Now they're not secret, but they don't go out as far. So we really can't predict. I'd love to get say, oh, I understand where they'll be in five years, but good Lord, nobody does, right? They don't know. Microsoft doesn't know. What I think we will see is more and more functionality being brought into this development method. More and more capabilities. I'm hoping that we start to see some third-party libraries showing up. I built that SP Services Library to fill a gap that I saw and some tooling that I found useful. I think we'll see the same thing with SPFX. We'll see a good ecosystem build up around it. I think there's much more potential for that. So I think we should all be thinking about the fact that it's not Microsoft only here. We can see what they're doing. We can augment it. We have to work with them to do things like, can you open source the generator so that we can actually see what we can add to it? Can we come up with a plug-and-play or an extensibility model for, let's add that angular yeoman template. Let's add the view yeoman template, whatever. Let's help them understand that we need to sort of step to the side of their React stuff and be able to build well with whatever frameworks we want and potentially in different tools than Visual Studio Co. I've tried to do a little bit of SharePoint framework stuff with WebStorm and it actually sort of works. But I think we'd like to see all of that kind of stuff broaden out and I think that's what we'll see over the next year or two. Remember there are a couple of goals here. One is to bring the server-side developers into the client-side development world. Another is to bring a whole world of developers who've been doing this stuff for a long time into SharePoint without saying, oh my God, what is this mess? And we need to make sure that the mess isn't there when we bring them. And I think that so all of those pieces together I'm hoping will come up with a, the story will just get better and better. I think one exciting thing here is that a lot of people have client-side solutions in their SharePoint environments already, whether they know it or not. You know, we've got these power users, citizen developers, some of them are copying from blogs like mine. Some of them are really writing code that turns into useful solutions. So if we can start to find those solutions, not to beat these people up, but to enable them more and understand how they're building things and help them understand how to move toward this more industrial strength way of developing with the SharePoint framework. I'm not saying that we're not going to get power users to use the SharePoint framework. That's probably not the right idea. But if we can think about how we help those people get to where they can and then pick this up, pick up what they're doing as, I hate to term professional developers, but people who do this stuff all day long and take them to the right endpoint. I actually asked Jeff Teeper a couple days ago about, you know, what's the story with citizen developers with this. And I was so happy to hear him say that he wants to see the same thing. He wants to see, you know, those citizen developers be able to go to an IT-like organization and get more assistance. To me, that's a huge problem. So I think the really cool thing is that if we can help people, and this is part of the community thing, if we can help people to think about developing in a way that lets them get toward the SPFX way of doing things, then we can start bundling and packaging and deploying stuff that's already there in a more robust way so that we have better solutions that can roll out faster, that can be more available to end users to accomplish better business goals. Because that's the whole point. All this fufa about what tools we're using and stuff is sort of irrelevant if the end users don't get something out of it that makes their work go better. So I'm psyched for that part.