Native JS (es5) features "randomly" not supported in some environments (AE2020)

[jeroenr13836525]

Hey guys,

We are currently working on writing an extension for AE, however, we are running into bugs that we cannot explain.

In our code, we use the .filter method on an array. Something that should be possible in AE19 and above, and in fact, it works flawlessly - on some computers.
In the office we run 8 computers with AE, all running the newest updated AE2020 version, and on about half of them it works, where the other half says that .filter is undefined.

We tried reinstalling everything, tried it with/without extendscript toolkit, we tried it between different versions of windows and mac, but it appears to be completely random.

We had a look at the expression engine (legacy or JS) but that appears to only affect expressions as expected and not scripting.

So, bottom line, higher js commands like .filter seem to work, but depending on your system they sometimes appear to not be included in the scripting engine.
Extremely weird.

Does anyone have any clue as to what could cause such a discrepancy between installations?
Any help is very much appreciated

[Mylenium]

At least where ESTK is concerend I could imagine compatibility issues if older versions of Adobe products are installed and the language and debug levels are set accordingly. It might be worth investigating that first.

Mylenium

[jeroenr13836525]

Valid point. The weird thing is however that even some machines with all kinds of versions simultaneously DO work, while another machine which never installed any adobe programs besides the newest AE does NOT work.
Incredibly frustrating.

What exactly do you mean by 'language' in this case though?

[Mylenium]

You can set the ECMA script compatibility for some script engines as far as I remember. That may only apply to some versions Photoshop, Illustrator or InDesign, though. I'm really not up to speed on all of that.

Mylenium

[Justin Taylor-Hyper Brew · Accepted solution]

ExtendScript and Legacy Expressions are ES3 based, so filter/map/reduce/etc will not exist there. The new JavaScript Expression Engine and CEP JavaScript is ES6 based so you can use those methods.

If you're seeing ES6 functions in either of those ES3 environments, it's because some script has modified the prototype which is very bad, and can cause the inconsistencies that you're seeing. Try launching AE on all your machines with the same Expression settings and WITHOUT any scripts or extensions open, and you should have the same results.

If you want, you can then start launching them one by one till you find the culprit, and then notify the developer.

[Tomas Sinkunas]

I second @JustinTailor - AE scripting still uses old ES3 standard, so there's no native support to forEach/map/filter etc. functions. 

If you're experiencing situations where these methods are available, it's because some other 3rd party tool is globally modifying Array prototype, and injecting these functions into the global scope.

Therefore you should always code in the ES3 environment for Scripts and never rely on prototype modifications.

[jeroenr13836525]

Thanks for the clarification. Interesting to know that these functionalties can be inherited from other scripts, extenstions etc.
We are using the CEP engine for our extension, but still need extendscript to actually make changes/get info from the AE file itself. We can use ES6 in our front-end/extension part, but are forced to use a 'translation layer' in between CEP and AE (which is extendscript) which is running ES3.

To clarify: We are writing an extension in CEP which needs to be able to manipulate AE project items, layers etc, or make new layers and comps in the currently open ae project. We currently do that by running the: 
CSInterface.prototype.evalScript = function(script, callback)
Where the script parameter is the name of an extendscript function.

Because, in the end, we actually run extendscript this means we are limited to ES3 in that specific piece of code we are calling with this evalScript function, correct?

We are curious if this is the correct implementation? Or do we maybe overlook a more convenient manner to deal with this.
If so, any idea whether the necessity for using that 'translation layer'/extendscript will be dropped at some point allowing CEP to alter layers etc. directly?

[Tomas Sinkunas]

You're doing it a proper way.

To put it in a simple form: CEP HTML panel is just a UI element, that uses modern JS features. ExtendScript is the language that manipulates AE dom, and it's ES3 only.

So, write CEP with modern features, but write JSX part in ES3.