Does Adobe have any plans to update JavaScript

[McShaman]

According to Adobes documentation they are using a version of JavaScript based on JavaScript 1.5 which was released about 15 years ago. Understandably the language has changed greatly and has some very convenient features to make coding and readability easier and faster.

Does anybody know if Adobe has any plans to upgrade their scripting API including the version of JavaScript integrated into the API? It feels like the scripting community is often overlooked in updates.

[McShaman]

Surely the scripters in this community all want to see Adobe update the JavaScript support? I'm very surprised at the lack of response to this post.

[frameexpert]

I would love to see it. I would also love to see at least XSLT 2.0 support in InDesign. I file these under the "don't hold your breath" category.

[Vamitul]

I would love it, but the chances of this happening are lower those of me winning the lottery (that is taking into account the fact that i never play the lottery).

[Marc Autret]

About two years ago DavideBarranca‌ wrote an "open letter" — Adobe Scripting: collaborative code sharing — that is still topical. Davide and I also had a private discussion on the hot question, ExtendScript vs. JavaScript, and I guess Davide would totally agree your point. Here are additional thoughts I'd like to share:

As far as I know ExtendScript has been designed and developed at Adobe by Michael Daumling (who was part of the ECMA-262 committee). This is a specific ECMA-262/3 implementation, including both E4X (ECMA-357, i.e. the XML layer) and many additions. Of course there are ExtendScript pros and cons, but I think this still is a great engine (just speaking about the core layer, based on 'ScCore.dll' and 'ExtendScript.dll' on Win platforms). In some sense ExtendScript is the only Creative suite component that has remained stable, robust, and reliable after so many changes and moves in Adobe technologies.

Indeed it doesn't comply with ECMA-262/5 (and it even lacks some ECMA-262/3 properties), but its exclusive features still deserve to be highlighted:

• Engine dispatcher, preprocessor directives.
• Debugging/tracking services: $.summary(), $.stack, $.list() and $.listLO()—not to mention hidden ones.
• Reflection and Dictionary interfaces.
• FileSpec API (i.e. File/Folder objects).
• Ability to overload operators. Cf. Operator Overloading with ExtendScript
• JSXBIN compiler Cf. JsxBlind | The First JSXBIN Obfuscator for ExtendScript
• UnitValue, XML, etc.
• watch/unwatch methods (so great to emulate 'setters' or 'listeners' at a very low level).

Not sure I'd be ready to abandon that all, just to have some JS sugars like Object.create(), getters and setters, or additional Array methods I don't care about.

Don't misread me though. I don't pretend there is no serious reason to *update* ExtendScript. For instance, it seems obvious that Adobe will have to unify the HTML5/JS infrastructure with ExtendScript, just because it'd be stupid to maintain two ECMA intepreters! But IMHO it would be a big mistake to simply replace Daumling's creation by the state-of-the-art JS standard.

@+

Marc

[Peter Kahrel]

I entirely agree with Marc. ExtendScript could do with some updates but we can't afford to lose e.g. the file and folder objects and XML processing. It may be possible to add HTML5, as XML was added in CS4, and other things may be changed as well. But we have to make sure that we don't lose the good things listed by Marc.

More important I think is that Adobe provides a decent script editor/debugger, either by fixing the ESTK, which is an embarrassment, or by creating a new tool of the current ESTK can't be fixed for whatever reason.

Peter

[Vamitul]

Peter, Mark, I'm a bit on the other side of the fence with this.

Replacing the current JS engine with something like Node would bring a lot of benefits, and for most of the good things in your list there are better alternatives:

• preprocessor directives: the CommonJS require and module are far superior to the #include stuff. And even #targetengine directive might not be needed.
• debugging: the built-in node debugger, stuff like Node Inspector etc
• reflection and dictionary: NPM search 162 results for ‘reflection’ and 1199 for dictionary (but most of them are unrelated)
• Files and folders...
• Operator overloading: i never used it and never saw the need for it, but...
• jsxbin compiler: we already have a big problem with that
• UnitValue is nice, but it can easily be implemented as a module
• XML: the E4X is very nice in theory, but becomes horrible in practice. There are a lot of better alternatives available
• watchers: how about some better listener support?

And then... access to more than a quarter of million of available packages just on NPM, for almost anything. Stackless tail-end recursivity, functional programming. ES6 stuff and maybe even TypeScript.

[Peter Kahrel]

Vamitul -- I'm not married to ExtendScript/ESTK, I'm open to any alternative so long as we don't lose any of the functionality that we have now. It's clear that you are better informed on alternatives than I am. If Node or a Node-like framework can provide the same functionality better and more comprehensively, sure.

More than a quarter of a million packages just on NPM -- I won't live long enough to discover what they are!

Peter

[McShaman]

I fully agree Peter. I just spent hours trying to get a simple CSV library working that I often use for web applications. Unfortunately more and more scripts (understandably) use functions like Array.forEach or Array.some and I have to try and debug, rewrite and pollyfill the hell out of them to try and get them to work. There is so many applications on NPM that could add massive flexibility to an Adobe workflow.

Marc you always seem to have an internal insight into Adobe's movements. Do you think they are just letting it die away or do you think it is something they are intending to upgrade every 15 years?

[Marc Autret]

McShaman wrote:

Marc you always seem to have an internal insight into Adobe's movements (…)

Yet I really do not, but I'm flattered you believed that! Seriously I have no prediction about the next move. Also, I perfectly understand your arguments as well as those expressed by Vamitul and Davide. What we can hope is just a good compromise. Should they upgrade ExtendScript in the short to mid term we could all rejoice at that, as long as upgrading is not weather-cocking—a sport in which Adobe excels. If they plan to change ExtendScript as they have managed Flex or ScriptUI, please, tell them we can implement Array.forEach by ourselves.

@+

Marc

[Vamitul]

McShaman‌ Github can help quite a bit with all the polyfil and transitioning and stuff. I can't look for them right now, but there are three projects in particular that helped me a lot:

CommonJS require and modules implementation for ExtendScript
The standard polyfill libraries (i think those are also on MozDev)

An implementation of UnderscoreJS for ExtendScript (since i really don't like extending native objects prototypes)

[Loic.Aigon]

Don't forget that sometimes the tool we work with are just the consequence of a brave one at Adobe and not always a thoughtful consideration from headquarters to the bottom. I was told from an us adobe guy that PatchPanel which later would lead to Flex Extensions was nothing but a personal initiative from an employee to demonstrate feasibility against his hierarchy. So as long those people are around project may evolve but can also be abandonned or let as it is once they leave the company.

So I won't exclude any changes but it would probably lays on a motivated engineer there some day than from a corporate strategy.

Also, once again, can someone tells me who is in charge of these questions at Adobe ?

[McShaman]

That's a terrible business model! There is no way you be able to introduce features that hinge off the expertise of a single dev in any of the companies I have worked for... And they are a fraction of the size of Adobe. YEEK! I hope that is not common practice!

[Loic.Aigon]

I can't agree more.

Another example is how the CC extension project is managed. Flex was dropped of in favor of HTML5, well ok, why not. A project manager was there for a coupe of years (Don't want to quote him but every one will know who I am talking of). Now he has left and there was no notice from Adobe at any point t say "Hey, ok this guy left but don't worry here are our plans, John Doe is now the new project manager, he will now leading the project…" (unless I am wrong).

ScriptUI…he he. It seems like no engineers is willing to take his hands onto it.

Last example, I met a former InDesign product manager and asked him if Adobe had any plans of rationalizing scripting between Adobe apps. His answer was "really not a concern at Adobe…".

To be honest, I would be happy that some Adobe folk come here and say "Come on, stop the bullshit…" Here is a link to our roadmap, here is the guys that handle the projects… But I can't see that anywhere….

Loic

[pqiorpa]

You can use TypeScript to transpile newer version of JavaScript to run on Adobe JavaScript Core that supports only ES3.

Here is repo how to get started TypeScript definitions for Adobe Audition / Illustator / InDesign / Photoshop

[Nick Combs]

Unfortunately, we're still stuck with threads like this in now late 2018. No word on even any plans. I work at one of the largest GD and 4 color print companies in the world, and our leadership is looking for alternatives for the content teams. I cannot in good conscience recommend another Adobe product given this level of neglect.

[Pickory]

There might be some news this week, with MAX happening, CEP and all that.

You could take the C++ plugin route.

P.

[Nick Combs]

Pickory, yeah but we'd likely end up with tools that far too few people know how to maintain.

Trevor, that sounds promising, but a web UX app doesn't really fit the needs of a content team. Our role is in processing artwork we're given and it's data so that it can be enabled on site, not in designing the webpages for it. Still, nice to see Adobe has some modern developer tools. Why they left this one to rot instead of transitioning is still worth asking.

[Trevor:]

The idea is that UXP would be applied to each app as per the needs of that particular app. Note that it could still take a few years to happen and it's not even 100% that it will. The XD app is to do with designing web pages but that's not connected with UXP.

[Pickory]

The initial learning curve is quite steep with C plugins. The big advantage is you are not tied to a technology that might be abandoned. UXP is still jam tomorrow.

P.

[Jongware]

But the biggest two disadvantages, IMO, are:

1. Developing a plugin for a certain version requires a very specific set-up of OS and compiler, and as good as unique for each separate version and platform, including separate machines to develop for both OS X and Windows.

2. The usable shelf-life of a plug-in is very, very short. A plug-in is strongly tied to a single version of InDesign. It won't work on an older version, and neither on a newer one -- by design. The target version is hardcoded into the plug-in.

A good scripting interface -- and let me remind all of you, the InDesign scripting interface is very, very good; by far the best of all programs in the increasingly bad named "Creative Suite" -- suffers much less of these two problems.

Adding an entirely new object or interface does not interfere with existing scripts. A changed interface can be resolved through its own scripting interface (so it may get changed but a script would never know), or a simple version number check can be included to avoid or take advantage of that new function. See, for instance, the simple check to see if a script should support Immediate Undoability.

As I understand it, the scripting interface is only loosely related to the scripting language. It should be possible to make a link to any scripting language. The only thing is that InDesign itself is not "aware" that you should be able to double-click such an external script from inside InDesign.

The interface is one part; the intrinsic capabilities of the language itself are another. For this goes: the more, the merrier. I see no reason why the JavaScript Engine that InDesign uses cannot simply be upgraded to include more "internal" functions -- all that 21st century functionality that browsers seamlessly integrated (and nothing had to change in HTML or CSS!).

As for upgrading JavaScript itself: sure (why not), but let's up the ante and ask for integration of Python. Python is a modern language, easy to learn (apart from the relentless un-ending list of questions all asking "but why do I get an IndentationError?"; it seems to be unavoidable); it is platform independent, has an impressive list of useful built-in functions and capabilities, and a vast external set of libraries for everything from mathematical modelling to image processing to font handling.

Plus, it is conceived by a Dutchman (as I am). So pluses all around.

Add Python to the list of supported scripting languages – Adobe InDesign Feedback

[Pickory]

Hi,

1 and 2 are true of plugins, also true of scripts that rely on exotic features of the current flavour of CEP .... UXP.

The overriding advantage of a C plugin is that you can add your own features, highlight no break. Also, a C plugin can call on all of the current scripting resource. You also have more control of the product that you may develop.

I think a good mixture of all the technologies is good. Use the best combination to get the best results.

P.

[frameexpert]

For what it's worth, I do most of my scripting with Adobe FrameMaker with ExtendScript. I used to write C-based plugs with FrameMaker's API, but recompiling for new versions (when required) was troublesome. When ExtendScript was added to FrameMaker at version 10, I rewrote most of my plugins as ExtendScript scripts. FrameMaker's latest version is 64-bit and so far all of my scripts work fine with the new version.

I do share the general frustration that Adobe hasn't kept up with the latest JavaScript standards.

-Rick

[Trevor:]

There are plans that are actively being pursued.  Most of the stuff is under NDA.

A hint of what's planned is https://medium.com/adobetech/xd-and-creative-cloud-extensibility-faq-e615dd6ecbfe

https://medium.com/adobetech/creative-cloud-updates-this-year-d2fc1628b71

The info there is not very much and very liable to change but the key word is UXP.