AppleScript was designed to be used primarily as a scripting language, offering users a programmable mechanism for the control of and exchange of information with running applications. Scriptable applications provided a dictionary of terms and a grammar for communicating with them - for directing their activites and settings from outside their own code.
Any graphical user interface requires an event model - the system code that captures external events like mouse clicks, key presses, or floppy disk insertions and “informs” the running application of their occurence. Prior to System 7 the Mac OS application runtime had a rather simple event model that recognized and reported a small and fixed number of low-level events like “key was pressed” or “mouse was clicked”. Each application was responsible for decoding these low-level events into meaningful high-level user actions, like “select cut from the Edit menu”. In many cases the code for reading the event and decoding it was mixed together; for instance the code handling a mouse click might decode it to selecting the Quit item from the File menu, and then quit the application immediately.
To add AppleScript support to an application required that authors completely segregate this decoding from instructions to carry out the command, a task Apple referred to as factoring the application code. Developers were encouraged to write two complete event handling “stacks”, one for dealing with low-level events (clicks, etc.), and another for high-level events (AppleEvents that could include AppleScript instructions). The actual work code that handled these commands, once decoded, was to be completely separated and called identically from both stacks.
In OS X it is much simpler for developers to implement AppleScriptability, particularly in Cocoa applications, because under Cocoa events are decoded at a higher level and dispatched directly to the object that should get them. Cocoa factors the application code by default so the author doesn’t have to write event handling code.