The New SharePoint Framework: A New Perspective from DevKit3

Last week I had the privilege of attending the third Developer Kitchen (DevKit3). The mini-conference, with content centered on the upcoming SharePoint Framework (#SPFx / the Framework), gave attendees an in-depth review of the future of SharePoint development. Since what I consider the Framework’s predecessor, NextGen Portals, was publicly introduced at Ignite 2015, I have been beyond excited to dig into a new SharePoint development model. This excitement jumped a notch when the Framework was formally announced at the Future of SharePoint in May 2016.

First, I just want to thank Daniel Kogan, Bill Baer, Dave Pae, and the Microsoft Development Team for an invitation to DevKit3. I am excited to share that in my opinion, the Microsoft Development Team, an extremely talented group of individuals, is providing an innovative model in the new Framework, as well as unleashing some exciting opportunities to create and implement new solutions. That is not to say the current implementation is perfect, nor am I saying there isn’t room for improvement, but it is a leap in the right direction.

We attendees were asked to put the Framework through its paces and see what we could create in less than 24 hours, and although one can’t expect the most polished examples in such a short window, over 25 concepts were showcased on day two of DevKit3. I was extremely impressed by the ideas and cutting-edge concepts my fellow participants produced.
Even further, we were provided the opportunity to provide feedback and suggestions, and I hope I helped represent the developer community well with comments that will help improve the framework and its adoption.

My Key Takeaway: A More Modern Web Development Approach

The Framework delivers a new development model based on Client Side Rendering (CSR), adopting the common modern Web Development approach. CSR, a model that became popular a while back for most web application, offers SharePoint developers a chance to insert their CSR solutions directly into SharePoint, rather than being forced to use less desirable integration solutions, such as the Script Editor Webpart.

The new CSR model available within the Framework decouples the back-end of SharePoint from the front-end presentation of information to the client (browser). This is right up my alley. In fact I would say that anyone who has been branding SharePoint, or rather anyone who has been attempting to customize the front-end interface of SharePoint, should be very excited about the new framework.

Time to Learn TypeScript

One of the prerequisites of the Framework is TypeScript, and although I thought I came prepared, I can say I did not. TypeScript is at the core of the Framework and I found first hand, it’s time to truly learn TypeScript. While I have a feeling this might be a stumbling block for some in the SharePoint community, I encourage the skeptics to see it as a new challenge that can yield additional great benefits.

I will admit, a small percentage of me still questions the use of Framework over the Script Editor Webpart (all of which I shared with the Product Group), a much larger percentage of me is ready for new capabilities in customizing the interface of future SharePoint portals. I can’t say everything we have been looking for will be delivered all at once, but when the Framework is released, it will be a step in the right direction.

What’s Next on My To-do List

After departing from an excited two days, I will continue to further emerge myself in Typescript. With the migration to TypeScript as one of the biggest challenges in the new SPFx and possibly a hindrance for a sizable group of existing SharePoint Front-end Developers, one might ask, “Why does TypeScript matter?” or even, “Why can’t we just use raw JavaScript?” and all of these are great questions. While the jury is still out as if I will use TypeScript for future projects, I still believe TypeScript was chosen for good, deliberate reasons.

There are other decisions that have been made around Sass compilation and CSS namespacing that might take time to get used to. This may cause initial issues with external JavaScript libraries, but I believe with time and hands-on experiences, these are issues that will take care of themselves.

Closing Thoughts

I gave my feedback, often very candid feedback, which I hope will help the Product Group to continue to refine the Framework. While I am under no illusion that my input will be considered in the first release product, I do have trust and faith in the Framework Product Group to deliver a solid product. As Microsoft delivers on their May 4th promise of the Framework, I will have more updates to give you. In the meantime, check out my post last month on other SPFx announcements made at SPTechCon Boston.

So, for all of you SharePoint Developers, keep on developing SharePoint as you have in the past. Don’t worry, nothing you have been doing is going away. Master Pages, Page Layouts, full trust solutions on-premises, will continue to be available for you and your projects for some time. The Framework is bleeding edge right now and will take time to deploy.

When you do get your hands on the Framework when it is released to public preview (no idea when this will be), if you hit a limit within the Framework, remember that there are likely reasons why that rail exists. You should also remember to share your suggestions at User Voice. Vote early, vote often, and keep coding my friends.

Speak Your Mind

*