I don’t like programming in AppleScript in general, but there is one construct that I’ve always liked. Because I’m not a computer scientist, I don’t know what to call it,1 but I can give an example that came up recently:

applescript:
tell application "System Events" to get the name of every process whose visible is true


The System Events preamble doesn’t matter. It’s the

    _____ of _____ whose _____ is _____


that I find interesting. It’s compact, easy to understand, and, I would say, the most useful example of AppleScript’s “English-like” syntax.

In trying to write the JavaScript for Automation (JXA) equivalent of this, I learned (sort of) how parenthesis work in JXA when dealing with properties and filters by reading this excellent article by Christian Kirsch. I’m writing about it here before I forget.

applescript:
tell application "System Events" to get every process


This returns a long list—over 100 items—which I’m going to condense and format as one item per line:

{application process "loginwindow" of application "System Events"
application process "ViewBridgeAuxiliary" of application "System Events"
application process "NotificationCenter" of application "System Events"
.
.
.
application process "Dictionary" of application "System Events"
application process "com.apple.WebKit.WebContent" of application "System Events"
application process "System Events" of application "System Events"}


The JXA equivalent is also pretty simple:

javascript:
Application('System Events').processes();


It’s result is recognizable as the JavaScript equivalent to the AppleScript result:

[Application("System Events").applicationProcesses.byName("loginwindow")
Application("System Events").applicationProcesses.byName("ViewBridgeAuxiliary")
.
.
.
Application("System Events").applicationProcesses.byName("Dictionary")
Application("System Events").applicationProcesses.byName("com.apple.WebKit.WebContent")
Application("System Events").applicationProcesses.byName("System Events")]


So far, so good. Now let’s add one piece of complexity. Instead of returning a complete description of each process, let’s get just their names. In AppleScript, that’s easy:

applescript:
tell application "System Events" to get the name of every process


The the isn’t necessary—get name of every process would work just as well—but it adds to the readability. This returns a list of the same length but with simpler items.

{"loginwindow"
"ViewBridgeAuxiliary"
.
.
.
"Dictionary"
"com.apple.WebKit.WebContent"
"System Events"}


In JXA, we do this

javascript:
Application('System Events').processes.name();


to get a JavaScript list of the same items:

["loginwindow"
"ViewBridgeAuxiliary"
.
.
.
"Dictionary"
"com.apple.WebKit.WebContent"
"System Events"]


To me, the tricky part of this is how we removed the parentheses from processes before invoking names. Trying

javascript:
Application('System Events').processes().name();


results in an error:

TypeError: Application('System Events').processes().name is not a function.


This is kind of misleading, as it suggests the problem is with name when the problem is really with processes(). We know from our previous example that

javascript:
Application('System Events').processes();


returns a JavaScript array. It’s an array of processes, yes, but it’s still an array. And name() can only be applied to processes, not to an array of processes. So to get around this while still providing reasonable compact syntax, JXA provides processes without the parentheses as an object specifier to which name() can be applied on an item-by-item basis. Again, see Christian Kirsch’s article for a better explanation.

Now we go for the last step. In AppleScript, it’s

applescript:
tell application "System Events" to get the name of every process ¬
whose visible is true


which returns (not condensed)

{"Messages"
"Calendar"
"Finder"
"Reminders",
"iTerm2"
"BBEdit"
"Mail"
"Contacts",
"Preview"
"Safari"
"Script Editor"
"Dictionary"}


(While it’s not the point of the post, this is the list of apps I happen to be running right now—the ones in the Dock. Invoking this line of AppleScript at some other time would return a different list.)

In JXA, the command is

javascript:
Application('System Events').processes.whose(
{visible: true}).name();


and the result is

["Messages"
"Calendar"
"Finder"
"Reminders"
"iTerm2"
"BBEdit"
"Mail"
"Contacts"
"Preview"
"Safari"
"Script Editor"
"Dictionary"]


Because the name of the process is what we want to return, name has to go last in the chain of calls, and it’s the one that gets the parentheses. We’re applying the whose filter to the processes, so it has to go after processes. The properties we’re filtering on (just visible in this case) are set up as a JavaScript object that’s passed as an argument to whose.

Suppose we had two criteria for our filter? Let’s say we want all the visible processes that start with the letter M (which will return just Mail and Messages). In AppleScript, it’s easy to add an extra clause:

applescript:
tell application "System Events" to get the name of every process ¬
whose visible is true and name begins with "M"


In JXA, the syntax gets nasty:

javascript:
Application('System Events').processes.whose(
{visible: true, name: {_beginsWith: "M"}}).name();


I think it’s obvious that we need to add a second piece to the object passed to whose, but that it should be

javascript:
name: {_beginsWith: "M"}


is anything but obvious to me. The rule for constructing this sort of filter—where a function is applied to the property—is that its key is the property we’re going to filter on, and the value is yet another object whose key is the function to be applied to the property and whose value is the argument to that function.

But wait, there’s more! The name of the function comes from the AppleScript terminology, where multi-word functions are smashed together using camelCase, and the whole thing is preceded by an underscore. Thus,

applescript:
name begins with "M"


becomes

javascript:
name: {_beginsWith: "M"}


Simple, right?

The more I delve into JXA, the more I think I should stick with AppleScript and get more clever about using do shell script with Perl or sed for string processing.2

1. Something to do with properties and filters, I imagine.

2. By the way, I know there are AppleScript libraries for string processing. Ages ago, I used Satimage’s Smile libraries, but as Apple began breaking longstanding pieces of automation, I got leery of using third-party add-ons. As far as I know, though, Smile’s text and regex functions are still working just fine.