We’re about a decade out from widespread availability of ASObjC, and I was wondering if anyone had any thoughts about the ongoing downsides of incorporating ASObjC into a script library codebase. The last major changes to general ASObjC usage were in macOS 10.11 El Capitan.
I have several fairly large script libraries that I developed in plain AppleScript, and have gone through substantial effort keeping them ASObjC-free over the years (explained below). This has necessitated a lot of do shell scripts, some compiled helper binaries, and some other very convoluted work-arounds.
I initially avoided ASObjC in script libraries because of OS compatibility and limited bridging support of some types, but these are no longer significant issues (some plain AS types are still not bridged & are not likely to ever be bridged, so there is still some value in plain AppleScript handlers).
However, the biggest reason I’d held off over the years was the noticeably long cold-start times (~200 ms) for scripts calling any ASObjC code when run outside of a script editor-like environment. This includes any usage of /usr/bin/osascript (including shell scripts AND AppleScript’s own Script Menu, which calls osascript under the hood through NSUserAppleScriptTask).
Fortunately, I’ve since moved over to using FastScripts, which among other benefits, pre-loads the ASObjC terminology (as of v3.2.3) to remove any delay in calling ASObjC code.
Now, I run all my AppleScripts using either FastScripts’ menu or its scripting interface (which handles CLI applications, shell scripts, other AppleScript instances, BetterTouchTool, etc. with a little effort), so this is no longer an issue.
Bottom line – are there any other reasons to avoid ASObjC in big script libraries?
I probably have one of the largest AppleScript libraries in the world. This does not mean that it is managed as a so-called AppleScript Libraries file, but in the sense that it is managed by dividing the huge amount of scripts that have been written into themes.
Its library is divided into categories and maintained on a daily basis.
What I try to do in this library management is to prepare both ASOC code and Vanilla Script code as much as possible.
Sorting may be an obvious example. ASOC’s sorting routines are fast and highly functional. However, it can’t handle AppleScript-specific objects (e.g. document). On the other hand, Vanilla Script’s sorting routines are reasonably fast, but you can’t expect them to be as fast as ASOC.
Now, let’s take a look at the actual project… If you write a GUI application for the Mac App Store in AppleScript and include a sorting routine in it, there is a case where “ASOC was slow but it became faster when replaced with Vanilla Script routine” at the stage of making various adjustments. The reverse is also true.
Thank you – it’s interesting to hear you say that. Appreciate the insight.
I was planning on moving (nearly) everything over to ASOC, but wanted to take the opportunity to improve the API for version 2.0 of my script libraries.
I’m torn, because I still find that AppleScript doesn’t have an ergonomic way to name handlers with optional parameters while still supporting Script Debugger’s autofill. I’d put in a feature request for Script Debugger to support some sort of documentation comments for smart help for handler parameters.
With that, handlers could be made more flexible by accepting a single record as an argument while still having useful autofill. So instead of having multiple handler variations, e.g.:
