Hallo Steffi,
danke für die ausführliche Beschreibung. Das mit der Textdatei war mir neu, und es entspricht ja dem, was ich hier als Pseudo-Code notiert hatte: Eine tabellarische Zuordnung von Mustern zu Zielen.
Grundsätzlich darf jede:r nutzen, was sie/er möchte. Und auch darüber schreiben, denke ich. Wenn man nicht darüber schreibt, erfahren andere nicht, was möglich ist. Deshalb noch mal Danke für deine Erläuterungen zu Hazel.
Zu deinen “Limitationen JS und DT”:
- Ja, JXA ist nicht das, was “man von einem Browser erwartet”
- Ja, es hat kein DOM-Objekt und bietet eigentlich keine Webseitenmanipulation
Aber: Wer bitte braucht ein DOM in DT? JXA heißt ja nicht “JavaScript im Browser”, sondern “JavaScript for Automation”. Und diese Aufgabe, nämlich das Automatisieren dafür eingerichteter Apps auf macOS erfüllt es mE besser als AppleScript. Mit dem hättest du vielleicht vergleichen sollen – das hat nämlich auch kein DOM und keine Webseitenmanipulation, trotzdem nutzen es viele für das Automatisieren von DT.
-
Konzepte wie async/await und Promise.allSettled fehlen in JavaScriptCore
Mag sein. Aber wer braucht das für das Automatisieren von DT oder irgendwelchen Apps? Diese modernen Konzepte fehlen auch in AppleScript, btw, und trotzdem benutzen es viele Leute.
-
Fetch und XMLHttpRequest lassen sich weder in AS noch in JXA direkt abbilden. In beiden Fällen muss man auf NSData und seine Methode initWithContentsOfURL via Objectve C zugreifen. JXA braucht dafür kein AppleScript, und man braucht auch keine “externen Tools”.
Ich weiß nicht genau, was du damit sagen willst. Aber grundsätzlich ist Scripting, egal von welcher Applikation, ein extrem unsicherer Prozess. Man kann eigentlich, dank doShellScript alles machen, was einem:r auf der Kommandozeile möglich ist, und zwar von einem Script aus, das in DT läuft. Schlimmer noch: Es ist sogar möglich, Befehle als root auszuführen. Und zwar von jedem JXA/AS-Script aus. Yuck.
Jein. Das Ausführen von Automationen in anderen Apps erfordert permissions. Aber die müssen nur einmal erteilt werden. Und das hat nichts mit JXA zu tun, das gilt auch für AppleScript. Und was sind “fremde Ordner”? Für die sollten dieselben Zugriffsrechte wie für alle anderen Apps auch gelten. Abgesehen davon: Entweder möchtest du es sicher (wie im vorherigen Punkt) oder nicht. Da müsstest du dich entscheiden. Bzw.: Mit Scripting geht nur genauso sicher wie auf der Kommandozeile.
- Warum sollte man intelligente Gruppen nicht bearbeiten können? Es gibt die Properties
searchPredicates und searchQuery, mit denen sich die Eigenschaften einer intelligenten Gruppe festlegen lassen. In AppleScript und in JXA. Was du mit “Sucheringstellungen” meinst, weiß ich ebenso wenig wie was “Erweiterungen beeinflussen” in diesem Zusammenhang bedeutet.
Performance bei großen Datenmengen: Beispiele? Was und wie groß sind die “Datenmengen”, und was sind die Operationen? Und womit vergleichst du die Performance? JXA ist sicherlich nicht langsamer als AppleScript, denn beide benutzen AppleEvents. Und beide sind sicherlich langsamer als native Zugriffe zB auf Datenbanken.
Kein Multithreading – naja. Braucht man das im Zusammenhang mit Applikationsautomatisierung? Besser noch: Will man das, angesichts des Aufwands bei der Programmierung?
Was du unter “Automatisierung” listet, liest sich nett, hat aber auch nix mit JXA und dem dafür vorgesehenen Anwendungsbereich zu tun. Natürlich hat die Browser-Version von JS Event-Handler (document.addEventHandler). Und andere Varianten von JS haben die eben nicht – schließlich hängt das von dem System ab, auf dem sie laufen. Wenn man mag, kann man natürlich FSEventStream aus Apple’s Core Services verwenden, um sich so etwas zu basteln. Wieder mit der ObjC-Bridge.
“gleichzeitig etwas ändern geht nicht” – Ja, und? Warum muss das gleichzeitig sein? Wer braucht das in diesem Zusammenhang?
“extrem langsam” – Da du das jetzt zum zweiten Mal erwähnst, hast du sicherlich fundierte Performancedaten und Vergleiche mit anderen Verfahren zur Applikationsautomatisierung?
Dein Vergleich Hazel vs JXA ist partiell etwas schief.
“OCR auf PDFs nicht möglich direkt” Wieso “direkt”? Was meinst du damit? JXA kann genauso gut DT/Abby für OCR benutzen wie Hazel:
if (record.wordCount() === 0) {
ocrRecord = app.ocr(record.path(), {
file: record.path(),
waitingForReply: true});
app.delete({record: record, in: record. parents[0]});
}
“Dynamische Regeln”: Brauche ich nicht, wenn ich eine tabellarische Zuordnung habe. Das hatten wir schon – da gibt es keinen Unterschied zwischen Hazel und JXA/DT, außer der fehlenden Synchronisierung via Cloud. Was an DT liegt, nicht an JXA.
“Textinhalt aus PDFs auslesen”: Inwiefern “langsam” (das ist der dritte Hinweis auf Performance-Mängel ohne Zahlen und ohne Vergleich)? Die Frage ist doch, wie die Software das Textlayer aus einem PDF ausliest. Meine Vermutung: Hazel und DT (also in dem Zusammenhang auch JXA und AppleScript) bedienen sich Apple’s PDFKit und dessen Property string am PDFDocument. Wenn das so ist, dann sollte es keinen nennenswerten Geschwindigkeitsunterschied geben. Oder wie liest Hazel deiner Meinung nach den Text aus einem PDF?
Wie gesagt: Jede:r soll nutzen, was sie:er mag. Und ich habe was über Hazel gelernt, was ich nicht wusste. Ich wollte das Programm keineswegs schlechtreden und hatte extra “wenn ich mich nicht irre” eingefügt.
Aber Vergleiche von Äpfeln und Birnen, wie du sie her anstellst, helfen nicht weiter. Es gibt nicht “das” JavaScript – es gibt ECMAScript (standardisiert) und es gibt Implementierungen in bestimmten Umgebungen, die alle ECMAScript umsetzen. Zusätzlich können sie bestimmte APIs (XMLHttpRequest, zB) oder globale Objekte (DOM, zB) implementieren. Das macht JXA auch mit Application und $. Und natürlich nicht mit DOM etc. Aber wenn du willst, kannst du zB mit doJavaScript in einem DT-Script ein geöffnetes HTML-Dokument manipulieren. Nicht schön, aber möglich.
JavaScriptCore mag aus 2015 stammen, aber es hat die wesentlichen Teile von ECMAScript 2025 implementiert, zB Set.prototype. Apple zieht das vermutlich deshalb nach, damit es nicht für Safari und sein OS zwei verschiedene JS-Engines pflegen muss. Promise und die verwandten Themen sind allerdings in JXA nicht so verwendbar, wie sie es sein sollten. Keine Ahnung, woran das liegt und ist mE für das reale Leben zurzeit nicht relevant.
(mit Abbyy/DEVONthink)
(nicht möglich direkt)
Teilweise
