 Hi, my name is Jeremy Thake. I work at HyperFish as the VP of Product Technology. For my sins, I've been in SharePoint since about 2004. I moved to Australia after graduating from a university in England and ended up in a web shop where I did .NET at uni and all the web developers there were JavaScript developers and this big government contract came on that was, hey, we needed to work on ASP and JavaScript inside of SharePoint and you're the only one that seems to know anything about SharePoint, which I didn't, but it got me the job and for all that time now I've been working as a developer in that space, kind of the journey through ASP, ASP.NET to all the different models and on from there. It's interesting, I had a kind of unique experience with the SharePoint framework. I actually worked at Microsoft for three years on the developer marketing side with Chris Johnson, CJ, who's also at HyperFish now as well. We were involved really in the foundations of finding out that the SharePoint engineering team were going away and building a SharePoint framework and naturally I was very passionate about the fact that I'd worked with the full trust solutions model and also the sandbox solutions model and the adding model and so then naturally I had a lot of passion and emotion for the community to make sure that, hey guys, let's try and make sure we're doing the right thing by introducing another developer model into SharePoint and so they're in the inception working with Adam Harmetz and Dan Kogan and Chaka Deep and it was really interesting to see kind of the framework evolve so yeah, from the very kind of beginnings. My impressions of ASP FX have been really that since when I first saw it in Inception I think the thing I'm kind of most proud of and happy that's gone in that direction is the fact that they've really listened to a lot of the feedback from actual SharePoint developers that have been in this space for a long time. I think their initial intent from engineering perspective was let's build this thing with JavaScript because we want to go get all the JavaScript developers in the world to build on SharePoint and that naturally wasn't going to happen immediately because SharePoint has a bad tang in the mouth with a lot of developers that have been dragged into that space over their career and I get the intent that by moving into that JavaScript tooling that it'll make it easier for those developers to come in but it's very obvious that they've spent a lot of time making sure that it's going to be an easier transition for a SharePoint developer that's been in this space for a long time working in Visual Studio and .NET and transitioning into this new tool chain. So the roadmap is a little bit kind of dependent on what the engineers want to commit to and obviously having insight into this being in the inside I can totally understand and empathize with the fact they don't want to over promise and then under deliver and so you see that they'll call out the big things they know they're definitely going to hit which are priority ones within the engineering team but they'll keep some other things back but I understand that they can't really commit to too much there because you don't know what those bigger things that they're introducing into the framework are going to take and what that impacts of things that drop off maybe not the P1 features but the P2 features so the roadmap is really just indicating the bigger things that they know they're definitely going to have all their developers working on inside of Redmond. For me we've spent a lot of time in the SharePoint world of having been so far back in time against when you went to like a build event or if you went to a web event somewhere. When I was in Australia I was always known as the SharePoint guy and was never respected against other developers that are in the .NET space or in the node space and so forth. Having the ability to be on the same level playing field being able to use the frameworks they talk about and use the techniques they're talking about with the tool chain for me is really what gets me excited as a developer but I think the biggest thing is that the experience for the end user is so much better. When I go into a modern page in SharePoint and I go into the plus sign and open up my toolbox and add my web part there's no longer these like full page reloads there's no longer when I go change a web part setting a full page reload so the experience is much like what people have been used to in the consumer world for a long long time. Now that's just the nature of SharePoint catching up and Microsoft will try and make you seem like they've done something new and innovative but the reality is that really that's what the rest of the web has been doing for five years and so I'm excited now that we have the ability to be on the same playing field as some of the other technologies that are out there. So at HyperFish obviously we're very focused on how we can help organizations complete and update their profiles and we do this via bot technology where we email the user when their profile isn't up to the company standards or we reach out to them via Skype. What we intend to do in the future is be present in people's intranets and other surface areas within Office 365. Now the SharePoint framework is great because it allows me to build web parts that can be appeared and snapped into intranet homepages or even departmental sites or individual team sites. The problem that we have at HyperFish is that there's no real store commercial model for that. So if you're a developer out there watching this video and you feel like you've come up with this call, weather web part, here's a tip, don't build a weather web part because everyone's built them for the last four models and you're not going to make any money out of it. But if you did want to do that, you're not going to be able to do that because there's no store mechanism and there's no easy way for an end user to actually go deploy your web part. You do need to go and speak to a SharePoint administrator to be able to deploy anything like that. And so other development models that SharePoint have have a store ability that doesn't require a SharePoint admin to deploy and there's lots of other kind of angles that can be taken by power users and citizen developers to get things into intranets. So for us as a vendor, we are desperately waiting for that kind of support where the business owner can actually deploy these things without having to go to their IT guide to get these things deployed. I am far as pretty hard with the existing SharePoint developers because I am one. I did delete from ASP to ASP.net. We were always lagging on the .NET framework in terms of not being able to use the latest framework whenever it was announced in a Microsoft Keynote and there were some really cool things that I wanted to be able to leverage but you had to go build that stuff rather than leverage a class library that existed in the framework because you're an older version. I think with the way the SharePoint framework is going as a new node developer and learning JavaScript and TypeScript and all the tool chain I believe it would have been better if we had prioritized a bit more on where those Visual Studio developers exist and live right now and getting them comfortable with the framework working there as well as trying to encourage them to move to things like Visual Studio Code and other code editors. The main reason being is that you don't want so much of a giant big bang change all at once and it's perfectly capable and there are experiments going on right now that people like Eric Shupps are working with the engineering teams to get full blown Visual Studio working with the framework and I just feel like if we had anything to change I would have been more empathetic towards our existing SharePoint base getting them into the framework before we tried to sell this cool SharePoint product to node developers that want to build everything from scratch themselves with a thousand different frameworks. I think the biggest challenge of the SharePoint framework adoption is the fact that not everyone's on SharePoint Online not everyone's on SharePoint 2016 Feature Pack 2 when that comes out with some of the SharePoint framework capability it's not going to have everything that you can get at that's available in SharePoint Online so the adoption rate is going to be pretty low until they satisfy the server version of SharePoint having the framework and also then the subsequent release where some of the new extension things for when I'm in a SharePoint library having the ability to override UI controls there because I feel like the SharePoint framework first release will be in Feature Pack 2 it doesn't do enough for the enterprise to switch when they're already building things in the Adi model or to be honest they're probably still not using the Adi model they're using full trust code because it doesn't matter to them because they're never going to the cloud the reality is they'll go to the cloud eventually but there's a fair population of customers that are still camping on SharePoint 2010, 2013 and 2016 that aren't even indicating that they're going to move to a Feature Pack when it releases they'll give it 9 months to a year before they'll even consider putting a Feature Pack in and so for the mindset of those customers that's going to really hurt SharePoint framework adoption and obviously for us as a vendor when we make decisions about we're going to build the HyperFish web part for profile updates the challenge that we have is that we want to go to the biggest population of audience we don't want to kind of limit ourselves just to those that have the capability to run the SharePoint framework and so we'll probably do a bit of a combination of JavaScript that can be deployed as an Adi model capability for those that are on 2013 or 2016 but you know the best experience would be if the JavaScript was running inside a SharePoint framework and deployable to SharePoint online or SharePoint 2016 we feature Pack 2 deployed so the SharePoint framework's been released for about a year now so I expect Microsoft to release another developer model in two years no I'm kidding because if they did that they would be hosed I think the SharePoint framework has to be their last effort at this they really can't kind of deviate from this I do believe that in that timeframe they won't be able to get rid of the Adi model the main reason they won't be able to get rid of the Adi model is purely because the decision they made architecturally that the framework lives in the client side in the browser and it has basically full realm to the whole page model now again if I go back to being a vendor and building a web part if I'm calling our HyperFish API that's living inside of Azure somewhere and I'm using an OAuth token other web parts from other vendors could sniff those tokens and start calling our API ourselves and either trash our service or kind of read and inspect information we're storing in the databases that are kind of behind closed doors in Azure and so there will be times not just for vendors that are fearful of kind of multiple vendors living on a page or not wanting customers to have that kind of access but they'll have to use the Adi model to get that isolation security where I can have my own Azure AD token that only my pages can get at because they're in a separate DOM which is elevated outside inside that iframe which you don't get with the SharePoint framework so I guess the main prediction will be SharePoint framework is hopefully their last bet and they're going to really invest in that and not go and throw the towel in and get a new one but I also definitely believe that the Adi model has to exist for a long long time to come purely because of the deployment strategy and the isolation of security I'm fortunate enough to call Andrew a good friend and we've actually worked together a lot on SharePoint training and I've actually trained Andrew's content for a long long time when I was in Australia and that's how we first met many years ago he taught me through his 2007 WCM book How to Code in SharePoint web content facing sites which earned me a ton of cash when I was in Australia so my advice would be if you want to learn the SharePoint framework you have to go to Vortanos and use his content to learn it it is simply the best stuff that I've seen so far out there from all the different Microsoft internal things that are being pushed out to some of the bloggers out there across the globe and Andrew's been in this space for a long time he's teaching not only the fact that he knows SharePoint from the weeds all the way up to the top but also Andrew did a really big pivot a long time ago when he always packed in a towel with SharePoint and jumped into that no JavaScript space so I think the benefit of going for the Vortanos content is that it's not just SharePoint-oriented knowledge but it's also really really good knowledge around how you should genuinely building node type scripts and the whole tool chaining from woe to go whether you're on a Mac or a PC so it's the best place to go for learning the SP FX framework