Is UXP missing a feature or API that is blocking your migration from CEP (or elsewhere) to UXP? Please list it here.
@zwettemaan said recently that he knew several developers who started to migrate but were blocked and went back to ExtendScript. I’m curious what those features are… please list them in this thread.
UI:
API:
resolve Extendscript function to resolve raw specifiers into objects (ironically the .toSpecifier() is available, but rather useless at the moment)UXP DevTools
Another current deal breaker for full migration to UXP is that in general the UXP APIs appear to be slower than ExtendScript. Not an issue for user interaction, but for doing some intensive processing on a whole document I still have to resolve to a doScript into string-based ExtendScript, either directly of via a persisted engine to keep things fast. Using doScript like this is also kind of annoying due to the limitation of only allowing very basic argument types on that function.
The latter is a request in of itself I suppose… please allow objects to be passed via doScript (probably not very feasible do to technicalities - but doesn’t hurt to ask eh )
For a clearer picture, Adobe might need to pick the brains of people that are not here on this forum… It’s not so much about migration as about ‘not bothering to try any more’.
ExtendScript was an environment where a lot of effort was made to lower the treshold for would-be scripters: it allowed creative users to try their hand at scripting.
Things that ExtendScript had, and UXP is missing:
built-in OMV
ScriptUI
ESTK: slightly weird UI, but we all learned to love it. Debugger/editor/OMV all in one, very lightweight. I know there are people who switched to Windows just so they could continue to use ESTK when the Mac dropped 32-bit support.
E4X
The whole environment was enticing to get creative, non-scripters to try and dabble and write their first script, and that created a rich eco-system. To regain that attraction, UXP needs to get much better tooling and try to remove hurdles.
I have already mentioned a few things elsewhere and I think one or two things are already being worked on, but here is my wish list:
more Spectrum Web Components … and the ones that are available still have one or two bugs It’s still beta, I know, but if you can’t install them without errors, it’s difficult to create a useful UI.
XMP (In the documentation but not yet in InDesign)
As a replacement for E4X (mentioned above):
DOMParser()
XPath document.evaluate(…)
Very useful for new project
Drag & Drop
structuredClone()
UDT
Better error logging, sometimes simply no errors are output there.
For me, the biggest problem preventing migration to UXP is reading and writing text files.
One of the issues is shown in the InDesign sample script.
Even with InDesign 19.4, there are only 19 sample scripts for UXP compared to 21 sample scripts for ExtendScript. That is, two are missing.
Among them, I created “PlaceMultipagePDF.idjs” by myself while studying. (PlaceMultipagePDF.idjsを作ったぞ（ExtendScriptからUXP Scripting） | CS5)
However, “FindChangeByList.idjs” cannot be created. Because line 124 of “FindChangeByList.jsx”
myLine = myFindChangeFile.readln();
This is because there is no equivalent function, that is, the ability to read a text file line by line. Of course the InDesign team should know.
Currently, to achieve this with UXP, it is necessary to read the entire text file and divide it into arrays using line feed codes, which requires extensive rewriting.
There’s another big problem with text files. Encoding cannot be specified in UXP. All are treated as UTF-8.
However, there are some functions in InDesign that cannot handle UTF-8. First is “InDesign tagged text”. In the case of the Japanese edition, the encodings that can be handled are “ASCII”, “ANSI”, “Unicode(UTF16LE)”, “Shift_JIS”, “GB18030”, “Big 5”, and “KSC5601”.
There’s no UTF-8 here, so I can’t create the text file I want to use with “InDesign Tagged Text”.
Next is “Data Marge”. Although this function is often used alone, it has many inconveniences, such as line breaks cannot be included in the field and there is no function to automatically adjust the horizontal ratio, character spacing, and font size. , and execute it using a script, including the processing after data import. However, in the case of Japanese, the encoding of the source file will be “Unicode (UTF16LE)” and “Shift_JIS”. This is because this function cannot handle UTF-8.
I’ve been requesting this from the InDesign team for quite some time, but there’s no sign of it ever happening.
There is also a problem with newline codes. In InDesign, Chr(10) is a Forced line break and Chr(13) is a Line break, so you need to use them properly, but in ExtendScript, there is a problem that both are replaced with the character of odeline break setting. UXP doesn’t allow reading line by line, so I’m not sure what the problem is.
One of the issues preventing migration is the issue with ExtendScript’s own objects.
Typical examples are $object and UnitValue object. $objects are commonly used in any application. The UnitValue object is required in countries that use units of measurement other than points. It probably doesn’t matter much for Photoshop, but it’s essential for InDesign and Illustrator.
Script UI has become essential for scripters. In InDesign Dialog, if you create a dialog with checkboxes for each paragraph style, the dialog may extend beyond the screen depending on the number of paragraph styles. We were able to replace those parts with Script UI. However, this cannot be done easily with UXP Scripting, so you must consider UXP Plugin. I would like to be able to easily handle dialogs in HTML with UXP Scripting.
Finally, there is the issue of tools.
For scripters, the most important thing is the one-liner. While writing a script, it’s common to run a small script with a few lines just to see what’s going on.
ESTK was very useful for doing that. Because you can run it without saving the file. You can also use the console in VSCode to run unsaved code, but you can only write one line, which is a bit inconvenient.
Currently UXP Scripting doesn’t seem to have a tool to do that. It is very time-consuming to save a single-use script with a name in order to run it, as you will have to delete it later.
In macOS, the menu allows for easily assigning keyboard shortcuts and easily incorporating them into an automated workflow. This is a very cost effective solution.
Users who go to the trouble of adding scripts and plugins to InDesign are people who are very interested in such customization. If it doesn’t exist, they will certainly have a poor opinion of UXP. And they will complain to the developers who are the providers.
I tried to provide it myself via the InDesign DOM menu addition feature, but found it impractical for a variety of reasons.
Change events on React are considered equivalent to input, but I’m using Preact and would like to clearly distinguish between them.
It looks to me that UXP has already become almost a maintenance mode for Adobe. Or simply seems that way due to lack of resources?
ScriptUI in ExScript was a bad part in my opinion. In UXP I can do what I want in more predictable manner. Even use React. In ScriptUI when I wanted scrolable panel I had to code scrolling logic from scratch 
in UXP overflow CSS property should deal with it.
The UXP developers tool is still pretty hopeless for scripts. An integrated object-model viewer is lacking (there are third-party solutions but there should be an integrated one). EX4 processing, better file handling, ScriptUI.
The ESTK and ScriptUI aren’t perfect, but as Kris Coppieters mentioned, they provide an integrated developer tool with a low threshold. And as @Omachi mentioned, in the ESTK it’s easy to rattle off a couple of lines and run them.
It has been difficult to learn how to make a packaged plug-in. I have never used ESTK or the VS Code’s plug-in for ExtendScript, but I have heard that it is easy to export a .jsxbin version. While it is not fully safe (to keep prying eyes from viewing), it was easy and built-in.
I am working on bundling my Photoshop UXP plugin, and features that require secure storage, such as saving log in information and modifying files, do not work correctly.
Thanks for asking, Erin.
The big one for me is the absence of Bridgetalk (or equivalent) in UXP plug-ins. I wanted to migrate my old InDesign script that post-processes exported images via Photoshop (to ensure best quality and smallest file size). Without Bridgetalk I gave up and went back to Extendscript.
Or am I missing something? I’ve spent many hours Googling UXP and Bridgetalk and I can’t find a single result that even mentions UXP and Bridgetalk.
Thank you, @Erin_Finnegan, for asking about this. I’ve got the following thoughts. For emphasis, some are repeated from other replies to this same question.
Some processes to make it easier to create something quick by inexperienced users. While I’d personally rather have VS Code integration, even that would be too many steps for many to knock out something quickly. While I hope to never launch it again, basic ESTK functionality would be what you should strive for. I’ve got a co-worker who still uses ESTK because he knows how it works. He’s not using any code repository (git, etc.). He’s just producing scripts to solve problems and automate processes. ESTK was/is good for that.
Part of ESTK’s appeal is access to an Object Model Viewer (OMV). I’ve been away from it so long that I don’t think much about it anymore, but it is surprising how many forum questions deal with things that a user used to be able to see in OMV in ESTK.
Replace the Adobe UXP Developer Tools application with a VS Code plug-in. The workflow of editing somewhere else, then reloading in UXP, debugging, rinse and repeat is tiring at best. It certainly isn’t efficient.
Native XML object support. I never knew until these replies to your question, but it appears that was an implementation E4X in ExtendScript. We heavily rely on the native parsing in ExtendScript. We’re taking advertising layout files from 13 different sources and parsing them to add frames for ads on pages. Thousands and Thousands of pages a day across hundreds of sites. We’ve looked at using DOM Parser with UXP, but to do that you need something like WebPack. That adds a whole new great big set of headaches and is certainly not something easy. XML parsing is a roadblock for us.
Built-in equivalent to something like WebPack. Your documentation strongly encourages using something to obfuscate the code. Yet you offer no method. Even ESTK had an easy export to JSXBIN. JSXBIN, while not secure, was a nice first line of defense. The ExtendsScript Debugger for VSCode again provided a method of doing the same JSXBIN export.
Make the Spectrum Web Components built in. We know it is possible since you had the Spectrum Widgets in early versions. We’re still using that limited set since to use the full SWC, you’re back to needing to use something like WebPack. A problem with the Widgets, however, they don’t match in appearance across all the applications. If you’re keeping/extending them, please make the appearance match. And you need to keep them to have something easy/simple for new users/script users. But then you’re forcing advanced users to change at least a small amount of the UI to switch.
Please add the ability to add a menu item to a UXP-based Panel in Adobe InDesign. Adobe Photoshop supports it. Not a roadblock, but it would be nice since, as far as I know, I can’t fully remove a menu in the menu bar upon quit.
Please add some ability to easily allow the users to add PERSISTENT Keyboard Shortcuts. ExtendScript didn’t allow this either. We got around it by making standalone scripts that called the menu items. I assume this same hack will work with UXP, but we’ve not tried it out yet. But why make it that ugly? It should just work! I’d even be willing to do something crazy like get an Adobe Unique ID for each menu item if it would make it easy and persistent for the users. Again, I don’t want to force the keyboard shortcut on the user, I want them to be able to pick what keys they want to use using Adobe’s built-in Edit > Keyboard Shortcuts... functionality.
I think there are like two events you can monitor for a text field in the UI elements (input and paste). Not a roadblock, but it’s going to change how we go about building certain aspects of the UI. UDT’s view shows there are additional events that are known about, but why aren’t they wired up?
Documentation! I’ve been harping about this since my first day. When was the last time something new was added?
Drag and Drop isn’t a requirement for us-yet. Coming from ExtendScript, we don’t currently use it. But starting with UXP in Adobe Photoshop, I expected it would be an option. We would certainly integrate support for it if it was available. For us, we want to drag and drop something from a UXP Panel into a document and then trigger an event. And look how many people on the Forums are asking about making it work!
Positive Things about UXP:
I am ecstatic about the demise of ScriptUI! Adobe abandoned it ~15 years ago, so it is nice to have modern UI components that can match the native appearance of the application’s UI. Yes, I know there are some who miss it. To each their own. I was expecting the transition to be more difficult. But I have slowly constructed a simple library of code for common elements and it is now very fast for me to bang out a new dialog. But it would have been way easier if there had been some better documentation. And it wasn’t clear to me for quite some time that the built-in spectrum widgets a) behaved differently than the SWC which b) weren’t even available at that time.
I’m very happy to leave ECMAScript 3.2 behind and advance to version 6! So glad to have a modern language. I definitely use the newer features.
One positive aspect of the Adobe UXP Developer Tools application is the ability to set it to look at the UI elements. It’s flaky, but when you get it working, it is helpful to assess the cause of the appearance of an element. That was a bigger help in the beginning, however. Rarely need it now.
jsw (For Erin: the guy with the treadmill desk)
I’m adding not a blocker but a feature request: The ability to have a dialog adjust to the size of what it contains. AKA to ‘flex’ a dialog. Perhaps I just don’t know how to do it, but it seems like it currently isn’t possible if you want to prevent it from exceeding the monitor’s bounds.
Along the same lines, some documented way of handling the User Interface Scaling so that we can scale dialog and content to match what the user has selected, but again, not make it too big for the monitor’s bounds.
jsw
I think dialog wants to fit its inner content… if you restrict inner content max size then it will help. But I miss feature to change dialog and more importantly popover size after it is shown.
Thanks @Jarda on the concept of limiting the inner content. I’ll see what I can do if we ever make a dialog from scratch again.
Yeah, in ExtendScript with ScriptUI, I had several dialogs that dynamically changed sizes once the user exposed certain features. It seems all I can do now is reserve the blank space (or let flex properties move something else into that space and have the blank space later). Admittedly, this is what Adobe does in some of its own InDesign dialogs (Settings/Preferences).
jsw
for me those are
CSInterface.prototype.resizeContent() comes to mind;app.system() even with user’s consent;ScriptUI.environment.keyboardState that was able to detect a modifier key while performing a script;Thanks for all the thoughtful posts!
I was going to compile these into a neat voteable list for easy browsing by the Product team, but some of the items are less features than large concepts… nevertheless, I’ll see what I can do.
Feel free to keep adding to the list.
For me pain points during migration are:
…and also bugs I reported
Hi @Erin_Finnegan Thanks for this post, hope this can be helpful:
For me the things that are a MUST, and I had to workaround with other things like Electron and other ways to make my plugins work the way I wanted is:
Programmatically resizable UXP window, a lot of users miss my plugins old UX and worked with this perfectly.
Canvas HTML element: functions like ctx.putImagePixels() or ctx.createImageData() are not available and they are VERY important when working with HTML canvas elements because canvas is made to manipulate pixels and if we don’t have a way to put pixels in there like this is not performance friendly, so I have many plugins stopped in UXP because of this.
As mentioned in point 2, my other workaround is to create a server locally as I did with CEP long time ago for my plugins, and use that server to exchange infromation between my WebGL application and Photohoshop, but I cannot find a way to start a temporary local server like I would do with CEP.
As an experienced UI / UX developer, not having all the CSS features can be a problem when designing things.
It would be a mazing to have a feature that can start a program from the UXP so that program can connect with the UXP plugin and exchange information. My workaround is to have my program as a server running in the background and I use webhooks to listen when the UXP plugin is started and then start my software and they are connected, but this involves having my software as a server in the background and I always look for optimization in memory so would be amazing that the external software is fired when the UXP plugin is started. Why I went to create a external software and connect it with UXP and not created entirely in UXP? Because I use WebGL directly and is fast, UXP doesn’t allow directly WebGL which is a shame, webview is amazing but it is slow and it has a lot of small bugs when dealing with the UI inside the webview…
I think by now this would be my most important things I thing would be best to implement in UXP.
Bests,
@Erin_Finnegan I’m not sure if this is the place for a feature request, but one really frustrating feature is the number clicks required to start debugging a script. Basically, AFAICT the developer needs to:
This is wayy too much. I am developing complex scripts to build paged media in InDesign from local files. I am running the scripts over and over again, bumping my head through a poorly-documented space, with no type inference or IDE autocomplete 
. In development, I sometimes run a script over a hundred times a day, and the routine of the above gets tedious very quickly.
Suggestion: would it be possible to add an additional menu option to the right-click menu scripts in the Scripts Panel? I’m talking about the context menu where “Reveal in Finder” lives. It would be nice to have “Debug script in UXP Developer Tools” in that context menu. It could error out with a helpful message if UXPDT is not already installed, or offer a prompt to install it. That would reduce the click path for me from 5 to 1. 