Forum Discussion
Powerapss vs SPFX
- Mar 03, 2018
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...
- Paul CulmseeMar 03, 2018MVP
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...