Is there a future for scripting in FrameMaker? - very personal view

[K.Daube]

As an introduction just a few quotes from the Coding Corner forum.

Lumigraphics 2023-03-29: «You'll have a revolt if you kill ExtendScript on Photoshop. Oh boy. A LOT of people rely on it in production. I do get the shift to UXP, but for those of us who aren't dedicated developers, we just need something that's easy to use and works. I'm first and foremost a working professional photographer, not a developer. I don't want to write a complete plug-in for simple stuff that I need automated.»
PECourtejoie 2023-04-04: «If ExtendScript is to be retired, I seriously hope that developers will have enough time to convert their work to the new language, or many users will be stranded.»
My personal view concerning FrameMaker [2023-04-11]

My way into FM scripting:

My entrance to the world of IT was 1964 a class on Fortran at the Adult education centre (Vokshochschule) in Zürich. It allowed me to shrink a two-person workload of 3 weeks with goniometric tables and a mechanical calculating machine to 20 minutes on an IBM 1620 computer (15 lines of code) - including a beautifully printed output table. We were calculating the coordinates for milling a cam. Manually we restricted it to 120 points, my program run for 360 points…
My first contact with FrameMaker was 1992 when a friend gave me the hint to use FM to solve my problems with MS Word for software documentation. In those times I also learned about GML and then SGML which flattened the route to HTML significantly. Soon I learned JavaScript to enhance navigation on my website - the starting point for scripting.
For early automation in FM I simulated keystrokes with a script language called AutoHotKey (FrameMaker and EndNote 8 … Xy). Then I recognized the existence of FrameScript (by Frank Elmore). But I never got very acquainted with it.
Fortunately ExtendScript was introduced with FM 10 (in 2011) and peu à peu I developed my skills in this language with the took kit ESTK - with the help of many others. However, it took me longer to learn debugging with ESTK replacing numerous alert statements.
Then 2020 we got notice that ESTK will not be developed any further (it’s a 32–bit application) and had reached End-Of-Life. Users should switch to VSCode and and ES debugger (this was in early beta stage). I’m now quite familiar with this tool, although the use of it is not that intuitive.

Rumous and raw random data

But in the meantime we hear that ExtendScript shall be replaced by something else - is it called UXP? What is this really? As far as can see now, it is a completely different concept compared with ES, needing different tools to be managed… IMHO the concept of UXP dis clumsy - so many levels…
Poking around I found Davide Barranca’s blog and book . In his blog he first presents the marketing event Adobe MAX 2020 with the following statement:
… So UXP is going to be the future of all Adobe Creative Cloud extensibility. CEP is going to be faded out, it will take a lot of time, nobody knows how long. UXP has one engine compared to the two engines of the CEP system, the one engine deals with both the UI and the scripting side so we have an entirely new scripting engine that has a new DOM. You can use subset HTML, CSS and JavaScript and the result of what you write is then converted into native controls which are faster and have a lighter footprint…
And then I read somewhere «UXP scripts can not create panels, only dialogues…» - a serious limitation.
For the new feature in FM-15 (2019) HTML dialogues for FM I found only announcements - no real information. There is only a short discussion on the FM forum - nothing in FM-UG, nothing elsewhere!

Conclusion

In a productive documentation environment scripting is a must to be able to fulfil the various customer demands. Many of them require a long sequence of repetitive operations with the interactive UI. And there are also special requirements with are not (monetary) qualified for direct integration into the application (see for example FMbiblio, FMcalc, FMgraph, FMnotes ).
All of this work is endangered by the Damocles sword of  ExtendScript will be discontinued. We have only rumour about this, but rumour is the source of speculation. Because of the importance of scripting for FrameMaker, I am urging Adobe to communicate a roadmap on this topic  - and to provide adequate documentation suitable for FrameMaker developers.

[frameexpert · Accepted solution]

Klaus, thank you for the links, especially to the UXP stuff. I agree that we need some communication from the Adobe FrameMaker team about the future of FrameMaker scripting.

My gut feeling is that, because FrameMaker's code base is quite old, the FDK model will be pretty much the same going forward. Since ExtendScript (and FrameScript) are more or less wrappers for the FDK, I would think that ExtendScript would be around for future versions.

There are several problems with ExtendScript going forward:

1. ExtendScript is based on an old version of Javascript/ECMAscript.

2. ExtendScript has extra features that are essential for scripting: File/Folder objects and methods, XML objects and methods, and ScriptUI objects and methods for building dialog boxes. If ExtendScript is no longer maintained, it is not clear if these features will survive future FrameMaker or OS updates.

3. Those of us that develop for multiple applications (for example, FrameMaker and InDesign) may eventually have two separate development platforms, ExtendScript and UXP.

An ideal (although unlikely) scenario would be for the FrameMaker team to take over and maintain ExtendScript. They could then update the ExtendScript Toolkit and update the core Javascript language to the latest version. Given that FrameMaker's market share is much smaller than the Creative Suite's applications, I am doubtful that this will happen.