PowerApps Component Framework - Frosting on the Cake

I usually wait a week or two to weigh in on new announcements from Microsoft. I like to let the noise die down a little, and see how others are responding to the news. But I am way too excited about the Public Preview launch of the PowerApps Component Framework.

What's in a Name?

The journey to Public Preview has been a rather long one. Originally coined the "Custom Control Framework" (CCF), which gave way to another name, "PowerApps Control Framework" (PCF), to ultimately landing on the name "PowerApps Component Framework", this "framework" has been quite the work in process. According to the new Branding Guidance, we are not supposed to use the acronym (PCF) anymore, but whoever decided that, does not write blog posts.

Good Delays

When PCF was first announced, there was a lot of excitement, among the MVP community in particular. We were all eager to get our hands on this new "capability" that was coming soon... but it did not come soon. It was not because there was any lack of will from the team behind it, rather it was another example of Microsoft seeing an "Opportunity". I recently discussed this "opportunistic re-trenching" that has been going on across Microsoft Business Applications on Mary Jo Foley's podcast. The source of this particular delay, was the realization that if both Model-Driven and Canvas PowerApps could share the same Component Framework, it would be way more valuable to everyone. So one step back was taken, to get two steps forward to the Preview. A frustrating delay for some, but well worth the wait.

What the Hell is PCF?

Is it charts? Is it Kanban boards? Is it Gantt Schedules? Buttons, dials, widgets, cameras? It is actually a way to create all of these, and many other "components". Is it a "Citizen Developer" capability? No, it is not. Building "Components" is a developer-level job, requiring Javascript/typescript and other development skills. For those of you on the development side, this is the future of what you now know of as html Web Resources... but way better.

How is it better?

Flexibility, portability and supportability are three things that come to my mind of why this is way better. As opposed to building a hard-coded webresource tied to something, with a Component you can package that up with parameters. This means that your Component is abstracted away from the particulars of a specific environment.

For example, during the just concluded "Private Preview", we worked directly with the Microsoft development team to refactor a Gantt Chart Webresource that we had built for a specific custom project management entity in one of our ISV solutions. Our original html webresources were of course hard coded to this entity. The finished "Component" version instead included a parameters capability, meaning we could actually display our Gantt Chart "Component" on anything that met the minimum requirements to display it, which in our case was a start and end date. If additional parameters are present such as predecessors, successors or percent complete, it would take advantage of those also... very flexible. We can install our component solution on any environment, and use it wherever we want. While Citizen Developers may struggle to "build" a component, configuring one for their use is completely within their capability.

From a supportability standpoint, since Microsoft developed and owns the "Framework", it falls on Microsoft to handle component lifecycle, retain application business logic and optimize for performance... instead of you.

Is this All New?

Well, it's new to you, but you have actually been using "components" for quite a while, possibly without even knowing it. Remember the fanfare about the addition of editable grids? That was a "component' built by Microsoft on the framework. In fact, a lot of the features you see in the new Unified Interface are actually "Components", including all of the original charts. What is new is your ability to now create your own components.

Who will use this?

Personally, I think the largest opportunity around the PowerApps Component Framework is for ISVs. Either building components as part of their larger solutions, or even freestanding components that they might resell individually via AppSource. There is some development effort involved, and I don't see a lot of SIs necessarily learning the nuances of building components for individual end customer needs. Better that they just incorporate components that exist, or will exist in the near future. Of course many ISVs still need to get themselves up to the Unified Interface, but that will happen pretty quickly, or they will be in a world of hurt.

Are Html WebResources being deprecated?

A common question today from customers and partners, whenever the Microsoft Bizapps team launches something new, is whether the old stuff will go away. Everything you are doing will eventually require change. Microsoft can only advance so fast when they are dragging a big bag of legacy behind them. This was the impetus for the One Version strategy. But even in the One Version world, a level of backward compatibility is a requirement... but for how long. How long will Microsoft allow that technical debt pile to grow? As long as they absolutely have to, and no longer. I have not heard anything about deprecating anything as a result of PowerApps Component Framework. But of course the same could have been said two years ago about other, now deprecated things.

Neither the future nor Microsoft is waiting for you.