Run JavaScript Function vs Web Automation

[BLawless]

Hello! I am trying to understand some of the deeper concepts behind Power Automate Desktop (PAD) when it comes to web automation actions. I see that PAD offers the ability to perform form and UI operations such as clicking on a button and populating a text field. But I also see an option to "Run JavaScript function on a webpage" which can allow you to perform the same actions, and possibly others that are beyond the limitations of the web automation actions.

For example, if I wanted to click on a button on a page, I could use the "Web Automation">"Web form filling">"Press button on web page" (optionally "Web Automation">"Click link on web page" if the button is implemented appropriately) OR I can perform "Web Automation">"Run JavaScript function on web page" with the following script:   

document.querySelector('[/*CSS SELECTOR HERE*/]').click()

Another example would be if I wanted to fill out a text field I could use "Web Automation">"Web form filling">"Populate text field on a web page" and select the appropriate element and supply the given text, OR I can perform "Web Automation">"Run JavaScript function on web page" with the following script:   

function ExecuteScript() { 
document.getElementById(/*ElementID Here*/).value = "Some Text I Want To Insert";
}

Note that for most applications I can perform the "Run JavaScript function on a web page" operation as a fully enclosed function (function name and everything) or a single line command.
My point of confusion sits with not understanding the reasons for opting for an automation action over running a JavaScript function. What details should I take into account when deciding between achieving an action through one operation over the other? Are there any performance benefits that should be accounted for when choosing which implementation to use?  Any information that would help expand on this narrow concept would be greatly appreciated. 

[yasunm02 · Accepted solution]

Hi @BLawless 

IMHO this kind of confusion results from considering only the 'tech' aspect of the product, and not the broader marketing perspective (marketing not as advertisement only, but product concept, strategy, positioning, etc.), which I believe is the most important here.

As part of Power Platform, PAD is a low-code solution intended to provide RPA to citizen developers. This is the product concept and main target market. That's why graphic automation actions are the primary option to build flows, and not a code screen. But Microsoft noticed Power Platform could also be an useful tool to pro devs, and that's why options such as 'Run JavaScript function on a webpage' in PAD, or integration with Python and R in Power BI, for example, were included. By doing that, Microsoft broadens the product's market.

Those two publics - citizen developers and dev pros - 'coexist' in PAD, and you have functionalities for both of them. So if you're a dev pro and considers running a JS fuction more useful, go with it. Instead, if you're a citizen developer and don't know code, go with predefined actions..

[BLawless]

Following up here with some additional remarks and questions regarding @yasunm02's resourceful and thorough response (thank you for getting back to me so quickly BTW):

---

@yasunm02 wrote:

As part of Power Platform, PAD is a low-code solution intended to provide RPA to citizen developers. This is the product concept and main target market. That's why graphic automation actions are the primary option to build flows, and not a code screen. 

---

This is actually why (despite having programming experience in Java, C#, JavaScript, C++, Swift, etc.) I'm using Power Automate Desktop. It's a great tool to rapidly prototype automations which I can then use as a "skeleton"/outline for an equivalent automation in a full on IDE. It allows me to test a proof of concept without having to do a lot of heavy coding. 

---

@yasunm02 wrote:

IMHO this kind of confusion results from considering only the 'tech' aspect of the product, and not the broader marketing perspective (marketing not as advertisement only, but product concept, strategy, positioning, etc.), which I believe is the most important here.

---

There are some downsides to this though when we neglect the technical aspect, namely the performance hit from the UI elements during debug time and the responsiveness issues of the editor. This is potentially related to either a memory leak issue or, and I haven't confirmed this, maybe it's due to PAD being a browser-based editor with some form of web wrapper executable where your workflow is saved to a central server and not a local instance. That's what it seems to behave as from my experience, especially when I observe the flow downloading each time you wish to execute it (and UI click and drag operations lagging to a noticeable degree). 

This performance concern actually begs the question that I didn't place as much significance on in my initial inquiry.

While I marked your answer as "correct" because it technically is the right answer when trying to address when we should be favoring one operation over its analogous coding equivalent in PAD from a "best practices" standpoint, it would help me if you could perhaps expand on the performance difference between a PAD flow performing a single "Run JavaScript on web page" action containing several operations and PAD flow performing the equivalent operations using other actions.

For example, to clarify, if I wanted to:
1. Get a value from a web page
2. Click on a button using a CSS Selector
3. Insert text into a textbox, and then
4. Press another button in the web page

I could either run a single "Run JavaScript on web page" action with all of those actions encapsulated in a single JavaScript function code block, or I can run those as separate actions using the various actions in the Web Automation portion of the action library.

Which would have a better runtime performance?  (For the sake of this argument, on top of ignoring "ease of use" factors when it comes to non-coding actions, let's also ignore the debugging and variable assignment benefits that PAD provides in the flow and focus strictly on runtime performance as most of these items can be handled with JavaScript analogs for variable assignment and try-catch blocks). 

[yasunm02]

Hi @BLawless 

Well, that'a good question to which I don't have an instant answer. It's certainly worth a test using timers to find out if there's a difference and whether this is relevant, didn't find anyone who ran this kind of test in community threads. If there's difference and it's in seconds scale, PAD's 'Get current date and time' action could capture it. Otherwise code or Excel would easily help.
Secondary to your question, but it's worth of note that better (faster) runtime has a limit on automation works due to factors such as page/apps load times, which is sensitive to internet connections, hardware config etc. Many times I have to insert delays actions in my flows to avoid errors because actions take place before the field is there.
My two cents.

[BLawless]

Thanks @yasunm02 for replying back and bringing up a great suggestion on how to benchmark this.

If I have time and energy I will devise a test that makes use of the "Get Current Time" action, loops of the analogous operations, and a bit of logging skills that I've been learning over these past couple of months. I hope to report back with some insightful results and detailed testing procedures for others to recreate for validation purposes.