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.
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).
1 person found this helpful
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.
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, 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.
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!
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 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.
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)
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 ?
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!
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 ********…" Here is a link to our roadmap, here is the guys that handle the projects… But I can't see that anywhere….
Here is repo how to get started TypeScript definitions for Adobe Audition / Illustator / InDesign / Photoshop