SharePoint Framework, what about on-premise people ?
This is my two cents journey from switching my mind away from on-premise development methods to Office 365 SharePoint Developer.
Back in 2015, when I saw all those tutorials about SharePoint Framework, the so-called modern way of developing new apps inside SharePoint, back in 2015, I told myself: “my customers are mostly on premise (in France) so this is not of my concern”.
Then SharePoint 2016 feature pack 2 rolled out with SPFX support, and soon SharePoint 2019 will go RTM (end of the year).
YET, most of my customers are on SP2013 or SP2016 RTM. So I thought there are no ways to switch to modern development.
How to be able to catch those trends driven by PNP community? Every week there are new components built in Typescript, React, Material UI, VueJS, Angular etc….
Some GitHub boilerplate to the rescue
Then, I discovered some boilerplates github repository to be able to program using the trending technologies such as :
The second one has been done by Andrew Koltyakov, a MVP. A lot of modern ways to deploy has been added to this project such as :
- gulp watch to deploy JS / CSS etc to SharePoint whenever you save
- live reload to reload the page automatically
- PNP to enjoy coding faster than lucky luke
Plus coding in typescript will prepare a potential SPFX migration for potential migration to Office 365.
SPFX Continues to get updates by the community
Ok, you will tell me that Microsoft recommends app model on-premise or upgrading to more recent SharePoint version… To me, that is the dream and we have reality: technologies shift, modern ways to develop components on the shelve, why shall we stay in a heavy model such as apps model? There are some cases where app model is useful such as run with elevated privileges etc… for other cases components could be developed using such boilerplate.
Meantime for Office 365 :
- Recently some developers have created a pnp jquery spfx boiler plate.
- A lot of VS code Extensions came to life to make the process easier to package and deploy to Office 365.
Maybe we’ll see the same kind of innovation on premise? I hope so 🙂
And you which way you develop your components on premise when SPFX is not available?
Angama, J (2018). I do not work on O365, why should I care about TypeScript, SPFX, React etc ? Available at: https://jeffangama.wordpress.com/2018/09/19/i-do-not-work-on-o365-why-should-i-care-about-typescript-spfx-react-etc/ [Accessed 2 October 2018]