Which missing feature or API is blocking your UXP migration?

The main issues are:

  • Forcing everything to be async makes code much more difficult to write. There are situations where async API’s are useful, but for 90% scripts (particularly casual ones) it just makes it more difficult to write and debug.

  • The restrictions on APIs are painful. For example, there are many situations where opening things from hard-coded file paths are useful for a script, but the API restricts this case.

  • The documentation is missing. You usually have to record actions and reverse engineer the descriptors to access various Photoshop operations. This is much more tedious than just looking up the DOM functions in a reference document.

Question: what is the status of UXP Hybrid Plugins (i.e. being able to write C++ code for a DLL that gets integrated into a UXP plugin)? This is currently a blocker for me to implement certain features in CRDT_UXP.

Having that would make it vastly easier for me to add new features to Creative Developer Tools for UXP (CRDT_UXP).

Right now I make do with an external daemon to give the UXP code access to the stuff it needs (unencumbered read/write files, read environment vars, being able to launch processes,…) but having a proper DLL would make that much cleaner and efficient.

Also, how are things in relation to multiple UXP-enabled apps (Photoshop and InDesign, hopefully Illustrator soon?)?

Will the DLLs for UXP mutually compatible between apps? With ExtendScript, I can write DLLs that are compatible with all ExtendScript enabled apps, and I sure hope that the UXP DLL infrastructure is similar in that respect!

What I would hope is to be able to write a single UXP DLL that would work with all host apps that support UXP.

I only just started with UXP, i might be mistaken. I am blocked by

  • Indesigns Enumerators not beeing present, or the way they work, i have to use the values or write conversion routines.
  • i miss toSource()/eval as a way to store data in scriptlabels or local files. I can’t get JSON.stringify to properly store and remake for instance transformation matrices or the mentioned enumerators. Someone mentioned structuredClone - That would be great i guess.
  • A missing runtime object model watcher. I don’t know how i wrote ANY script without one at all, since ESTKs demise.
  • Documumentation … please, or more samples with some reusable good practises patterns (plugin-examples, NOT .idjs)
  • the Spectrum Widgets input field is not as comfortable as the ScriptUI Editboxes, i get weird behaviour.

@zwettemaan, this is worthy of it’s own thread!

In any case I’ll tag @pkrishna and @indranil. If we have a status, let’s start a new thread.

@Erin_Finnegan Thanks for asking for this type of input. We were initially excited about UXP (modern JavaScript and no zxpsign!), but we are hurting from the loss of a Node.js environment. UXP seems to be a ways off from feature/capability parity with CEP. Here’s a list of what’s needed for us to adopt UXP and support the required features of our existing CEP Extensions. Some of these echo what others here have already mentioned.
Please let us know if any of these have been implemented or fixed and we just missed that in the docs.

Blockers

  1. Ability to send system calls (child process)
    • We will try Bolt-UXP’s hybrid plugin that provides execSync(), but we support a number of internal CEP extensions on macOS and Windows. Building either a Helper app or hybrid C++ plugin just for this functionality seems like a lot of overhead.
    • Our plugins are internal to the studio and will not be distributed in the plugin marketplace. It would be nice if there were some sort of feature toggle that would allow exec calls and full file access for this type of plugin.
  2. Ability to whitelist a helper app in configuration without requiring user consent initially and with each new plugin version. (if we have to go the route of building a helper app)
  3. Plugin preference to grant permissions and not require user consent for file access for each version
    • localFileSystem and tokens do address this somewhat. However, the way it is implemented is not in the same manner as other fs implementations such as in nodejs. This means that some otherwise useable node modules would not be compatible with UXP.
  4. CSS Features. SWC is ok, if it was fully implemented, and if the SWC-UXP-Wrapper surface covered all SWC.
    • For example, text-transform: uppercase and text-transform: none
    • Transitions on popovers and toast notifications.
    • Flexbox
  5. Drag and drop
    • Drag and drop from one area in a panel to another inside the same panel.
    • Also drag and drop from within the panel to the InDesign page.

Blockers from the List of Known Issues

  1. When rendering inline text that wraps, borders, outlines, and backgrounds only apply to the first line. You should place borders, outlines, and backgrounds on elements with block layout semantics.
    • Block level backgrounds are not an option. We need to be able to style the background of spans.
  2. Save, file open, and browse dialogs appear behind plugin
  3. Infinite clicks from displaying a dialog or file picker from button

Items Requiring Less-than Desirable Workarounds

  1. Text field password does not hide text input on macOS.
    • The recommended workaround is not viable.
  2. Interactive elements swallow events.
    • If this means onClick events are not bubbled up past their element, this is a problem.
  3. Text field z-index. Text fields and areas will always render the above everything else in the same panel or dialog.
    • This sounds undesirable for text fields on a scrollable page where we would need to hide them manually under headers and footers.

Wishlist

  1. Document storage (XMP or equivalent for arbitrary data)
    • We rely on writing data to custom XMP namespaces in InDesign documents. This data needs to travel with the file between users, so local storage is not an option.
  2. Better Hot Module Replacement (Reloading) in UDT in the pattern of bolt-uxp
  3. Ability to run a series of commands that don’t get added to the undo stack at all. Could be either by pausing and resuming the undo queue, or explicitly sending a doScript command that is not undoable.
    • Examples: Collecting information from the open document, reading/writing XMP metadata, going to a specific page, selecting text, etc…
2 Likes

Very curious to hear whatever came of all this very valueable feedback that was provided on the blocking UXP features for migration and what the plans are going forward Erin_Finnegan. As it currently stands in early 2025, most of the things mentioned here still hold true and while UXP is “usable” for certain use-cases, it is to me far from “production ready” (if still feels like a v0.5). CEP to me still feels like the more mature, stable and battle-tested plugin platform, which IMO will only be cemented if/when CEP 12 comes to InDesign.
Don’t get me wrong, I really want to love UXP as a plugin platform, but it is a really hard sell when there are so many quality issues still open and little actual practical value provided over CEP at the moment - which can already do “modern” JS, web components ,call out to UXP scripting in the backend and much more, with very little issues.

2 Likes

I’ve only started to explore UXP scripting now and I think there are several major problems with the migration.

  • The documentation is incomplete.
  • So, to try to migrate things, we still need to lose a lot of time at experimenting if things work, if methods exist, etc.
  • There’s no migration guide. There are some samples in the documentation, but this is not really a migration guide.
  • There’s no list of the features that were available in CEP and are no longer available in UXP scripting, so that we can quickly check if we can or not migrate
  • Some methods are available for plugins but not for scripts (like getDataFolder()) and this is not stated in the documentation and alternatives are not listed
  • The documentation states that scripts can be run in a headless manner, but this is not true - see next point
  • Some scripts should not require user interaction, but we still need to ask the user to select an initial folder. So, this prevents us from running scripts without user interaction to perform intensive tasks, so it’s far from being headless
  • Built-in scripts that come with the latest Photoshop packages still use old school ECMAScript 3 code, so you haven’t even tried to migrate them even after so many years that UXP has been around, so we are a bit skeptical about migrating because you also haven’t migrated these old built-in scripts. The future of UXP is very unclear. The development doesn’t seem to be active. The documentation still references year 2022 in the URL and there’s no updated version for 2025.
  • I like the fact that we have a debugger for scripts, but it seems that I have always to load it from the file system. This is a bit of a pain. The debugger should at least remember the last opened scripts so that we can just click on them.
  • Type hint information is still lacking. I’m using VSCode. In some cases, it provides some info about the methods (e.g. for methods in the Photoshop API), but in many cases (e.g. for storage) the type hints and documentation is missing and VSCode doesn’t allow me to go to the method/class/property definition. So, we need better type and editor support at least for VSCode, which is widely used nowadays.
3 Likes

Just a couple of quick things here:

Three years ago, I had a teammate write a migration guide here: CEP-Resources/UXP-Migration-Guide at master · Adobe-CEP/CEP-Resources · GitHub

I think there’s been at least one update to UXP since it was written, but I’m not always right.

Built-in scripts that come with the latest Photoshop packages still use old school ECMAScript 3 code, so you haven’t even tried to migrate them even after so many years that UXP has been around, so we are a bit skeptical about migrating because you also haven’t migrated these old built-in scripts.

The built-in Photoshop scripts are written in ExtendScript, right? CEP is being slowly phased out over time, not ExtendScript…

That said, I remember a thread where someone was saying you have to launch Photoshop in Rosetta to run certain old scripts.

@Erin_Finnegan Hey! Thanks for the answer. Indeed, it’s not very clear to me what the relation between CEP and ExtendScript is. I thought ExtendScript was part of the CEP platform, so, if you were phasing out CEP, I thought ExtendScript would also be replaced, which would be good because I think old JavaScript is so bad compared to the new one (>= ES6). Anyway, even if you don’t plan to kill ExtendScript, I think it would be a good idea to rewrite those default old ExtendScript scripts using new JS. I know this takes time, but having concrete official examples of scripts and how they were migrated to perform the same or similar functionality could help other people to migrate.