Tiddlywiki (Node.js) on iphone?

I am migrating from single HTML files to Node.js stored on Dropbox.

Reason: A single TW5.HTML file grew too big and became slow. Creating multiple smaller HTML files wastes time searching which file a tiddler is in. I did consider Mohammed’s $:/plugins/kookma/searchwikis solution, but prefer to not need to update the searchindexes.

Duplicate tiddler titles get the wiki’s name manually prepended to the tiddler title.

I wish there were an easy to avoid an accidental tiddler overwrite. Importing behavior (sometimes) notifies me and appends a “1” to the title, but not when I import to Node.js (not sure why).

Access to Node.js from laptop

On my laptop ,(13" MacBook Pro, MacOS Monteray 12.1), and in terminal ,(Hyper 3.1.4), I load the Node.js wiki with the command:

tiddlywiki /Users/jwh/Dropbox/TW5/Node --server 19671

In my browser ,(Firefox 96.0.3), I access the wiki with:

http://localhost:19671

How do I access the Node.js wiki from my iphone ,(iphone 8+, IOS 15.2.1),?

I don’t think Quine2 can access Node.js - correct?

1 Like

Note that the servercommand is deprecated in favour of the listen command (https://tiddlywiki.com/#ListenCommand)

An equivelent command would be this:
tiddlywiki /Users/jwh/Dropbox/TW5/Node --listen port=19671

But that still won’t open the wiki up to other devices on your network. To do that you will need to tell the server to listen on other addresses not just the local one. Your final command will be

tiddlywiki /Users/jwh/Dropbox/TW5/Node --listen port=19671 host=0.0.0.0

Note, this will only work inside your network.

2 Likes

From the browser perspective a wiki served from nodejs is absolutely the same thing as a single file wiki. So if your single file wiki is slow in the browser that won’t change if you use nodejs as a backend.

The only difference is, that if you save a tiddler with a nodejs backend, that tiddler will be saved as a single file on the server. … So saving a tiddler will be faster. … but that’s it.

But doesn’t the node.js version allow lazy loading? Does that not make the TW quicker?

2 Likes

It does allow lazy loading but you have to specifically enable it, https://tiddlywiki.com/#LazyLoading

Lazy Loading is interesting. It skips including the text field of all NON-System tiddlers from packaging it into the HTML file that is generated and loaded by the browser. But, the first time a text field it doesn’t have is referenced or changed, it re-downloads ALL non-system tiddlers at once.

Not exactly how you’d think that’d work…

It doesn’t seem to be working that way for me. I base this on empty searches for known key words. But it’s hard to tell. Questions:

  1. How are you detecting that text fields are being downloaded?
  2. Any possibility you’re using the Relink plugin?

So @pmario, what is the advantage of running TW under node.js over the classic single file option?

IMO there is no “advantage” or “disadvantage”. There are different usecases. It depends on the user, what is important. It can vary from wiki to wiki.

The single file wiki has an advantage, because it is 1 self-contained file. It’s the simplicity of handling 1 file that makes this usecase appealing.

The client server wiki has single tiddler files on the server instead of 1 big HTML file. So every file can be easily accessed with other “editors” if needed.

On the other hand a client server configuration has a lot more moving parts, wich increases complexity quite a bit.

As Mat points out, it supports “lazy loading”, where the client only gets the title of the tiddler and all fields except the text field. Only if the tiddlers are “shown” or the text field is requested by filters, those text fields will be loaded on demand. This can have an advantage, if the text fields are big.

I do not need lazy loading so I cannot tell much about it. IMO @linonetwo has a big wiki which uses it. So he should be able to explain the pros and cons much better.

hope that helps
-mario

1 Like

NodeJS wiki will double the startup time, because many startup process like building index will run once on nodejs, and once on the browser you open the wiki. And mobile phone will kill your process after a while, it need to recalculate when you open it again. So I don’t want to run nodejs on mobile, which will consume too much battery.

So TidGi-Mobile use SQLite instead, so it save as fast as nodejs wiki, and only calculate once like HTML wiki. The drawback is it don’t have both HTML and tid file, it is just .db file. But you can sync it back to TidGi-Desktop (NodeJS wiki) to get .tid files.

I will release TidGi Mobile iOS once I done the google play release.

Hi @linonetwo manyver.se has a crossplattform implementation of node.js. It would be great to have a transplattform codebase for something like tiddlydesktop

One would think the node implementation being the key way to deliver tiddlywiki as a server, would be a motivation to use node, rather than single file. However it seems to me it is either

  • not easy or safe to put on then internet
  • to put it on the internet with a proxy etc… Is complex and not accessible to most tw users
  • it needs improved multi user features

I am not sure if the new Announcing the MultiWikiServer Plugin solves this as I understand it also uses node.

To me the lack of an accessible multi user internet facing tiddlywiki server is possibly tiddlywikis biggest gap.

Thank you everyone for giving me your feedback. From what I read and understand, I’ll be staying with the single file version for now.

bobj