SharePoint Framework - In Jeremy Thake's Own Words

This is one installment in a series 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.

Jeremy Thake

Twitter: @jthake
VP of Product Technology, Hyperfish

Hi, my name is Jeremy Thake, I work at Hyperfish as a VP of Product Technology.

What’s your background as a SharePoint developer?

For my sins, I've been in SharePoint since about 2004. I moved to Australia after graduating from a university in England, ended up in a web shop where I did .NET at university, and all the web developers that were JavaScript developers, and this big government contract came on that was, "Hey, we need you 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 that time now, I've been working as a developer in that space, kind of a journey through ASP, to, to all the different models, and on from there.

How much time have you spent with the SharePoint Framework?

It's interesting. I had quite a unique experience for 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 was going away and building a SharePoint Framework, and naturally, I was very passionate about the fact that I had worked with the Full Trust Solutions model, and also, the Sandbox Solutions model, and the Add-in model.

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 we're doing the right thing by introducing another developer model into SharePoint."

There, in the inception working with Adam Harmetz, and Dan Kogan, and Chaks. It was really interesting to see the framework evolve from the very beginnings.

What is your impression of SharePoint Framework today?

My impression of SPFx have been, really, the ... since when I first saw it in inception, I think the thing I'm 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 the space for a long time.

I think their initial intent from an 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 taste in the mouth for a lot of developers that have been dragged into that space over their career.

I get the intent, but by moving into that JavaScript tooling that it will 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 the space for a long time, working in Visual Studio and .NET, transitioning into this new toolchain.

What is your impression of the SharePoint Framework roadmap?

The Roadmap is a little bit dependent on what the engineers want to commit to, and obviously, you're having insides being inside, and I can totally understand, and amplifies with the fact that they don't want to over promise, and then under deliver.

You see that they ... they all call out the big things. I know they're definitely going to hit which are priority one with an engineering team, but it will keep some of the things back.

An example was, yesterday, Vesa tweeted that they now support tenant level employment of the SharePoint Framework, which is great for developers that have been in this space for a long time.

They used to use things like delicate controls to override the user interface across all site collections, without having to go through the process of deploying individually to each one.

I think, sure, there'll be this roadmap, which is showing the key features that they release at the Ignite event, and moving forward now, the SharePoint event that's going to be in Vegas next year, and then the next Ignite event, 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 impact of things that will drop off ... maybe not the P1 features, but the P2 features.

The roadmaps really just indicating the bigger things that they know they're definitely going to have all their developers working on inside at Redmond.

What is your favorite part of the SharePoint Framework?

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 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 again.

I'm a developer, being in the .NET space or in the Node space, and so forth. Having the ability to be on the same level playing field, be able to use the frameworks they're talking about, and use the techniques they're talking about with the toolchain they talk about 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 the plus sign and open up the toolbox, and have my web part, there's no longer these full page reloads, there's no longer when I go change a web part setting, a full page reload.

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. Microsoft will try and make it seem like they've something new and innovative, but the reality is that, really, that's what the rest of the web's been doing for five years. 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.

What is the one thing you would add to the SharePoint Framework?

So, Hyperfish, obviously, we're very focused on how we can help organizations complete and update their profiles, and we do this by our bot technology, where we would email the user when their profile isn't up to the company standards, or we reach out to the via Skype.

What we intend to do in the future is be present in people's internets 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 internet home pages, 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 and you're watching this video, and you feel like you can't build a 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.

Other development models that SharePoint have had have a store ability that doesn't require a SharePoint admin to deploy, and there's lots of other angles that can be taken by power users and citizen developers to get things into internets.

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 the IT guy to get these things deployed.

What is the one thing you would change to SharePoint Framework?

I empathise pretty hard with the existing SharePoint developers, because I am one. I did the link from ASP to We were always laggy on the .NET framework, in terms of not being able to use the latest framework whenever it was announced in the Microsoft Keynote, and there was some really cool things that I want to be able to leverage, but you have to go build that stuff, rather than leverage a class library that existed in the framework, because you're on an older version.

I think with the way the SharePoint Framework's going, as a new Node developer, and learning JavaScript, and TypeScript, and all the toolchain, I believe it would've been a little bit 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.

I think 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 I know people like Eric Shupps are working with the engineering teams to get Visual Studio, full blown Visual Studio working with the Framework.

I just feel like if we had anything to change, I would've been more empathetic towards our existing SharePoint base, getting them into the Framework, before we try to sell this cool SharePoint product to known developers that want to build everything from scratch themselves with 1,000 different frameworks.

What is the biggest challenge with SharePoint Framework?

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 capabilities. It's not going to have everything that you can get out that's available at SharePoint online.

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 Feature Pack Two, it doesn't do enough for the enterprise to switch when they're already building things in the Add-in model, or to be honest, they're probably still not using the Add-in 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 aren't even indicating that they're going to move to a feature pack when it releases. They'll give it nine months to a year before they even consider putting a feature pack in.

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 a profile updates," the challenge that we have is that we want to go to the biggest population of audience.

We don't want to limit ourselves just to those that have the capability to run the SharePoint Framework. We'll probably do a combination of JavaScript that can be deployed as an Add-in model capability for those that are on 2013 or 2016, but the best experience would be if the JavaScript was running inside a SharePoint Framework, and deployable to SharePoint Online, or SharePoint 2016 with feature pack two deployed.

Predict the future - Where do you see the SharePoint Framework Going?

So, the SharePoint Framework's been released for about a year now, so I expect Microsoft to develop another developer model in two year. No, I'm kidding, 'cause if they did that then they would be hosed. I think the SharePoint Framework is it has to be their last effort of this. They really can't deviate from this.

I do believe that in that timeframe, they won't be able to get rid of the Add-in model. The main reason they won't be able to get rid of the Add-in model is purely because the decision they make architecturally that the framework lives in the client's side in the browser, and it has, basically, full roam 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, then I'm using an OAuthtoken.

Other web parts from other lenders could sniff those tokens and start calling our API ourselves and either trash our service, or raid and inspect the information we're storing in the databases that are behind closed doors in Azure.

There'll be times, not just for vendors ... there are multiple vendors living on a page, or not wanting customers to have that kind of access, that they'll have to use to Add-in model to get that isolation security where I can have my own Azure AD token, but only my pages can get at, because they're a separate domain, which is elevated outside, inside that iFrame, which you don't get with the SharePoint Framework.

I guess the main prediction would 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 Add-in model has to exist for a long, long time to come, purely because the deployment strategy, and the isolation of the security.

Do you have any Advice or Words of Wisdom?

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, and always in Australia, 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 earnt me a ton of cash when I was in Australia. My advice would be, if you want to learn the SharePoint Framework, you have to go to Voitanos 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 of internal things that are being pushed out, to some of the bloggers out there across the globe, because Andrew's been in this space for a long time.

He's teaching not only the fact that he knows 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 the towel with SharePoint and jumped into that Node JavaScript space.

I think the benefit of going for the Voitanos content is that it's not to SharePoint or oriented knowledge, but it's also really, really good knowledge on how you should genuinely building Node, TypeScript, and the whole tool chain from where to go, whether you're on a Mac or a PC. It's the best place to go for learning SPFx framework.

Did you like this installment in the series? Let us know what you think in the comments below and share it on social media!