TL;DR
This post picks up from the initial Project 2036 post to go into more detail about the proposed v5.4.0 release.
- The proposed v5.4.0 release is focussed on improvements that require small breaks in backwards compatibility
- The primary goal is to clear the existing backlog of new features that have been held up due to backwards compatibility concerns
- A secondary goal is to add the groundwork for tentpole new features that have become table stakes amongst our competitors
- We will trim the functionality that is included in this release so that we can achieve a mutually agreed target release date
- We would welcome feedback on these plans, including the specific features to be included
Most importantly, this is not a call to compile a general wish-list of new features. To get anything done we need to focus on establishing and achieving much tighter and more specific goals for this release.
Introduction
A unique thing about TiddlyWiki is the value that we put on making it future proof. We want users to be confident that their TiddlyWiki data will be under their control and freely accessible for as long as it is needed. We also want 3rd party plugins and templates to continue to work without requiring constant maintenance. We achieve all of this by being rigorous in maintaining backwards compatibility.
At the same time, we want to keep improving TiddlyWiki so that it becomes more usable, flexible and powerful over time, and hence more useful. That process of continuous improvement is arguably what drives a lot of community activity: discussion with users influences the direction of TiddlyWiki, and users can choose to contribute directly to improving TiddlyWiki.
However, there is a clear tension between these two goals. There are many perfectly reasonable improvements that we cannot make without minor breaks in backwards compatibility.
Accordingly, if you follow the development of TiddlyWiki on GitHub you will have noticed that there are quite a few worthwhile improvements that have been held back on the grounds that they break backwards compatibility. Examples include:
- Allowing comments within filters and between widget attributes
- Improvements needed to TiddlyWiki’s support for bidirectional scripts
Clearing this backlog of potential improvements is the motivation for a new release of TiddlyWiki that judiciously and surgically makes some modest breaks in backwards compatibility. From the perspective of end users, this will provide a wealth of welcome improvements and fixes. For developers the result will be a cleaner TiddlyWiki that is easier to work with.
Criteria for inclusion in v5.4.0
This list almost entirely comprises new features and updates that have been held back due to backwards compatibility concerns. To maintain momentum, to be considered for v5.4.0 these PRs need to be essentially ready to be merged.
For example, 5 years ago we did some experiments that showed that there would be only a very minor practical impact from making the default behaviour be to allow duplicates within filter expressions. This would clear up a significant pain point, particularly for those heavily using the maths operators but it would undoubtedly not be fully backwards compatible.
A criterion for breaking backwards compatibility is that the break must be minor, with an accompanying solid argument as to why it should not affect users in the field. If the backwards compatibility break is likely affect existing usage of TiddlyWiki then it belongs in TWX.
I have also proposed a couple of bigger tentpole features that we have never got around to but that are now table stakes for note taking software. In some cases I don’t expect to have the features fully fleshed out in v5.4.0, but I hope we can at least include the groundwork and necessary backwards compatibility breaks. The best example is WYSIWYG editing functionality.
There is also room for improvements that are either trivial to implement, or would be inconvenient to maintain as a long term PR. For example, we don’t have PRs for the improvements listed under streamlining, but they are all relatively straightforward to implement. The key requirement is that the improvements require a break in backwards compatibility.
We must avoid letting this turn into a general wish list for the future of TiddlyWiki; most of that discussion belongs in a separate TWX thread. Here we need to ruthlessly focus on the feature backlog, and these few important new features that require active development.
Schedule
It is too early to be able to figure out a precise date for v5.4.0 because we need more discussion about what should be included. I think the best we can do is agree a rough target based on our collective sense of what feels right. We would then trim and refine the work to fit the timescale.
We also need to discuss whether we should make an interim v5.3.7 release with the updates since v5.3.6 was released in November 2024. The argument would be that v5.3.6 is now roughly the same age as v5.3.5 was when we released v5.3.6. If we defer the outstanding changes until the v5.4.0 release then we’ll have features that were merged back in November/December last year sitting on the shelf for more than 6 months.
For the moment, my proposal would be that we imminently make a v5.3.7 release, and then we shift our entire development effort to v5.4.0. We would still be able to make a v5.3.8 bug fix release if it was needed, but for example the prerelease on the website would be v5.4.0.
Table stakes
These are features that are generally available in other products that are needed in order for TiddlyWiki to remain competitive and up to date. Some of them will require significant development work; the goal for v5.4.0 is to lay the groundwork and make any necessary backwards compatibility breaks.
- True single tiddler mode
- Optional new page layout similar to Obsidian/Notion with instant editing
- Improve wikitext interoperability with Markdown by supporting a subset of Markdown features
- Wikitext WYSIWYG editor feat: serialize AST node back to wikitext string by linonetwo · Pull Request #8258 · TiddlyWiki/TiddlyWiki5 · GitHub
- Syntax highlighting of TiddlyWiki wikitext
- Links to section mark - Feat: allow link to section mark by linonetwo · Pull Request #7744 · TiddlyWiki/TiddlyWiki5 · GitHub
Existing PRs held back due backwards compatibility concerns
- Default to not removing duplicates in filters - Add switch for enabling duplicates within filters by Jermolene · Pull Request #3790 · TiddlyWiki/TiddlyWiki5 · GitHub
- Multivalued variables - Introduce multi-valued variables and let filter run prefix by Jermolene · Pull Request #8972 · TiddlyWiki/TiddlyWiki5 · GitHub
- Bidirectional text improvements - Bidirectional text improvements by Jermolene · Pull Request #7557 · TiddlyWiki/TiddlyWiki5 · GitHub
- Fix crash with empty transclusions - Fix crash with empty transclusions by Jermolene · Pull Request #8145 · TiddlyWiki/TiddlyWiki5 · GitHub
- Enable duplicates within filters - Add switch for enabling duplicates within filters by Jermolene · Pull Request #3790 · TiddlyWiki/TiddlyWiki5 · GitHub
- Colour handling improvements - https://github.com/TiddlyWiki/TiddlyWiki5/pull/8702
- Dynamic build commands - Dynamic build commands by Jermolene · Pull Request #8689 · TiddlyWiki/TiddlyWiki5 · GitHub
- Bundled sub-plugins - Introducing bundled sub plugins by Jermolene · Pull Request #8957 · TiddlyWiki/TiddlyWiki5 · GitHub
- Upgrade encryption from 128 bits to 256 bits Set AES strength to 256 bit by pmario · Pull Request #8249 · TiddlyWiki/TiddlyWiki5 · GitHub
- Allow comments within filters add // filter comment till linebreak by pmario · Pull Request #8191 · TiddlyWiki/TiddlyWiki5 · GitHub
- Background actions and media query tracker mechanisms - Introduce background actions and media query tracker mechanisms by Jermolene · Pull Request #8555 · TiddlyWiki/TiddlyWiki5 · GitHub
Proposals that breaks backwards compatibility but have no PR
- Fix the core to not require camel case linking so that it can be optionally disabled by users
- Ability to use the location hash to customise startup behaviour
- Use bundled plugins to establish way for plugins to embed their own language plugins
- Extend import to also import let widgets
- Default advanced search tab to be filter
- Default to fluid-fixed
- Max width for story river, centring
- Independent version numbering for plugins
- Comments in between attributes
- Line breaks within filtered attributes
- Deprecate all old palettes in favour of those from https://yatagarasu.tiddlyhost.com
Deprecating dangerous, confusing, unnecessary features
All require breaking backwards compatibility
- Replace safe mode with something more useful
- Remove old event catcher syntax
- Deprecate view and reveal widgets
- Redefine standalone
{{{filter}}}
syntax to be more useful - Deprecate keyboard driven input macro, replace with lower level primitives based on custom widgets
Streamlining
These proposals are concerned with making TiddlyWIki more efficient, with less redundancy.
- Remove some obsolete build artefacts from the website
- Remove deprecated components to a plugin where possible
- Remove commands and other Node.js cruft from single file wiki
- Plugin compression/decompression with GitHub - 101arrowz/fflate: High performance (de)compression in an 8kB package
Internal improvements
- Adopting a more modern subset of JavaScript
Documentation
- We will need a new section on tw-com for backwards compatibility, with individual structured tiddlers about each backwards compatibility break
- A new symbol for the release notes and the docs to indicate backwards compatibility breaks