What’s a Plugin?

As a software user, you might hear a lot of different terms: plugin, script, extension, add-on, etc. It might be confusing as to what is what, and which is better. What you need, etc. In this article, we will try to make some sense out of all the options.

How to Define a Plug-in

Wikipedia defines a plugin as “a set of software components that adds specific capabilities to a larger software application”. Not a bad definition.

Most software applications have very specific ways of adding functionality to the application, and this definition pretty much covers it. In InDesign, things get much more confusing, because it’s probably one of the most extensible commercial software applications in existence!

In the beginning of time (a few years back when InDesign was created), there were “plugins” and “scripts” — two very well defined concepts.

Plugins

Plugins were written in C++ using the same SDK and APIs that InDesign itself was created with. In fact, at least 90% of InDesign itself and almost all its features are implemented as plug-ins. Plug-ins are tightly integrated into the program, very efficient, and can work dynamically in the background. Plug-ins can have user interfaces which look like integral parts of the program.

Scripts

Scripts are implemented in one of the three supported scripting languages: ExtendScript (Adobe’s version of Javascript), Applescript (on Macintosh), or Visual Basic Script (on Windows). Scripts were classically slow, each action showed up separately in the undo list, they must be manually invoked, and they were limited to clunky, static user interfaces.

Although InDesign had incredible scripting support (there’s almost no native functionality that can’t be accessed through scripting — and better), there were many clear use cases where a true plug-in was the clear (and only) choice.

On the other hand, scripts are much quicker and inexpensive to develop, as well as easier to debug. Additionally, a buggy script is much less likely to crash InDesign than a buggy plug-in.

Things Got Muddled

As InDesign matured, the scripting engine became more powerful and capable. Each version of InDesign brought a quicker, more efficient scripting engine. In recent versions, except for the most demanding procedures, you can hardly tell the difference between the performance of a “native” plug-in, and an optimized script. Of course the performance of the script will highly depend on how it was written, but a veteran script writer should know how to write scripts that run efficiently.

On top of that was the introduction of events, and Script UI. Events allowed for scripts to run dynamically in the background and Script UI allowed for user interfaces which reacted dynamically to user input and context.

The division between “plug-ins” and “scripts” became very blurred. The only clear differentiating point remained the language the add-on was written in. Plug-ins are written in C++, while scripts are written in one of the higher level scripting languages.

The only two use cases where “plug-ins” remained the clear winner, is where functionality was needed that didn’t exist at all in InDesign, or very high performance was critical.

Hybrid Plug-ins

These distinctions are further blurred by the fact that an add-on does not need to be 100% “script” or 100% “plug-in”. It’s quite possible to mix C++ code with scripting code to create a seamless product (and quite a few of these products exist!) The starting point of such code can be a “script” or the whole thing can be compiled into a single plug-in. It is entirely invisible to the user whether a specific feature is implemented as a “scripting feature” or as a “plug-in feature”. In fact the implementation can be split up into a custom implementation like was done with APID (which we utilize in our products).

Enter: “Extensions”

In CS5, Adobe introduced a new concept: “Extensions”. Extensions can be written using the CS SDK. They are programmed in Flex and ActionScript, and compiled as swf applications. These extensions are an entirely new class of “add-ons”. They have all the capabilities of AIR applications, and all the functionality of integrated scripts. Script Bay is one example of such an extension. Mini Bridge, CS Review, and Kuler are other examples.

Extensions have many of the UI advantages of plug-ins, and can be contained inside native panels. There are quite a few new events in CS5 which allow even tighter integration into the program. In addition, “extensions” can work across the different programs of the Creative Suite.

Conclusion

The basic fact remains. There’s many ways to extend InDesign, and there is no clear “right” way to do it. Sometimes it makes sense to implement a feature as a plug-in. Other times it makes sense to do it as a script, other times, a hybrid, or custom solution is required.

In many situations, it is even difficult to define whether a specific add-on is a “script” a “plug-in” or something else. That fact is, that to the user, it doesn’t really matter that much what the definition of the product is. The technology used to create add-on functionality is mostly a developing consideration. From a user perspective, it’s just important that it allows the user to do what they need!

If you are purchasing a commercial “add-on” don’t concern yourself too much with the technology used to create it.

If you need a custom solution created, things are a bit different. Make sure that whoever you hire is familiar with all these technologies, or you might end up paying extra money for a product which could be created cheaper using a different technology.

Tags: , , , ,

2 Comments

  1. […] This post was Twitted by astutegraphics […]

  2. […] difference between plug-ins and scripts is confusing. Add to that the new concept of an Extension. Here’s an article that breaks it down for you by a guy who […]

Leave feedback