The main cost of Drafts script actions at the moment is the rather slow (and slightly feed-back impoverished) cycle of testing and adjusting:
Several levels of tapping to select and edit a script action, then
ditto to read any console.log or error output, and
often limited or absent error information.
An important culprit here is the use of the older var rather than the more current let.
Among other advantages, the newer let gives a beginner helpful error information, where the old legacy var gives none.
Imagine, for example, that we accidentally reuse a variable name.
var a = '123e4567-e89b-12d3-a456-426655440000';
// then, somewhere lower down ...
var a = 42; // We've now lost the UUID, but we get no warning or explanation at all
var just destroys the value in the first assignment, and gives us no warning of what has happened.
let is very much more helpful:
it triggers a red ‘!!’ warning in the code editor, as soon as we make the mistake, and
if we run the code, it gives us an explanatory error message, with line number:
SyntaxError: Cannot declare a let variable twice: "a"
Line number: 9
let a = "123e4567-e89b-12d3-a456-426655440000";
// then, somewhere lower down ...
// We get an instant red !! warning in the editor if we now type this:
let a = 42;
// and an explanatory error message with line number if we run it.
@agiletortoise I’m not sure whether the use of var in the API documentation examples is a legacy thing (compatibility with an earlier Drafts/JS ?) but perhaps it would be helpful to do a (var -> let) search replace ? It would allow beginners to immediately get more help from the Drafts code editor, and from the error panel.
(In nearly all the examples, const would, of course also work, and might have advantages (we can declare an object as a const, and still update its properties – we just can’t change the reference to a different object), but perhaps simpler for beginners not to have to deal with that choice too soon ?)
const is the ideal default (executes faster, encourages avoidance of unnecessary mutation)
let is needed for any real mutation (not needed for any object property updates)
Both give helpful error messages, and editor warnings, where var gives nothing at all, and just leaves us in the dark.
Good tips. Generally speaking, using the latest features of a language are nice and offer some benefits, but aren’t the best way to provide examples, because they make it look alien to people looking at common example and tutorials on the web, so I try to avoid those features in code examples.
Your tips and tricks have been great for advanced users, but to a novice things like Array reduce are scary and harder to read. Similarly, sprinkling an example with optimized uses of var, let and const tend to make it less approachable to the non-programmer because they are faced with another set of concepts that make them feel like the are doing it wrong if they don’t understand the nuances differentiating them when a plain old var would just work fine.
For the most part, in the types of simple scripts people are writing in Drafts, the performance differences are negligible.
Performance differences are certainly negligible – JSC is unlikely to be the bottle-neck anyway in running an action.
I’m not sure, though, that the friction and the time-consumption in the test -> read message -> re-edit cyle are really negligible at all at the moment, and it seems a pity to deprive beginners of helpful error messages …
But you have your reasons – I just wanted to check that the use of var was deliberate – sounds like it was.
Perhaps we can just agree to disagree on that one
( Where you write “plain old var”, I think we might do better to substitute “plain old let”, but the stakes are not high – just a bit more time wasted in confusion and debugging – and you seem to feel that that’s a price worth paying for congruence with older teaching resources … despite the clash with newer teaching resources ? )
As long as people know that they will get more help from let (and const), the influence of the documentation examples shouldn’t be too disabling.
The point, however, is that the cost / advantage balance simply fails if the main advantage is ‘compatibility with learning materials’.
Older materials use var, newer materials use let. In other words there is a compatibility cost in either direction, and with time the use of var will only get more costly and confusing in these terms.
That leaves us with just the utility value of let vs var.
let has a simpler and more intelligible behaviour, and provides both editor warnings and run-time explanations.
var has confusing properties, and offers no editor warnings or run-time explanations.
I have no interest in an argument about programming best practices. As far as I’m concerned, for the purposes of productivity automation, if it does what you want it to do than it’s well programmed.
Absolutely, and ditto – I’m not a programmer either, which may help me empathise a bit more with the predicament of other non-programmers, who, like me, need what is simpler more than we need what is more traditional.
(All of the major desktop browsers have caught up with const and let)
Precisely because var has some different and peculiar properties, and it’s not impossible to inadvertently create code which depends on leaky or eccentric scoping, I certainly wouldn’t generally recommend global search and replace for arbitrary sets of code. It just happens to be feasible for Greg’s set of documentation examples.
But if you are writing fresh code, sticking to let and const will allow the editor and interpreter to flag up problems that slipped through unnoticed with var.
I agree fewer interactions would be better. However, for writing and managing my actions, I now use a script that sources the JS from a specific Draft UUID and uses eval() to run it. I don’t really notice a speed difference. It also lets me use library scripts that are included in the final execution.
Someday I’d love to be able to edit the scripts in a proper code editor like Textastic. With my Python scripts I am able to open them in Pythonista, Working Copy, or Textastic – all without moving any files or doing any copy/paste. It’s so cool!