Power Pages: What Kind of JavaScript Should I Write?

While there is a lot you can do with the out-of-the-box capabilities of list and forms with Power Pages, pretty often on projects you do run into cases where you need more than what you can do with just configuration. In these cases, Liquid and JavaScript are often used to help you meet requirements. While there aren’t too many choice to make when using Liquid, the same can’t be said for JavaScript. In this blog post, I’ll look at some different options for writing client-side code with Power Pages.

Vanilla JavaScript

Vanilla JavaScript refers to writing JavaScript without using any frameworks. Instead, you just use functionality that is supported by browsers out-of-the-box.

There is absolutely nothing wrong with using vanilla JavaScript to build Power Pages sites. In fact, and this is the start of the main theme of this blog post, if you are most comfortable using vanilla JavaScript, then it’s probably the way to go. However, if you are going to build out a custom UI, I would at least recommend exploring some of the other options I’ll present later in this post, as they can make your life a lot easier.

If your boss insists you to use a framework, but you want to stick with vanilla JavaScript, check out http://vanilla-js.com/. It’s a fun gag site that seems to present a JavaScript framework, but when you download it, the files are empty because they are really just promoting using vanilla JavaScript.

jQuery

When Power Pages was first built back in the late 2000s, jQuery was all the rage. It’s a JavaScript framework that helped iron out cross-browser compatibility, and also make it easy to interact with the DOM. Adxstudio Portals, as it was known back then, was built using jQuery, and that dependency remains to this day in Power Pages.

These days, a framework like jQuery isn’t as necessary, since browser are pretty consistent. However, since it is built into Power Pages, you can’t remove it. You also have to consider that for the last 15 years or so, this product, and the community that built on top of it, used jQuery quite a bit. So many examples, including from Microsoft and from the community, will use jQuery.

At Engineered Code, we still continue to use jQuery on projects, even new ones. We typically use it for simple form validation, or small UI changes. Since we have so many clients that were implemented using jQuery over the past 10 years, it’s a skillset our developers need to have.

If you’re new to Power Pages, and you don’t want to learn jQuery, I think you can get away with not knowing it. But I would recommend at least becoming familiar enough with it so that you are comfortable taking advantage of code available from Microsoft and the community.

jQuery and Vanilla JavaScript

One thing I prefer to keep away from is mixing vanilla JavaScript with jQuery. For example, I find it messy to see code that contains both $(‘#id’) and document.getElementById(‘id’). So my recommendation is that you pick one way, and stick with it. While some developers may know both, I think they are certainly a separate skillset, and so if you use both, anyone who has to work on it subsequently would need to know both, and it is harder to find someone who knows both versus someone who knows one of them.

TypeScript

TypeScript is a strongly-typed superset of JavaScript developed and maintained by Microsoft. It adds capabilities to JavaScript that aren’t directly supported by browsers. So, since browsers only understand JavaScript, you need to compile your TypeScript code into browser-supported JavaScript.

While you certainly can use TypeScript in replace of jQuery or vanilla JS, there is a bit of overhead to doing so, as you need to either compile manually and upload the result, or build processes to automate this.

At Engineered Code, we typically stick with jQuery for simple implementations such as form validation and small UI changes. However, we will use TypeScript when building out more complex UI using React.

React

React is a front-end JavaScript framework meant for building user interfaces. Once you learn it, it allows you to build interactive experiences with quite a bit less custom JavaScript.

Microsoft uses React to build many of its applications, such as model-driven Power Apps. This makes React a popular framework in the Microsoft ecosystem. Microsoft also has the Fluent UI, which is a user experience framework for building applications, and supports various platforms like Windows, iOS, Android and macOS. There are React components for the Fluent UI, and you’ll over seen these used in PCF controls, as the Fluent UI is used to build model-driven Power Apps, so you can make your controls feel much more native.

When we are asked to build more complex user interfaces in Power Pages, our go-to is building a React app with TypeScript. TypeScript helps avoid a lot of simple errors like incorrect types, and React allows us to build the user experiences much quicker. However, we don’t often use the Fluent UI. Power Pages is built using the Bootstrap UI framework, not Fluent UI, so if you use Fluent UI, you work might look out of place. Of course, you can customize the Fluent UI to make it fit, but often that is more work than just using Bootstrap.

Other Front-end Frameworks

There are other popular front-end frameworks, such as Angular and Vue.js, and any of these can work with Power Pages. As an example, the Power Pages template that work with Dynamics 365 Marketing was built by Microsoft using Angular. My guess is that is because the team responsible for building it was probably more familiar with Angular.

So, if you’re embarking on a Power Pages project, and you know you’re going to need to build out some complex interfaces, the main thing to consider is the skillset of the team, both the current team, and perhaps whatever future team might need to support it.

PCF Controls

PCF Controls, also known as code components, are UI controls that adhere to the Power Apps Component Framework, and are supported for use in both model-driven and canvas Power Apps, as well as Power Pages.

Within Power Pages, PCF Controls can be used in a variety of ways: they can be used to replace the controls for an individual field on a form, as a replacement for a list or subgrid, or they can be included directly using Liquid.

Often we see PCF Controls built using React and TypeScript. So that brings up the question: if you want to build out a custom UI in Power Pages, should you add a React app directly to your Power Pages site, or should you create a PCF control and use Liquid to embed it.

Again, to me in this case there really isn’t a wrong decision – I’m usually guided by the skillset of who is doing the work. I think building a PCF Control comes with additional overhead, and requires additional knowledge – the code needs to be uploaded using the pac command line utility, and building a PCF Control requires more setup than just a simple React app. However, if the developers are already comfortable with PCF Control development, then I think it is a fine approach.

Another consideration is if the PCF Control could be used elsewhere, for example in a model-driven or canvas Power App. In an ideal world, if you build some useful functionality, it can then be leveraged in other apps. However, the reality is that the UI frameworks for each of these different places is different enough that often a PCF Control meant for Power Pages may not work well in a model-driven or canvas Power App. So while reuse is something to consider, it wouldn’t be the major factor in my decision.

Do What You Know and Be Consistent

Of course, as with everything, the answer is always “it depends”. However, I think it most cases when you are trying to decide what type of JavaScript to use to build Power Pages, there aren’t too many wrong choices. To me, there are two main keys: understand what is the skillset of the team, both now, and in the future, and be consistent. That’s going to put you in the best position to successfully deliver the project, and support it over the long term.

 

The post Power Pages: What Kind of JavaScript Should I Write? appeared first on Engineered Code.