Some thoughts on backward compatibility

[EricShulman]

An interesting side note about backward compatibility…

The syntax I used in the TiddlyTools/PrintTiddler toolbar button includes \procedure and “substituted attribute values”, which were introduced in v5.3.0 (1st July 2023), and also “conditional shortcut syntax” (<%if ...>), which was introduced in v5.3.2 (13th December 2023).

I decided to test TiddlyTools/PrintTiddler by importing it into the various “Beautiful Wikis” posted in the Cafe section. It was then that I noticed that some of these excellent wikis are based on older versions of the TWCore… some using v5.2.x, and even a few using v5.1.x. The result was that the toolbar button did not work and produced some very ugly display of the unrecognized syntax.

To address this, I’ve re-written a few bits and pieces of TiddlyTools/PrintTiddler.

Changed

\procedure print()

to

\define print()

Changed

<div style=`zoom:${[{$:/print!!zoom}]}$%;`>
and
<$transclude tiddler=`$:/core/ui/ViewTemplate${[{$:/print!!template}]}$`/>

to

<div style={{{ [[zoom:]addsuffix{$:/print!!zoom}addsuffix[%]] }}}>
and
<$transclude tiddler={{{ [[$:/core/ui/ViewTemplate]addsuffix{$:/print!!template}] }}}/>

Changed

<%if [<tv-config-toolbar-icons>match[yes]] %>{{$:/core/images/print-button}}<%endif%>
<%if [<tv-config-toolbar-text>match[yes]]  %>@@.tc-btn-text print@@<%endif%>

to

<$list filter="[<tv-config-toolbar-icons>match[yes]]">{{$:/core/images/print-button}}</$list>
<$list filter="[<tv-config-toolbar-text>match[yes]]">@@.tc-btn-text print@@</$list>

These changes added just 50 bytes to the code, but allows TiddlyTools/PrintTiddler to work properly with some much older TiddlyWikis.

-e

[Scott_Sauyet]

@EricShulman

An interesting side note about backward compatibility…

That’s a hard call. The longer we stick with backward compatibility, the more widely useful a tool is… but the harder it becomes to make the transition to more modern techniques.

I’ve ended up making the opposite choice for myself. I use the latest syntax without concern, preferring <% if %> to <$list>, and choosing procedures over macros for everything but the most trivial static definitions. I’m slower to move to substituted attribute values, but am moving that way.

My reasoning is simply that – because TW itself so strongly supports backward compatibility – it’s generally straightforward to move a wiki from 5.2.x to latest. So if someone wants to use my tool, I assume they can get their wiki itself updated. I’m sure that assumption isn’t always warranted, but I can live with that.

You’re in a different position, though. Most of my work has been on whole wikis, and my tools have derived from that work, occasionally shared with the community if they seem useful. You, on the other hand, clearly build tools for the community. I’m very impressed with the breadth and depth of TiddlyTools. I don’t know what call I’d make if I maintained so many widely used tools.

I don’t envy you that decision. But I can certainly understand your choice.

[EricShulman]

As you’ve noted, TiddlyTools is intended as a general TiddlyWiki resource – a virtual hardware store to help people enhance their TiddlyWikis – and most of my TiddlyTools add-ons are designed to be “plug-and-play” wikiscripts that can be easily added to live, published TWs without requiring upgrading or even a save-and-reload cycle.

For example, TiddlyTools/Time/Calendar is a single-tiddler add-on that can be dropped into virtually any existing TW5, regardless of the TWCore version that TiddlyWiki is using. (Try adding the Calendar to TiddlyWiki.com and you’ll be able to view an instant year-by-year overview of tiddler additions/changes that track the evolution of the main TiddlyWiki distribution site.)

Initially, I thought as you did, and planned to start using the latest syntax enhancements after waiting a reasonable amount of time for them to be generally adopted by the community. I figured perhaps a year after introduction of a new syntax would be sufficient.

But then, I found that there are still a great deal of older TWCore versions in use, and many people stick with those older versions even if they are still actively maintaining and updating their specific TiddlyWiki wikiscripts content.

Also, as illustrated by some of the sites highlighted in the “Beautiful Wiki” postings, there are some really spectacular published TWs that are stable and have no need for further upgrades. It was my experiments with using drag-and-drop to add TiddlyTools/PrintTiddler to these older TWs that really brought the “backward compatibility” issue to the forefront.

In light of this, I’ve decided that it is better for TiddlyTools add-ons keep using the older syntax except when the newer syntax offers a distinct and compelling advantage, such as making an add-on significantly more performant or by vastly reducing and simplifying it’s code.

-e

[XLBilly]

As a python example I mentioned before:

Confusing discussion about backwards compatibility

Recently I’m trying to maintain a python library to support type hints. Because it requires python newer than 3.7, I tried to make type linting supported in older Python versions and found it very tricky: X | Y syntax is not supported in 3.7, so I have to use Union[X,Y] and Optional[X] instead list[T],tuple[T] syntax is not supported, so I have to use List[T] and Tuple[X], which requires adding: from typing import List, Tuple typing.Self is not supported in python lower than 3.11 It mea…

IMO the downside of being backward compatible mentioned in the example is more difficulty to maintain for lack of beneficial benefits, like using addsuffix instead of text substitution syntax, using $list widget instead of conditional syntax, using <<__param__>>,$param$ , $(var)$ instead of <<param>>, <<var>>. Since newer version of tiddlywiki has excellent support for backward compatibility, I think there should be urge for users to upgrade their wikis.

Perhaps providing a v5.3.x modern version of the macro for better maintainence for the future, while a legacy version for backward compatibility is a better solution.

[Scott_Sauyet]

@XLBilly

Perhaps providing a v5.3.x modern version of the macro for better maintainence for the future, while a legacy version for backward compatibility is a better solution.

While that is clearly great for users, it more than doubles the burden on maintainers. It’s even worse if the maintainer – as most maintainers do – bundle their tools into multi-tool wikis.

It would take time from creating new tools, and that would be sad.

But the current situation has its own downside. One of the most prominent members of our community, in his most prominent contribution, doesn’t get to model the TW style we’d like to promote. I certainly understand and respect his decision, but it’s also somewhat sad

[EricShulman]

In my previous post, I noted that I decided to keep using the older syntax

except when the newer syntax offers a distinct and compelling advantage, such as making an add-on significantly more performant or by vastly reducing and simplifying it’s code.

In your response, you wrote:

the downside of being backward compatible… is more difficulty to maintain for lack of beneficial benefits

However, if the exact same functionality can be implemented using the older syntax without any significant impact on performance or code complexity, then using that older syntax has no net downside and, as noted by @Scott_Sauyet, it saves me from having to test and maintain two versions of the same functionality.

In addition, providing alternative versions would greatly complicate the publishing and distribution of TiddlyTools add-ons. It would require extra coding strategies to prevent “collisions” between the alternative versions existing in the same file, and would also require that end-users understand the difference between the “modern” version and the “legacy” version so they can consciously choose which is the right version for their use.

Lastly, while we certainly can try to “urge … users to upgrade their wikis”, TiddlyWiki has always made an extremely strong promise towards providing “painless” backward compatibility, even as the TWCore has continued to evolve and gain exciting new features and functionality. This is why the upcoming v5.4.0 is being so carefully curated to minimize the anticipated impact that those compatibility-breaking changes will have.

-e

[TiddlyTitch]

@EricShulman

I noticed that some of these excellent wikis are based on older versions of the TWCore… some using v5.2.x, and even a few using v5.1.x.

@EricShulman

I found that there are still a great deal of older TWCore versions in use, and many people stick with those older versions even if they are still actively maintaining and updating their specific TiddlyWiki wikiscripts content.

@EricShulman

I’ve decided that it is better for TiddlyTools add-ons keep using the older syntax except when the newer syntax offers a distinct and compelling advantage

Yes!

And, given your knowledgeable beard, you are the perfect bloke to juggle the differences in TW versions into optimal, ongoing, broad utility.

The fact those older wikis still function perfectly well for their purposes stands out to me.
They don’t need to update their cores.

They, so far, all, evidence the likely true viability of a TW 30 Year Rule (make <<now for YYYY +30>>

TT

p.s. Your new Print Tiddler Button is great. And in a snap it’s installed.

[TW_Tones]

I support @EricShulman’s approach but similtaniously maintain my key wikis at the latest core version. When plugins and solutions are released with newer syntax they have more utility as demonstrations of writting tiddlywiki script with the new features.

I would suggest that new solutions that serve as good examples, or provide substantial hackability are best deployed with a modern syntax.

It is well understood that if you dont update the core over time you will get further from being able to do so or make use of new tools and features.

I think here we need to maintain both “concepts similtaniously”.

Erics example of a tool that lets you review changes by installing on any wiki is a case for maximising compatibility.