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.
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.
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.
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, 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.