Powerapss vs SPFX

[Russell Gove]

So I spent the last week looking at PowerApps. Someone needed an IPhone app to record some safety info at one of our locations. In the course of a week I was able to cobble together a nice app that let them record the info on their iPhones and save it to a sharepoint site , along with photos (thanks to Paul Culmsee).

I have also been working with SPFX since it was in preview and have developed production applications using that technology. These took anywhere from 5 months (when I was learning) to a few weeks, depending on the complexity.

Both these platforms are changing so quickly that a person could spend 40 hours a week just keeping up on the latest developments in the platforms.

Is there any guidance available on when to use which technology? Apart from time to develop (which PowerApps wins) there are other concerns (such as maintainability, ALM) which SPFX wins. And these platforms change so often that it’s impossible to know which platform is the right solution for a given problem at any point in time.

[#2]

I think that guide does not exist and I agree it would be great to have it. Hope someone from the PowerApps or SharePoint Team thinks this guide would be really worth too

[#3 · Accepted solution]

That's a great but hard to answer question. My take on it (so far) having working with all of them is that all have massive potential, but all have inherit constraints.

SPFx has the most power and flexibility, but the amount of boilerplate code you have to do is massive. I don't like boilerplate code, and it also keeps SPFx in the realm of the developers, so SPFx will never be something I will be that good at. 

So I gravitated to PowerApps/Flow and Azure functions (this is huge) and I am surprised at how far you can go. Additionally, PowerApps, like InfoPath is easy for non hardcore developers to get into and do some very good apps quickly. The same goes for Flow.

While I am not directly answering your question, one useful approach to take to PowerApps and Flow is to assume they are a means to a bigger end. In other words, use them to rapidly prototype and get solutions into the hands of your users. I did one PowerApp for a client so we could get rapid feedback on functionality, which my colleague then used as a starting point to make some SPFx components to do it with the full power and flexibility of React and Redux. Other PowerApps remained PowerApps because they did what was needed.

So if I bring up PowerApps/Flow into the conversation, if the organisation is conservative and risk averse, I frame it as a risk reduction/piloting exercise. "we all know users don't know what they want, this reduces the problem of months of work to deliver the wrong thing". But if the organisation takes its cues from the world of startups and design thinking, then PowerApps is your dream tool towards an minimum viable product, so I frame it as an innovation/fail-forward experiment platform... 

[#4]

Great question Russell, and one that I am grappling with too. Although I have been a developer most of my working life, I can appreciate the massive time savings and functionality that PowerApps/Flow/Azure serverless bring to the table.  

The ALM story for PowerApps is getting better, with the ability to export and import PowerApps and settings between environments manually or by using PowerShell (this may be in preview). In theory, you could set up a CI/CD approach with PowerApps too if the PowerShell options become GA. The source control integration and versioning with PowerApps, however, is still a drawback IMHO. 

[#5]

In case anyone stumbles across this  there is a good comparison at Power Apps vs. SharePoint Framework for Forms - Thrive (thrivenextgen.com)