Thanks. Author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right?
So I'm trying to understand the difference, the payoff. I understand that local web APIs are ass and you very quickly run into the need for a server.
But I'm wondering about the utility of combining the two approaches. It seems like a contradiction in terms. Here's a server to help you with your dev setup oriented around not needing a server.
I guess the main win would be cross device access? You have it online and you can edit it easily.
I'm editing my stuff on my phone in a text editor. And syncing it to my laptop with a sync app.
Thanks. Author mentioned TiddlyWiki as inspiration. But the whole point of TiddlyWiki was that it doesn't need a server right?
I did a deep dive on TiddlyWiki recently. No, it doesn't need a server; an entire site can be self-contained in one HTML file.
If you want to run it as a multiuser, web accessible wiki, it runs on top of NodeJS.
Turns out, the original TiddlyWiki used a java jar to handle the file persistence. (I remember it being so magically automatic, but recently investigated how it was done)
I don't think that's right - IIRC it used to be possible to write out a file, if loaded from a file:// URL, directly from JavaScript. Then that ability got nobbled because security (justifiable) without properly thinking through a good alternative (not justifiable). I mourn the loss of the ability, TiddlyWiki was in a class of its own and there should have been many more systems inspired by its design. Alas.
ETA: Wikipedia has reminded me the feature was called UniversalXPConnect, and it was a Firefox thing and wasn't cross-browser. It still sucks that it was removed without sensible replacement.
I used TiddlyWiki a lot to manage my D&D 3.5 campaign back in the day. As I recall, it originally was a true stand-alone HTML document capable of overwriting itself, but once browsers dropped support for this capability, users had to begin using various workarounds, and this remains the status quo today.
TiddlySaver.jar was one such workaround. A check in the Wayback Machine suggests that it was originally required only for Safari, Opera, and Chrome; IE and Firefox needed no such plugin. Nowadays, there are several workarounds, and setting up one is a mandatory installation step: standalone applications, browser extensions, servers, etc. Some are clunky (e.g. you have to keep your wiki in your Downloads directory or the browser can't write to it), and either way, TiddlyWiki is no longer truly a single stand-alone HTML file, at least not for writing purposes. It's still a very versatile tool, though.
How would TiddlyWiki write to filesystem (save) without a server?
I thought opening index.html in the browser was basically just a demo.
TiddlyWiki can replicate itself. All users can freely edit any TiddlyWiki and save their changes to their filesystem. There's a few options for exports.
It is a common gotcha that new users will lose some of their work while they learn persistence.
Tiddlywiki has two modes of running. In one, you simply save the file as HTML and all your content is saved inside the file.
The other mode is with a nodejs server (it's what I'm using). This allows me to access the wiki from all devices.
I see, so you make edits, the Javascript edits the html, therefore File -> Save Page will download an html file with your changes in it that you can open again.
I forget that File -> Save is even a thing for websites.
Note: The TiddlyWiki documentation explicitly advises that File -> Save Page does not work.
You have to click a save button in the app, and it will generate a valid copy. However, most users deploy some plugin or software which allows transparent auto-saving.
I used https://github.com/slaymaker1907/TW5-browser-nativesaver, that still works with the current version 5.3.8, though just in Chromium based browsers. You save the file once and from then on, as long as the tab is open, it autosaves itself.
That said, I advise against Tiddly Wiki, after using it for long. It has multiple bugs, which the author won't fix (e.g. div's inside p's), It has a cryptic syntax (e.g. code in attribute values), and tagging is not implemented in a way which makes a wiki scale (well, technically it is, tags can have tags). It is a thing where features are added but nothing outdated gets deprecated, so it is bloated. One will be more productive by using a folder with markdown files, and a browser add-on like Markdown Viewer.
I don't know, for me it works, but I don't do anything fancy with it. I just put it on a server, so I can access it from all my devices. I don't even use tags, just tiddlers with sources which are other tiddlers or external web pages.
My solution to a lot of issues is to use Tiddlywiki Classic. No divs inside p that I can find, less bloat (412 KB for a blank file instead of 2.5 MB), and it's still maintained. The main advantage, to me, is that it fits more tiddlers on screen at a time, which is the main point of TiddlyWiki for me; TW5 adds large amounts of spacing, borders, and large font sizes, which looks nicer but is less practical.
It's not perfect, though. Paragraphs are rendered by using two br tags, instead of p tags. Link syntax is the reverse of MediaWiki syntax; i.e. [[foo|bar]] links to "foo" in MediaWiki, but "bar" on TiddlyWiki, which trips me up constantly. There's other syntax awkwardness like sensitivity to spacing and newlines. Journals sort in alphabetical, not chronological order.
<https://classic.tiddlywiki.com/>
iirc browsers used to allow direct filesystem access.
They never did, if anything it's the opposite in that I think there are now APIs that can make this possible.
With TiddlyWiki you had to essentially File -> Save As and save the HTML back over itself. There were other ways too but they were all workarounds to the issue that browsers don't allow direct access.
They did back around 2008. I used Wiki on a stick - see https://stickwiki.sourceforge.net/which was kind of neat) but after a few years, Chrome etc stopped letting it save itself.