If you’ve been present in our community Discord, Slack, or forum, you’ve likely already read about our long-standing goal of moving away from extensions for core functionality to native implementations. We've made near complete progress in this area. In previous major versions of our application, behavior like autocomplete tags, folders, and even duplicating a note were all implemented as external extensions that were loaded into the core application via an iframe mechanism. The philosophy behind this architecture was that implementing “extra” behavior behind extensions allows us to keep the core app slim and easier to maintain.
However, the observed effect was precisely the opposite. Extensions began drifting away from core app improvements and changes, and became more difficult to maintain over time. Because extensions communicated with the core app via a JSON message bridge, any new functionality extensions needed to gain required new messaging mechanisms, which made the API more bloated and less rigid. Extensions also needed to implement their own UI from scratch, and while we took advantage of a shared library for common styles and components, the effect was nonetheless that the look and feel of extensions drifted away from that of the parent application.
Moreover, extensions living in their own island meant a general disconnect in UX, and an unpleasant “first-time” experience whereby users needed to understand what extensions were, how to install them, how to enable them, and how to disable them if they wanted to revert to the out-of-box experience, which was usually a more primitive form of the extension experience.
Lastly, building functionality such as tag folders behind an extension meant that our communication bridge between the core application and extensions needed a permissioning system for streaming batch items. This meant that third party extensions could also take advantage of these same mechanisms. We felt this architecture increased the surface area of potential misuse of the API. While extensions could not batch request access to all your notes, we felt that a batch request of any kind should be disallowed by our API to maintain a stricter environment and a less worrisome surface area for our engineers.
For all the reasons above, and several other untold intricacies of bundling core functionality as extensions, we decided, perhaps as early as 2019, to move in the direction of building a more cohesive out-of-box experience that “just works” without you having to think about how it works, or how to enable the it just works feature. Because the extensions architecture was so ingrained in our ecosystem, it took time to get here. But we've finally arrived at a point where the only extension concepts that remain are themes and editors.
Editors is a concept we believe lends itself really well to extensions. There are a thousand and one ways to edit a document. And surely no matter how prescient we are, we could not build nor bundle all of those ways into one editor. We believe the ability to replace the built-in plaintext editor with custom editors like Spreadsheets, TokenVault, or the variety of other hyper-specialized editors we offer, is essential to an experience that doesn’t lock you into one format, and grows and adapts with the popular editing formats of the time.