Observation: JavaScript (JS) via Python (py)


As a software centric engineer finishing up my second decade of professional work I knew python from the early 2.x versions. Watching and usiyit for automation mostly on winOS (starting from good old Windows 2000). As my personal Hardware moved more and more to the Apple ecosystem I was always eager to get automation on iOS/iPadOS. This summer vacation I set myself the challenge to dive deeper to automation with Java Script on iOS - after quite some years of playing around with Pythonista. Most pro apps like Drafts do have a quite impressive JS framework for automation sometimes with great libraries (TADpole) and Examples and an open and helpful community (here or over at forums.getdrafts.com).

After the first quarter of JS on iOS my aversion to JS as a first language to learn is still controversial.

Firstly because many of the core is in fact based on C as a programming language- good for all who know that .

Secondly because most of the tutorials are heavily targeted for HTML usage or add the great and convenient nodeJS runtime - both do confuse users who just want to learn automation.

Thirdly because the higher abstractions in coding (classes, protocols, user interfaces) are not obvious in JS.

This is why I still would recommend Python (Py) as a better choice for first language experience.

This results in a threefold call to action:

One: To the users to look at the language and reply their insights and evaluation (JS vs PY) to the others.

Two: To the python developers to acknowledge iOS, Android and iPadOS as a target plattform and start releasing on it (Pyto is an iOS App with all sources on github, beewares Tofu is a python project that has this in mind but is pretty far from completeness

Third: To the app developers to reconsider the only JS approach in their apps. There could be a not so obvious back door via Python transpiration to JS if the full Python engine or the micro Python engine is too much effort.

What do you think?

The two structural mountains of language design are Lisp and C. (Functional composition vs sequential state mutation)

JavaScript and Python are both descendants of C in that sense.

In fact, to be honest, Python makes composition of pure functions harder than JS, and is in that sense a more direct inheritor of the C tradition than JavaScript is.

That’s fair, and worth doing something about. In the meanwhile the first 9 chapters of Eloquent JavaScript focus on the language rather than on the DOM embedding.

I’m not sure that object-oriented construction is a particularly good match for most light automation. A bit too techie, fragile, and time-consuming.

Generally, Python is a good tool for some purposes (though more marred than enhanced by some of the more opinionated and procrustean ‘Pythonic’ currents) but is not really an option for a central role in iOS/macOS automation.

[JSContexts](https://developer.apple.com/documentation/javascriptcore/jscontext?language=objc) are baked-in parts of Apple OS systems, and can run in-process (in the omniJS and TaskPaper architectures for example) in a way that Python interpreters can’t.

This is not a decision made by scripters, it’s a feature of Apple’s software architecture, and expresses the pivotal role of Safari.

PY interpreters are useful adjuncts, but not equipped for centre-stage, not least because they are fragmented targets.

Any given Apple OS build has a standard built-in version of a JS interpreter.

Python on the other hand - 2.7 ? 3.7 ? 3.8 ? installed by brew ? something else ? etc. etc.

Apple is the author of the JavaScriptCore JSContext, the development of Python interpreters is outside its control.


ok, that’s a very good argument.

the Drafts API is completely based on class/objects
And I think that is great.

JS quickly get to the magical stage where {[ dd ( is part of the code.

It’s a good solution on the supply side (API author)

less good, I think, on the demand side.

(Productive and reliable automation of personal work – without hours lost in bug-chases down rabbit-holes – by users).

To put it another way, consuming objects wastes no time, but building and debugging nested objects with hidden state is seldom likely to be worth the cost for users.

Nested functions are more than enough for casual scripting.

Fully agree!! There is a huge gap here. Would be good to have more tutorials focused on automation and apps like drafts, scriptable, etc


Ok, I have to think about that.
Thanks for the feedback.

Pyto starts to work better than first expected … bookmarks module lets you work from everywhere in the Files.app including file providers. Think like Dropbox or Working Copy (git)