Future Proofness

[Bruno Wassermann]

Hi there, 

I am a complete newbie to TiddlyWikki, the concept of small tiddlers interlinked in different ways resonates with me and I am considering to eventually migrate from Evernote to TW5. I am starting to understand that this might require a substantial investment, which has prompted me to try and understand the degree to which this time investment will continue to pay off in the future. 

I know that there are many dimensions to this question (i.e. TW is open source and so anyone can contribute and continue to maintain it just in case, HTML5, JavaScript, wikitext, and so on are probably going to stick around for a while and so on). 

However, I am trying to understand how painful it would be, if I ever decided, after moving and creating a few years' worth of notes into TW5, to migrate my notes to some other tool. 

I am not so much at home with frontend technologies, so please forgive my ignorance when it comes to JavaScript and friends. 

In the following snippet: 

<<list-links filter:\"[tag[tiddlywiki-example]] +[sort[title]]\">>

a. What kind of animal is the 'list-links' element? Or, what is a tiddler macro?

b. Is the filter syntax specific to TW?

c. By what kind of animal do these guys get evaluated? 

I have found https://github.com/Jermolene/TiddlyWiki5/blob/master/core/wiki/macros/list.tid. What does the actual flow look like from parsing a tiddler, to identifying that a macro should be invoked to actually invoking it? In addition, or alternatively, what would topics/concepts do I need to study to be able to make sense of this? 

All the best, 

-- Bruno

[Jed Carty]

Here are some quick answers, ask more if you have other questions:

a - In your example list-links is a wikitext macro. It is short hand that is parsed and replaced by some wikitext which is in turn parsed and converted into html which is displayed as the output.

b - The filter syntax is specific to tiddlywiki. The way tiddlywiki handles filters and lists is as important to how it works as the linking and tagging.

c - Tiddlywiki uses JavaScript so everything is evaluated in your browser by the javascript engine.

You don't have to understand anything about the parsing or javascript to use tiddlywiki or to make complex applications with it, so you may want to just look over some of the reference sites. Looking at how other people have created things is probably the best way to learn.
Looking through the code is probably your best bet for making sense of everything if you want a deep understanding of it. If you want to understand everything than you need some javascript, but there are plenty of people who have learned javascript by playing with tiddlywiki so I don't think that is too huge a task.


Here is a list of some reference sites:

http://erwanm.github.io/tw-community-search/ - this is a community search site that indexes a lot of other sites

http://inmysocks.tiddlyspot.com (this one is mine, but I have been bad at updating it)
https://tobibeer.github.io/tb5/#Welcome
http://twaddle.tiddlyspot.com/

These are lists of other sites:

https://tobibeer.github.io/tb5/#References
http://inmysocks.tiddlyspot.com/#Other%20Places%20to%20Look

[Bruno Wassermann]

Thanks a lot for the explanation and the links. 

I agree that learning how to make good use of TW will keep me entertained for a while, long before getting into its codebase. 

What kinds of changes to the 'runtime environment' of TW would necessitate changes to its codebase? For example, does a new version of Chrome or Firefox require the maintainers of TW to modify TW to make sure it continues to work well? What about the introduction of a new JS engine? 

-- Bruno

[PMario]

Hi Bruno,
Welcome to the club!

On Sunday, July 3, 2016 at 8:38:48 PM UTC+2, Bruno Wassermann wrote:

What kinds of changes to the 'runtime environment' of TW would necessitate changes to its codebase?

Short: Basically none.

---------------
Long:
You can change the TW codebase, using TW itself. Sharing your content is possible in different ways. ... You got some links from Jed. Many contributors also use the TW github repositorys.

The TW UI itself is built using wikitext. So you can see the power. ... However the TW UI wikitext is more complex, than what's needed for most users, because the TW UI needs to support multiple languages. The languages are plugins. So they can be switched live, if the plugins are installed. see: http://tiddlywiki.com/editions/full/index.html In my opinion this behaviour increases the TW UI source code quite a bit. ... To be fair: If you want to change the UI there is a relatively steep learning curve. (But it's still fun ;)

 

For example, does a new version of Chrome or Firefox require the maintainers of TW to modify TW to make sure it continues to work well? What about the introduction of a new JS engine? 

short: sometimes ;)

--------------

long: imo 2 questions:

a) New browser versions
b) New JS engine

add a)
I think the best example here is TWclassic. It is 10+ years old and still continuous to work well with the latest browsers.
The history: http://classic.tiddlywiki.com/#History tiddler has some interesting links. ... So you see, that both the browser vendors and Jeremy + the TW community did a good job to keep the content usable.

HTML itself is highly standardized and "human" readable. So even if you only have a text editor, it would be possible to extract your content. ... It wouldn't be easy nor fast, but it would be possible!

add b)
If there is a new javascript engine, it needs to be backwards compatible, otherwise it won't get any adoption. The best example here is Microsoft's Edge browser. It has a completely new js-engine. ... Unlike IE - TW works great with Edge, without any changes in the source code.

------------

As you may have found out, browser vendors try very hard to increase security for web users. ... TWs main usecase is file based. So from time to time we are forced to use work-arounds or browser plugins to make the file save mechanism convenient. A simple file download, which we call "the fallback" mechanism, should always work in the future. ... But it's kind of inconvenient.

So one good way to "force" browser vendors to deal with our needs is: a strong and big Community. If a big chunk of the browser users rely on specific browser features, we need to make them aware! eg: with useful bug reports. ...

So everyone can help! ... HELP WANTED!

have fun!
mario

[Mark S.]

The main problem I see, in terms of future-proofing, if you have followed the tiddler-semantic-unit philosophy, is that when you export your tiddlers they will be in little pieces that won't make sense to other information managers. The workaround is to export via aggregate pages as static pages  -- that is, a tiddler that combines other other tiddlers can be exported as a static web page.

Speaking of future-proofing and Evernote, last week EN boosted it's premium prices 40% and will be limiting it's free customers to 2 devices (where a computer counts as a device). Google had a product called Notebook which they then, in typical Google fashion, dropped. Then revived as Google Keep. Springpad was very popular but was abandoned without notice. Before Onenote, Microsoft had another note product which they also dropped.

From all this you can see that the problem with proprietary solutions is that there is zero transparency. You don't know if the company is making money with a product, what they hope to charge in the future, or if they plan to eventually sell themselves to some other company. You certainly never get to correspond with the CEO or lead developer.

There's a fair number of open-source information systems out there, but most of them are virtually orphans.

The great thing about TW is right here -- the extensive and active community. Should there ever be a reason to migrate (Like HTML25 requiring personal quantum entanglers) it's likely that someone else will already be working on various export options, and will be here to help you out.

Well, unless Google decides to do away with Groups, like they did RSS news, Sketchup, Notebook, and 40 other services you can view in the Google graveyard .

Good luck!
Mark

[Bruno Wassermann]

The argument that commercial tools do not offer a satisfactory (any) way to ensure the longevity of ones knowledge base is certainly true. I will begin to move part of my notes into TW and see how it feels when the rubber hits the road. 

Looking forward to HTML25 and quantum entanglers ;-) 

-- Bruno

[Josiah]

Ciao Mark S.

The TW community is a sweet thing. Likely fragile if anything went turbulent. But the current Google / Github thing looks pretty stable.

At ROOT TW has longevity from what it IS & has long been. . A very sophisticated JavaScript webpage. Here is mainly commentary & refinement.

MO.

J, x