… and are never going away (not speculation). In a phrase, backward compatibility.
Removing them, dropping support for them, would render TiddlyWiki a whole new project, like when classic moved to 5. In other words, TW5 today and tomorrow will forever support a TW5 from yesterday (and yesteryear).
That’s a good thing.
Yes it is. It’s great to be able to count on my wikis continuing to work, and to need little or no change in order to upgrade.
It’s also a bad thing, as it continually increases the cognitive load required to understand TW, as well, I assume, as the size of the core itself. It also makes it increasingly difficult to add features…
There’s no good way around this. Backward compatibility is fantastic. But it’s important to recognize the drawbacks alongside the benefits.
The long rumored TWX. I did once meet a guy from the future who said it never really got off the ground. And neither did Starship, so it’s in good company 
The plan is that at an as yet unspecified point in the future we would intentionally break backwards compatibility with a “TiddlyWiki 6” which would be the current code with the old, deprecated mechanisms removed. It would be a subset of whichever 5.x.x version was current at the time.
In such a situation, we would likely continue to release updates to the v5.x.x line. Crucially, it would be possible for authors to make plugins that worked in both 5.x.x and 6.x.x as long as they avoid the deprecated features.
TiddlyWiki 6 might also be the point at which we switch to a more modern JavaScript dialect, which would have implications for browser support.
To add that this is distinct from another idea that we have discussed over the years: “TWX”, which is a future re-working of the TiddlyWiki core that would distill everything we’ve learned from TiddlyWiki 5 but wouldn’t be backwards compatible. It might be very different than TW5: for example, a kernel written in Go or Rust that runs under WASM in the browser. My current thinking is that the first incarnation might not be a wiki at all, but a Figma-like shared vector editor with all the organisation, transclusion and composition features of TiddlyWiki.
It frequently crops up in GitHub discussions, and is under ongoing consideration. But we have yet to make firm plans. I am certainly keen to have a clear roadmap by the time of the anniversary in September next year.
It is one of those cases where the needs and motivations of developers can be tension with those of regular end users. There is strong support from developers for updating our JavaScript dialect, but there are also severe ramifications for end users; it would mean that TiddlyWiki would cease working in browsers made before 2018. While those older browsers are undeniably getting rarer, the people who are still constrained to use them are often the most disadvantaged users. TiddlyWiki wants to be universally useful, which means it needs to be inclusive and supportive of all users.
Right now, I don’t see “TiddlyWiki 6” as providing a compelling end user proposition. That will change as we make further improvements to the core and polish what we’ve got. The tipping point would be when TiddlyWiki 6 could plausibly perform better for the majority of ordinary users.
Thank you. Much appreciated. I’m hearing NET late 2025 if not 2026.
While we have you here (and now way off topic – I’ll split this off, probably) what is your vision for, say, 5.5? That’s a significant point numerically on the journey toward 6.0, at least. What changes are you expecting to see? How different might TW5.5 look? What might devs/powerusers/plugin-authors expect to see?
Thanks.
(I know, I’m treating this like you offered up an AMA but since the YT stuff died off…) 
I stand corrected. There is one good way around this. On very rare occasions, make a determined break with backward compatibility, making sure the older version is long supported and that the new one is compelling enough to encourage people to make the changes necessary to update. (Python 3, anyone?) For a project like TW, once every five years might be reasonable.
I hope it does come soon. But I understand the reluctance. I started a library over a decade ago now, and was working in an environment that had to support ES3. The library has never moved beyond that (although a few ES5 things may have slipped in, since nobody is actually using it with anything older than that, I’m quite sure.)
I’d be curious to learn what that might look like. Is the idea that the underlying philosophy of TW – especially the uniform nature of all content, including even the UI – would be applicable to domains beyond web pages?
This can be true, but the quality of the documentation, which provides realistic alternatives, with new functionality can reduce the cognitive load substantially. There are things within tiddlywiki even now, that fade in the minds of people because they have better alternatives. But they remain inside tiddlywiki.
I suppose there is a difference between understanding “everything tiddlywiki can do” including deprecated features and “understanding how to do everything, with tiddlywiki” in which you can sometimes ignore deprecated features.
Of course. The trouble is when you run across older code. “Hey, this plugin is doing just what I want. I wonder how it works?” Old code takes a long time to fade away.
And there in is the fact you want to read the code, and learn from other code, so you can write code (me too). I expect a large proportion of users just want it to work, and don’t care how.
Far too often when I have seen a feature I like, I start afresh and try to reconstruct it from my current knowledge, and only revert to historical examples if I am stuck.
Having lost tons of data and time in the changes of different LearningManagmentSystems I was forced to use, this sounds a somewhat terrifying. The eternity-promise to me was always one of the keyfeatures of TW.
It would be a helpful promise If there were modules to reimport the deprecated features and keep things working if some relevant widgets etc were omitted.
That promise is not going away.
The transition would be somewhat like that from TiddlyWiki Classic to TiddlyWiki 5. Version 5.x.x would continue to be available, and continue to get updates to the extent that contributors wish to work on it.
From a users perspective, it would be perfectly possible to continue on 5.x.x indefinitely, just as TiddlyWiki Classic is still actively used by many people today.
If users want the latest and greatest features then they would need to transition to 6.x.x, but that would be much easier than before. The fact that plugin authors could very easily make hybrid plugins that work in both 5.x.x and 6.x.x should mean that the key plugins that are depended on by many people would be available in both versions.
Another key difference from the transition to TW5 is wikitext compatibility: the wikitext of TW6 would initially be a strict subset of TW5, so ordinary textual content wouldn’t need adjustment,
Phew. It was a drawcard for me.
I think it reasonable though, to announce a departure from backward compatibility for the sake of advancing TW to a secure position that meets future possibilities.
Easy for me to say however, since I use TW in a rather non-tech way. But it begs the question, what happens if I don’t update?
I’ve been using TW with minimal knowhow for over a year now. I’ve update once, still on 5.3.0
I imagine it’s a little different for everyone depending on what kind of customisations they’ve made. I’ve tried to document anything new I’ve learned to embellish my wiki — just as well as I tend to forget anything I’ve learned unless I’m all over it every day.
There must be many “unknown” people still using TW on a daily basis.
If I may ask, what kinds of things besides the compatibility with ancient browsers would be removed?
Also, I am wondering if, for the next iteration of TW, the foreign language component could be done where all the language-related tiddlers are not part of TiddlyWiki but separate as a plugin called LanguageBuilderPlugin or something like that, and where each language-maintainer-person would build on top of that plugin to create their language’s plugin.
It seems like that might reduce the filesize at least a bit for many of us who don’t use foreign languages.
I found recently TW5 PR accept speed is slowing down, this can be more significant when you move attention to TW6, what’s your plan to address this? @jeremyruston
And in the future, maybe we can use LLM agent to translate TW5 features to TW6, the later we do this, the more powerful AI we can use. So it’s good to wait a while before TW6.
Not much, because of the way that TiddlyWiki works you’ll be able to continue to use it as long as browsers support the features it needs.
Things only get tricky if there is a later update to an essential plugin that requires a later version of the core. In such a case there would presumably be a benefit in upgrading, and so the balance of the decision might change.
In other words, as long as you’re happy for things to stay the same, you only need to worry about things like a future browser update requiring changes to TiddlyWiki itself. That hasn’t happened so far, but it remains a possibility.
For some users, the best way to navigate all of this is to proactively keep themselves on the latest and greatest version of the core, rather than risk that skipping lots of versions that will make any subsequent upgrade harder.
The compatibility with ancient browsers comes from our desire to update to a more modern dialect of JavaScript. It’s not really essential to the idea of TiddlyWiki 6 as discussed here, it’s really a separate change that we may decide to make at the same time, or may decide to defer, or bring forwards.
The main changes for TiddlyWiki will be that a bunch of features will move into a special deprecated plugin. Users (or plugins) that need any of those features will need to make sure that they have the plugin installed, but it won’t be part of the standard distribution.
Examples of those features include the fieldmangler widget, the encrypt widget, some obscure operators like “storyviews” (not storyviews themselves, just the operator), the rendertiddlers and savetiddlers commands, some older savers like the ActiveX ones for Internet Explorer.
We would need to take a decision about keeping macros in the core or moving them to the deprecated plugin. It would be largely symbolic since macros use practically the same code as procedures.
There are also some changes that we’d like to make to the core that are intrinsically not backwards compatible, and these would need consideration too:
Once we start this work, there will need to be a lot of detailed discussion about the implications of the changes as we work to balance the tradeoffs.
Foreign languages do not take up any space in the core because they are already published as independent plugins, but the core does contain the root en-GB “translation”.
It may be worth starting a GitHub discussion on this, but I think these plans would depend on moving the TiddlyWiki 5 repository to the TiddlyWiki · GitHub organisation, which would allow us to use more granular permissions to spread the workload. And as always please feel free to drop a comment on an outstanding PR to bring it back to my attention.
I would ask for a further promise, that being portable and a quine remains, specifically without needing to run a binary.
I used TiddlyWiki Classic for a while and returned to this software with TW5 recently. It has one thing almost no other such program has. I work in a large corporation where we work only on company machines and their own provisioned software. Importantly I’m not in IT (like most employees) and I’m therefore very restricted in what I can run on my machine. So I’m personally limited to either TiddlyWiki or OneNote (comes with O365) for personal notes. There is absolutely no way that our CISO would let us connect to Obsidian or run Emacs locally to use Org (just an example on two ends of the usability spectrum). Tiddlyhost is also blocked by our work VPN.
So from a very high level perspective for the corporate worker with a typically restricted device, these are killer features for the freeform setup TW is designed around.
Beyond this basic approach, it is about polish and customising in a certain way. These issues are a common theme on this forum so I’ll be brief. As an end-user I would say briefly
But these are small things - the key is to not require running a webserver or to run from an executable/binary file. It has to be an HTML. Both of the former would be blocked by a corporate firewall, and TW would cease to be an option in the office.
I want to also say to the community that I’m very glad that virtually no-one assumes nodejs is running in the configuration for their plugins, because I will always be a single file user. I also appreciate that while many of you use it in the workplace and are highly empowered/have your own devices, you still work on in-file revision mechanism and other such things. Your asceticism is a blessing to us ‘protected’ from truly personal computing.
I have faith you will anyway as TW Classic worked much the same, but I haven’t seen my specific scenario mentioned online since the need for running from thumbdrives has declined. So there it is - not sure how common it is, but I can say that many large businesses function the same way when it comes to cybersecurity and what the average employee is permitted to use.