Microsoft is separating its low-code programming tools from Power Apps. What does that mean for you and for your apps?
Microsoft is no newcomer to the world of low- and no-code development. Its long history goes back to Excel’s formulae (now getting an upgrade into a full-blown programming language in their own right) and Access’s web-application design tools, through the drag-and-drop process automation tooling in BizTalk, before arriving in Project Siena, a tool for building applications for Windows 8 and Windows Phone. That platform, with its declarative programming model and easy-to-use UI builder, became the foundation for what’s now Power Apps, a key component of Microsoft’s business applications platform.
SEE: Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)
Power Apps is a tool that lets anyone quickly build their own apps, working with data stored in the Power Platform’s Dataverse common data layer, in the Microsoft Graph, and in your own line-of-business applications, all the way to Azure’s machine-learning Cognitive Services. Using a mix of these tools, and its own design features, Power Apps can quickly assemble the apps you need to solve your business problems, without waiting on developers.
But there’s a problem with tools like this: the apps you build can get too important. Suddenly something you put together in a couple of lunchbreaks has become the key to how your department works. It now needs documentation, and at the same time needs to move into a source control system, rather than your PC. But if it’s code running inside a personal account on a web app that’s nearly impossible, when the code and the platform are tightly coupled.
With the Power Platform and Power Apps at the heart of Microsoft’s business applications strategy, it’s time for it to break that link between code and platform. Roundabout ways to do this have been available, but Microsoft has now formalised them, at least for Power Apps’ Canvas apps, with a new open-source language called Power Fx.
If you’ve worked with Microsoft’s low-code tools at any time over the last decade or so, you should find Power Fx familiar, as it’s a direct descendent of the tools developed for Project Siena, and inherits concepts from both Access and Excel. There’s a lot of similarity with Excel development, and you can bring your formula-writing skills to Power Fx, speeding up the learning curve. At the same time, it owes a lot to how tools like Access work with SQL, handling queries and working with data.
Microsoft talks about Power Fx as making application development like building a spreadsheet, calling it a ‘formula language’. In Power Fx, a formula uses references to controls and data instead of cells, linking it to your user interface design. Each formula runs when the control to which it’s tied is used, so when you type into a text control, the appropriate formula automatically runs. That way there’s no control flow in Power Fx, no way of tying an operation to an event without making the event a trigger for a control.
Like Excel, each formula is independent. But one formula can feed into another, using output values as inputs. You don’t control how those elements interact — it’s all handled by the underlying platform, whether it’s a Power App or another tool using the Power Fx language. If you want to think of it in higher-level terms, it’s an asynchronous functional programming environment, with each formula a separate function.
The result is a system that’s live as you write your code, with each new block of code ready to run as soon as it’s written. It’s an approach that makes writing a Power Fx application very like building an Excel spreadsheet, while giving you the opportunity to test and experiment with code as you’re building an application.
Microsoft has built a dynamic compiler for Power Fx that runs inside the Power Apps platform, and it’s used to deliver auto-complete and other IntelliSense features. You get to see errors highlighted as you make them, speeding up debugging. An error in one formula doesn’t stop the app running, thanks to each block being run in isolation. The IntelliSense tools in the compiler will work with your data sources and controls, loading metadata and using it to suggest what you can use at this point in a formula.
Microsoft’s tooling for Power Fx has no-code options for handling control formatting, setting values that can be seen in generated code. That’s a good option, as the resulting code can be edited outside of the Power Apps environment, without affecting the controls. There’s a dynamic link between the no-code tooling and your Power Fx code, so you can see any changes you’ve made when you reload. This option provides the possibility to use Power Fx as an export format for no-code development, taking code from visual tooling into code repositories like GitHub.
No-code control tooling works with queries, handling filters and providing ways of adding or removing fields. It’s an approach that’s reminiscent of the query design tools like Access, or old favourites like Claris’ FileMaker Pro. Microsoft’s approach to using data in Power Fx is to use SQL-like operations; the aim is avoid the need to learn anything new to work with Power Fx, whether you’re using it to solve a problem, or you’re a professional developer maintaining and updating apps.
Code is exported as YAML, which provides a human-readable way of working with declarative statements. It’s commonly used for configuration data, but Power Fx’s mix of declarative low-code statements is a good fit. YAML is supported by GitHub’s code-formatting tools, and there are plenty of YAML tools for editors like Visual Studio Code. While they’re good enough to help you get started with working with Power Fx outside Power Apps tools, they don’t offer language-specific features that you get with dedicated extensions. As Power Fx is most definitely a programming language, it’ll be interesting to see how quickly Microsoft or a third-party developer ship Power Fx-specific tooling.
SEE: Linux commands for user management (TechRepublic Premium)
What could speed things up here is Microsoft decoupling its Power Fx compiler from Power Apps, adding it to a Visual Studio Code extension, and building a language server for its YAML. You could then use the rest of Visual Studio Code’s growing ecosystem of extensions to work with repositories like GitHub or with any other platform that uses the Power Fx language.
Building Power Fx into familiar developer toolchains is an important part of treating Power Fx apps as more than quick fixes. They’re intended to be a part of your library of business applications, and they need to be managed as such. Anyone should be able to build one, and anyone should be able to use one.
But once they’re part of your business processes they need to be maintained as the essential tools they’ve become. A good app may outlive its author’s tenure in a role, which means that exporting it as documented and managed code is essential for not only the app, but also the business. Power Fx is a first step on the road to delivering that, now it’s up to Microsoft and the Power Fx community to continue the journey.