Building customizations: Working with the product and not against the product
Chakkaradeep
55

When you reset the page model in a product and produce a fourth development model, I’d expect this level on confusion both from Microsoft and customers. Something I know we both passionately talked about when I was marketing the add-in model and knew SPFx was coming.

They’ll be much more script injection in the next few years. The SharePoint Framework is a great step in the right direction (client side, responsive, broader reach developer stack etc.), but right now its just web parts. SharePoint has many other UI hooks that are missing, until those are available, you’re going to get workarounds with script injection. Like what Mikael did to change the SharePoint header.

You’ll never be able to stop folks from hacking at the SharePoint DOM now its full client-side inline in the page. The add-in models IFRAME certainly tried to help enforce it. There’s a reason that Vesa’s PNP initiative exists and calmed the community. It has saved SharePoint developer story in my opinion.

Like Marc D Anderson commented. Many of the customers I speak to are still sitting on SharePoint Server and not on 2016. So they’ll be living in the Visual Studio/SharePoint Designer world still for years. SharePoint Server 2016 really didn’t have anything that compelling to draw people from sitting on old versions from an experience perspective in my opinion. Hopefully a future feature pack will.
Even when SPFx makes its way to server, I wouldn’t necesarily expect them to jump to it over Visual Studio. Enterprise developers love Visual Studio and often don’t get time to learn a new developer stack. Plus, if they can’t migrate their current customizations over, they’ll continue to use Full Trust Code, Sandboxed Solutions and the Add-in Model.

The reason that SharePoint was so popular as a product, was its flexibility for pro developers and power users to customize it. They’ll always be something a developer does that you guys didn’t expect.
Partners have propped up SharePoint, filling in gaps, for a long time now. Right now, SPFx really isn’t a model that ISVs can use because there is no secure way to call back to a service with a token without other web parts on the page being able to do this too.

I personally feel that your team is far too small for the SharePoint Framework to catch up with its own developer journey tail. If Jeff is reading…maybe its time to pony up some more engineers so we fill the gap quicker and that way give the community more encouragement to switch.

I look forward to seeing how your team balances this fine line. Visibility is key. Which you guys are doing a lot better from my new perspective outside.

Like what you read? Give Jeremy Thake a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.