To cut it short, ExtendScript is good for a small plugin developed in short time, especially if you have little to no experience in scripting. C++ is good for bigger projects that should have a clear structure. It is stable,  good for production (especially in a large company), allows for more complex operations and more customization. At the same time, development time is longer.

​

More detailed explanation TLDR:

​

 UI:      

 

ScriptUI works quite well for quick UI prototyping. It creates elements with Adobe app appearance out of the box, they do not require any additional styling. There are some customization options, but they are quite limited. ScriptUI is quite poorly documented, but there are a few resources to get started.

​

CEP allows you to work with frontend like in web development: Typescript/Javascript + CSS which opens endless customization possibilities. The entire development process becomes very smooth with the separation of the objects and styles (relatively difficult in scriptUI). CEP quickstart guide is well-documented and easy to follow and since TS/JS are widespread, there are a lot of development tips and resources. It needs more styling than scriptUI as it comes with the basic html elements by default.

​

Bonus: with CEP the appearance of the UI can be tested directly in browser, without having to open Illustrator. Saves a lot of time on styling and debugging!

​

 Backend:     

​

Familiarity with the language is quite important here. If you are more familiar with Javascript, it will be easier to start with Extendscript, even though it might be frustrating to use an old Javascript version that lacks many important features and functions!

Both the frameworks require minimal familiarity with the Illustrator's functionality - but the more the better!

​

ExtendScript illustrator reference is well documented and has examples of how to call various objects. Many people on the community forum write scripts using this framework, so it's easier to get a development advice. The disadvantage here is the language structure itself. ExtendScript is based on the old version of Javascript, so it doesn't have some functions we are used to having by default, the script is written without any class structure, which makes it disorganized and difficult to follow. Some of the third-party packages can be used here, but including them is not straightforward.

​

Bonus: there is a possibility to write a library in C++ and call it from ExtendScript, which means that you can have any third-party packages used in the plugin.

​

C++ SDK also provides an extensive documentation, which I personally find clear and easy to navigate, even though it definitely lacks usage examples. Some of the developers do not share the same point of view though. Since the language is C++, the entire project can be structured the way we want it, with classes, maps, enumerators and so on. The code can be as structured and clean as it can get! The language can be challenging for a beginner, though. Any third-party packages can be used in the project; package inclusion is not straightforward but easier than with ExtendScript.

​

Bonus: with C++ SDK there is a way to debug the plugin by running Illustrator directly from the Visual Studio. This way we can identify the bugs straight away.

​

 Backend-frontend:     

​

Communication between the two parts (in case the plugin has a frontend part).

​

ExtendScript <-> scriptUI : signals and events are sent between the two parts using BridgeTalk. As for my experience it's inconvenient, requires writing extra functions (as if the code was not already messy enough), transforming different types into bytestrings (the only message type that can be passed to BridgeTalk) and decoding them afterwards. If there is a library written in C++ that interacts with ExtendScript, calling it becomes quite easy using ExternalObject. The positive part here is that both the parts are written using Extendscript, so there is no need to switch between the editors or to build anything. The entire plugin can be written in one file.

​

C++ <-> JavaScript/TypeScript : this part requires a bit more work, as communication events should have the same naming in both the frontend and the backend (that's how an eventlistener receives the message) and a specific function format defined in the SDK. Once done with writing a template for your events, adding the new ones becomes straightforward. There are two different languages used to write two different parts (whether it is good or bad is a matter of taste).

​

 Development:     

​

ExtendScript : easy to get started even with no to little programming experience, as the language semantics is easy to understand and the entire code can be written using the Notebook tool. External code editors are also light, free (many) and do not require specific skills to be used for a small plugin development. There is no need to compile the code, it can be tested as it is written without reloading Illustrator. Installation and distribution is very easy: no specific file location required, little platform dependencies; basically, the .jsx files can be sent directly to anyone and used straight away. The drawback with ExtendScript is debugging the code: you never know where the error is and it takes more time to find it than to actually write the code:) All you get when testing is an Adobe Illustrator alert with a code line number (not necessarily where the issue is).

​

C++ : requires familiarity with the language, especially pointers / references, memory allocation and data types, which can be intimidating and challenging for a complete beginner:) learning process is also much slower than ExtendScript, as there are endless compilation errors that don't even let you test what you have written. It might be a bit frustrating at first, but getting into it is totally worth the time and the effort! C++ also requires more tools for development, ideally you would need to install Visual Studio (and make sure it's version corresponds to the one required by Adobe), which is free but relatively heavy. There are many settings that need to be compatible with the Illustrator development guidelines (C++ version, platform requirements, output files, static vs dynamic build, SDK version, VS version etc). The backend code needs to be built, which ensures that the distributed plugin code is not alternated.

Compiling and building takes time, though. It also means that you can not simply send the code files between the users and edit the files on their machines. There is an instruction on .aip distribution from Adobe, which makes it easy to release in a corporate setting (or mass-release for the community). Distributing the plugin for test purposes requires more job though: editing the registry, placing files in the specific locations, ensuring version and platform compatibility.

Debugging is very smooth as the compiled code can be run directly from Visual Studio, stepping through each line, reading the variables and finding the issues as they arise.

​

 Maintenance:     

 

What happens between the Illustrator version updates?

​

ExtendScript: normally nothing happens, the script can be run in the same way with different Illustrator versions. As ExtendScript part is not being updated, the software maintains the basic compatibility with the existing functions. Sometimes there are issues that are normally reported by the community and fixed in the later updates. For example, I found out that some of the scriptUI functionality that worked fine before 26.2.1 suddenly stopped working at 26.4.1 - and there was no quick fix for it.

​

C++: it is important to use the latest version of Illustrator SDK when building a plugin, as previous SDK versions are not always compatible with the latest Illustrator app versions. There are around 4 SDK updates per year, which means you have to have regular updates. Code stays the same, it's only about updating the SDK files folder and referencing it as a library to your code. Latest SDK version is compatible with the previous Illustrator app versions, so no issues here:)

 

CEP: it is important to use CEP version that is compatible with the Illustrator app version. Later CEP versions might not be compatible with the previous Illustrator versions and vice versa. No need to download anything, it's only about changing the .xml file settings.