What sets CEPSparker apart?

CEPSparker is but one of the many starters or frameworks available for getting started with creating panels and extensions for Adobe Creative Cloud apps.

But a few notice-worthy traits set CEPSparker apart:

1. You can get to 'Hello World' in five minutes, pretty much. No need to install anything beyond the Adobe Creative Cloud and a good text editor.

When I want to get started in an unfamiliar development environment, I want to be able to 'just run something' and then poke and prod and break and single step the thing. And I want to be able to go back and start over cleanly, quickly and easily, as I figure things out. CEPSparker is built with that in mind.

2. All the developer-tasks, like 'clean', 'debug',... are automated using human-readable, simple command line scripts. Mac and Windows versions are available.

These scripts serve as a way to document the underlying mechanisms of CEP development and help build an understanding of the many moving parts of a CEP panel.

I purposely try to avoid 'magic' stuff. 'Magic' stuff works great, but unless you fully understand the magic, you can end up on the creek without a paddle.

'Magic' shields the developer from a much-needed understanding of the low-level mechanisms. You need to understand what is going on in order to be a better CEP developer.

So, instead of hiding the complexities, I try to show them, while at the same time automating common tasks.

3. Care is taken to encourage code sharing between ExtendScript and JavaScript. Because the two languages are so close, it is feasible to use the same code in both environments. By moving any environment-dependent stuff behind some API, you can write code that is oblivious to whether it is running in ExtendScript or JavaScript.

For example: look at the function 'logError' in the shared_js_jsx/utils.js script. This code is exactly the same for ExtendScript and for JavaScript. 'logError' calls upon another function, 'logMessage'.

Because logging a message is handled differently in JavaScript and ExtendScript, you'll find two versions of logMessage: one for JavaScript, another for ExtendScript.

The idea is to minimize the amount such 'context-specific' functions, and try to write code that can be shared between both environments. Only low-level functions should exist in two versions, higher-level functions should use shared code.

4. Care is taken to avoid duplication of the extension source code for debugging.

There is only ONE copy of the source code. When debugging, there is no second copy floating around.

The 'standard' approach seems to make a copy of the extension for debugging into a special folder on the computer.

I've found that eventually leads to confusion, when I inadvertently start making changes in the 'live' copy being debugged, rather than in the 'original' source code.

By only having one copy of the source code on the system, that issue goes away.

5. In the source code folder, the .debug file is named 'debug' (no leading period in the name).

I hate these invisible (on Mac) .debug files.

The same trick that I use to avoid duplicating the extension for debugging is also allows me to make 'debug' a visible file.

The 'debug version' of the extension contains a symbolic link called .debug (a leading '.' in the name).

This links to the actual file called debug (no leading '.' in the name).

That way, the Creative Cloud target app 'sees' what it wants to see (.debug) and the developer can also see what they want to see (debug) and both files are the same.