| Solution | Pros | Cons |
|---|---|---|
| Plugins | - Allow extending apps with various functionalities - Widely adopted in many modern software ecosystems, enhancing versatility - Allows forming community that creates and maintains plugins - Non-programmers can use existing plugins that someone else created |
- Only allows for a limited form of malleability; plugins are more of an outer layer of customization - Usually can't modify core functionalities or deeply ingrained software behaviors - A plugin created for one platform usually can't be used on another, leading to platform lock-in - Can result in fragmented development, with popular features being redundantly developed for different environments |
| Black-box Interface Extensions | - Allow for the modification of legacy software which doesn't have built-in plugin architectures - Can modify app interfaces without needing access to internal structure or source code, enabling adaptability - Reduces compatibility issues seen in traditional plugins - Provides diverse ways to interface — code injection, visual editing, etc. |
- Primarily for enhancement, reorganization, or integration; not suitable for building systems from scratch - Restricted by the features and limitations of the targeted apps - Cannot be used to repurpose parts of an app |
| Interface Embedding | - Enables sharing functionality across applications by embedding interfaces/documents within each other - Potentially offer a variety of embedding solutions like HTML iframes - Provides mechanisms like embeddable widgets, enabling users to easily incorporate specific functionalities into personal sites - Promotes externalization by allowing copy-pasting of interface elements, fostering reuse |
- Embedded elements are completely isolated, limiting interoperability between them - Can't solve complex integration challenges described in broader scenarios due to this isolation - Essentially recreates the app but at a more granular level |
| Live Objects Systems | - Each visible object is directly linked to its underlying functionality, allowing real-time editing and customization - Provides a very direct workflow for adapting and enhancing the user experience - The principle of "the thing on the screen is the actual thing" ensures that every interface element (morph) can define its own representation, state, and behavior - Context-oriented programming (COP) offers dedicated language abstractions for defining and composing adaptations, addressing some of the paradigm's limitations |
- Excessive coupling can lead to brittle interactions, meaning components might break if moved or altered outside their original context - Interactions are mainly defined within and across morphs, leading to cross-cutting concerns - Fundamental challenges arise in dealing with interactions, especially in malleable systems where objects frequently change - Scattered code across multiple modules complicates adaptations and increases the risk of errors |
| Webstrates | - Support for real-time collaboration by synchronizing DOM content across multiple users and devices - The model turns web pages into collaborative WYSIWIS interfaces, blurring the distinction between documents and apps - Webstrates allow for malleability at different granularity levels - Easy externalization of parts of web pages as HTML markup, enabling rapid integration into other pages |
- Relying on conventional code leading to challenges like code scattering and excessive coupling, similar to live object systems - Tools designed for specific webstrates might embed assumptions about structure and naming, potentially causing compatibility issues - Strict assumptions about structure and naming limit the flexibility - Adapting and reprogramming elements for new contexts can be challenging |
| Control Structures for Interactions | - A diverse range of control structures, like event listeners, state machines, and constraint rules - Aiming to achieve a better expressive match between code and desired interactive behavior, aiding developers in writing more intuitive code - Can make the code more maintainable and less error-prone |
- Developed with the assumption of rigid systems where interactive behaviors remain stable, limiting flexibility during runtime modifications - Their run-time forms are generally highly divergent, meaning they can't be easily modified at run-time unless originally designed for such adjustments - Can introduce couplings that hinder other system adaptations |
Based on Designing and Programming Malleable Software by Philip Tchernavskij