Using Javascript as a language for Export scripts

Using Javascript for an exporter script would be very nice indeed. Node.js has a lot of modules but requires the user to install it under Mac OS.

Another solution would be support for JSC in Hype…

/System/Library/Frameworks/JavaScriptCore.framework/Versions/Current/Resources/jsc

I found these articles but haven't used it until now

… and …

1 Like

I was just playing with trying to use the
osascript shebang in a .sh file and using JS.

#!/usr/bin/env osascript -l JavaScript

function run(argv) {

console.log('JSON.stringify(argv)')

}

Did not work ( yet)

Normal osascript works though.

#!/usr/bin/env osascript

say "hello"

Also we should note that Javascript is a first - class citizen on Mac now. Which means it’s scope is well sorted to be used in an export script with file system access. Although JXA documentaion is crap you can bridge it to Objective - c which I do all the time. ( And I know , not for the faint hearted )

Just figured out that the function can be setup similar to the Automator function in the ‘Run Javascript’ action.

#!/usr/bin/env osascript -l JavaScript

function run(input, parameters) {

 

return input;

}
1 Like

JXA is available on the Mac. It’s nice. I’m not sure how much Apple will support it though. Aside from the initial launch, has there been much development?

@MaxZieb – what is the feature you’re looking for? I originally wrote Wrapping in JXA. And like @MarkHunte, I’m also not a fan of Python. Ha ha.

Boy is that slow… just tried the wrapper and previewing feels like on a steam boat. Not looking for anything in particular. We are just exploring the use of Js in exporter scripts as it leverages the knowledge web developer have. Most of these don’t use Python.

Just to follow if your script is running and what is written back to StdOut you can use
log stream --style syslog --predicate '(processImagePath contains[c] "hype") && (category != "security_exception")'

That was my logic for using JXA. Ultimately, I ended up building a Swift based application, but the JXA version also works. For some parts I simply had to use shell commands to get things done, but overall it was nice. Hopefully Apple continues to support it.

But so far, it doesn’t look too good...

1 Like

Thanks. I already have that running…

in console I get mulitple outputs

A couple here

Hype2 output: --replace_url, HYPE-596.full.min.js, --url_type, 1, --is_reference, False, --export_uid, 5184FC91-E661-456D-95C4-0E03292C9A06-67084-0000A9776D5739F5, --is_preview, False, --hype_version, 3.6.7, --hype_build, 596


`Hype2	output: --modify_staging_path, /var/folders/zz/klwh366n1t743d60fg51qqz5zy_gk0/T/com.tumult.Hype2/TemporaryItems/(A Document Being Saved By Hype)/Untitledss, --destination_path, /Users/epdtemp/Downloads/Untitledss, --is_preview, False, --export_uid, 5184FC91-E661-456D-95C4-0E03292C9A06-67084-0000A9776D5739F5, --export_info_json_path, /Users/epdtemp/Library/Containers/com.tumult.Hype2/Data/Library/Application Support/Hype/Scratch/HypeScratch.nMK3vq/5184FC91-E661-456D-95C4-0E03292C9A06-67084-0000A9776D5739F5.1.export-info.json, --hype_version, 3.6.7, --hype_build, 596`

Just need to figure how to interact with it…

You get all the arguments in input as an array. Just run over them and if they start with -- they are a new key else they are the current value for the current key. This way you can create an object with named keys from them. You then return modified versions to StdOut as Hype is running all the settings through your script. To peak at the expected formatting just look at the exit_with_result function in the Python sample script (Json and a custom delimiter made of equal signs);

But this is soooo slow compared with Python so… basically dead to me if there isn’t a more performant solution.

Lol..

I know when I have used JXA with OBjC it can be fast processing files but thats normally for my needs.
Does speed matter here?
When you say slow.. in what sense..?

Well, just hitting the preview button and having the result pop up in the browser of my choice using an export script based on osascript -l JavaScript. That takes 4-5 times longer then usual on my MacBook Pro. You can literally see how slow it is when you follow the log with the method from above.

Ah I see what you mean. I think this is because we are going through the osascript (shell). Which will then use the same process as automator runner…

I’d be curious if running via node is faster for javascript?