 I'm Eric Shupps, SharePoint Server MVP, President of BinaryWave. I've been doing SharePoint development since the dark days of the Tahoe project before it was called SharePoint. So I've been around a while through the early 2000 revs into 2007 and all the way now into 2016 in the Office 365. Well, I started working with it in the early beta bits last year. I worked with it through GA and working with some of the various pre-release things that come out. So I've had some fairly good hands-on time with it so far. Well, I like where they're going with it. If the team can execute on their vision of bringing a client-side extensibility model to where we stand in Office 365 and hopefully SharePoint on-premises today, they can bring those pieces together, which is a big ask considering the breadth and width of the server-side APIs and where we've been with the add-in model and whatnot. But if they can really bring these things together, I think we've got something really powerful that will give us capabilities that we've never had in the cloud and quite frankly that other cloud platforms don't have and then translate that down to on-premise. You get a pretty powerful story. My impression of the roadmap is they've set a pretty ambitious agenda. I think they were smart to go with web parts out of the box as a basic extensibility concept. It's something that was sorely lacking in the add-in model that they focus their attention on, which is good. I think when we see the new publishing experiences, people are really going to like those and of course those are built on top of the framework. So they're using their own tool set to deliver a new set of capabilities. I'm really excited to see where that goes. And if they can further extend that to give us some of the capabilities in the cloud that we had on-premise in terms of overall extensibility, I think that's a really good direction for them to go. I know it's a lot of work to pull off if they can make it happen, but I think they're going in the right direction. I like that the framework brings extensibility without all the overhead of working on the server. You don't have to have a fully installed dev environment. You don't have to be running all the heavyweight server stuff. It's something you can spin up. You and I work on our MacBooks. We can deploy code from our MacBooks. Folks can work on Linux or whatever flavor they want to have that. Or if they want to stick with their traditional Windows environment, they can do that as well. But there's no server-side install. It's directly to the client. It's all done in client-side technologies. I think that opens up the platform to a lot of people who weren't prepared for the very steep learning curve for traditional SharePoint development. Well, it's interesting you should ask that, because the one thing that's missing from the tool set is integration with the idea of choice for most SharePoint developers, and that would be Visual Studio. I love the new tool chain. I like the VS code and everything being done with modern web technologies. That's great. The target base for SharePoint development is and always will be within the enterprise. So I would ask people to stay tuned. We're working on a community project that hopefully will address those concerns for folks and bridge that gap between the enterprise and the pure web development community. Change would assume that we have the ability to go in a different direction. And I'm not really sure that we do. I think it's too early, in other words, to say what will we change or what will we do differently about what we have. They've taken a direction for a lot of different reasons to go with this modern web stack in terms of development. That's going to be very confusing for a lot of people, but they didn't really have an option in that. So we can say, oh, we'd like to see that change. We'd like to see it go back to a traditional server-side model, but that's not possible, nor do I think it's actually the right thing to do at this point. I think there's, in order to get this stuff out to not have the traditional we got to wait three years for a new platform to come along and for them to tool it and support it and all that. We're beyond that now. So I think people just need to be patient and let the process mature. For those who are having struggle adapting to it, yeah, that can be a steep curve if you're a traditional server-side.net developer. But I would encourage people to focus less on the tool set and more on what you can get out of the product, especially as it matures more and we get more capabilities. The biggest challenge is definitely the tool chain. For most folks, that's a very hard bridge to cross from where they were in ASP.net, NBC, server-side type of development over to sort of this wild, wild west of JavaScript frameworks and things that change so rapidly. And tool sets that seem to come and go with the setting sun. That is a challenge. There are certainly some frameworks that are gaining adoption. I'm not sure that the tooling is the way we have it now is following the trends there about where most people are going in the web development community. But they've also made a choice not to block people out of using other frameworks, whereas in the past it was .net or nothing. And now we have, I think, more options available to folks. So that's a good thing. I think people are going to struggle. There's no question about it. But when we look back, people struggled with building web parts in 2007. People forget that there was a day where we didn't have any tooling, where we were running Make Cab and making our own Diamond Directive files to build these WSP things. There was no tooling. Now it's easy because it's all baked individual studio, but it wasn't back then. And we're kind of in that same boat again, although I would argue that the tool chains, although they may be unfamiliar, actually fairly robust within the web development community. So there's going to be a period of transition that may be a little rough. But on the other side of that, I think people will like what that gives them in terms of overall capabilities. In terms of future of the framework, I think that the near-term future is pretty clear. They've identified a roadmap where they want to go with this thing. They've already started building their own modern experiences, which are betting on heavily with this tool set. I think that secures the near-term future pretty well, 12, 18 months out. If they can execute, as I mentioned earlier, on their vision for this, I think we have a pretty long runway for this framework. If people adopt, now the community may not adopt. They may decide it's not for them. We have to be honest with ourselves that this is the fourth development model that we're working on. Some people have lost interest. For some, it's just too much change, especially enterprise developers who are used to a very consistent tool set and ALM story. We'll have to see, but if they can deliver us even a portion of the capabilities we had for customization at the server-side APIs, if they can do that in the cloud, with all the other capabilities that Office 365 brings to the table, I think they've got some runway in this. Do you have anything else you want to riff on? Why don't you call that? I would encourage people who are looking at it now and wondering if they should or shouldn't jump into it and work on it to just go ahead and take the leap. You're only going to learn new things. Outside of our traditional bubble for SharePoint development, we've kind of been insulated for a lot of stuff, usually running behind the game. We've been telling people for years, get on the JavaScript bandwagon, learn this disconnected remote API model, even if you're writing .NET and CSOM, learn to break out of that server-side chain. I think this furthers that opportunity. Find a framework or no framework if you want. Just write raw JavaScript and jQuery, if that's what you like to do. But get out of the comfort zone of the way we've traditionally built SharePoint stuff and look for new opportunities to learn the tool sets because maybe you decide not to do SharePoint in a couple of years. You'll be ahead of the game a little bit in catching up where the rest of the development community is at or be able to transition to other parts of the stack that you may. Maybe you want to do teams development or you want to do something inside of one of the other product areas of Office 365. So learning it now, getting ahead of the game, I think will pay dividends in the long run.