Question

I tried doing some research on this online, but unfortunately all I could find was articles on how awesome PowerApps and Flow are. I'm curious, in the world of no-code / low-code solutions, where does this leave SharePoint Framework? When are PowerApps appropriate vs when is SharePoint Framework appropriate to be used within SharePoint? What are the strengths and weaknesses of each in relation to SharePoint development?

Was it helpful?

Solution

Very interesting question.. let us first understand the background of what is all 3 about.

MSFlow - To Automate a business process we generally use workflows. Ms flow are alternative to workflows. Before MS flow, Sharepoint designer workflow was used for simple things but for complex things you had to rely on custom workflow(visual studio) or any third party tool like Nintex or K2... Now with MS flow, we can do cool things which were not possible before using designer workflow. But But But...Microsoft took it to another level where flows are not limited to use only for Sharepoint but with different data sources flow can take care of triggering a workflow with many others technologies...

Power apps - In context of Sharepoint This can be used to create complex forms, working with multiple data sources, creating rules to show hide controls based on business rules etc with no code solution .. But But But...again here Power Apps is not limited to Sharepoint... it is much more than that..it also allows us to create mobile applications and it can connect to many cloud services making it more flexible and extensive to use...

Sharepoint Framework - it is a new development model recommended by Microsoft due to fact that Previous Add in development model has its own limitations. Microsoft is recommending to use client side solutions for any customizations. Before Addin or SPFx, most of customisations done by developers on client side was using content editor or script editor webparts or creating custom pages and injecting HTML on page using JavaScript...to perform CRUD on Sharepoint we can use JSOM, REST api or spservices.js(not from Microsoft still highly used). SPFx solution are not specific to webparts, it has extensions, allows to provision assets along with solutions.Here we don’t have But... Spfx is very specific to SharePoint but it has more power and flexiblity.

Now answering your specific question

I'm curious, in the world of no-code / low-code solutions, where does this leave SharePoint Framework?

I think, purpose of both Powerapps and SPFx is different though there are some things which can be done in both and we had to choose any one. But in all other cases we have specific feature for both.. To understand let us point our some differences.

  • Powerapps can't provision assets(list,libraries) as and when app is installed.
  • SPFx has extensions which allows to customize UI of SharePoint using application customizer, field customizer, Command sets.
  • Creating webpart using SPFx(may be form) gives user unified experience of being in SharePoint where power apps takes user to a different url to fill out form.
  • SPFx solution can be made reusables using webpart properties etc. Power apps would be specific to a datasource and can't be reused(not always).
  • Powerapps has inbuilt connectors to connect to external data sources whereas in SPFx we have to write our own connectors.
  • If we want to have an outside of SharePoint experience but still want to use SharePoint's list and library to store data, Power app is way to go.

SPFx is here to stay and if you are following its roadmap, new features are getting added very frequently. In fact as per latest updated SPFx team has changed to monthly release cycle so we can expect some very good features every month.

Is it still worth taking the time to learn the SharePoint Framework if you have a developer and coding background, or do we admit defeat and resign ourselves to the low-code / no-code world?

Definitely, yes. If are looking forward to work in SharePoint technologies we can't ignore SPFx. We have to have its expertise and know how about. With SPFx supported by open source community there are many samples available for real world use cases. Infact SPFx is supported on SP 2016 so for organization using SharePoint On-Prem would also have to use SPFx for customization.

Having said that, we also must understand that no code solutions would always have its constraints. If your problem is complex, no code solution won't work in certain cases. We as developers should have expertise in both. There will be always cases when non- technical team using no code solutions won't be able to solve specific problem that's where We(putting our programmer's hat) comes to rescue.

Hope this answers your question.

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top