What is the advantage of Node js. over html file?

Reposted from What makes me love Tiddlywiki - #9 by pkuadt

Pros :

  • If the wiki crash, get corrupted or stuck in a loop it’s easy to salvage the tiddlers.
  • For collaboration on GitHub for example, individual tiddlers avoid to build the entire wiki each time someone want to submit a change, and there is the benefit of versioning.
  • A node.js wiki take a lot less of space on the drive since the core is not needed.
  • Images dropped inside the wiki are automatically put in the wiki folder rather than embeded in the html file (edit: tiddlydesktop can do that, not the vanilla node.js tiddlywiki !)

E.g : I recently (a few hours ago actually) switched my main wiki to node.js. For reference, my single file wiki is 3.6 Mb, while my tiddlers folder is only 0.6Mb. True, as the wiki get bigger and bigger the size difference get smaller, but for someone that like to make a lots of backups (8 thousands files on my end…) it seriously adds up.

Cons :

  • Automated backup : it looks like I will need to setup my own backup method.
  • Since it requires a node.js server running, it might not be great on low performance computers.
  • Loading may be slower if there are a lot of tiddlers, unless maybe if lazy loading is enabled.
  • Cant be launched directly from the browser

Other than that, I’m pretty satisfied with my decision.

I made a very basic batch file to make it quicker to launch/create a tiddlywiki on node.js, hopefully it could be useful to someone else. Here’s the code :

@echo off
set /p name=Name of the new wiki:
echo %name% is being initialised and will open shortly..
call tiddlywiki "%name%" --init server
start http://127.0.0.1:8080
(for /f "tokens=* delims=:" %%L in ('findstr /b ::: "%~f0"') do echo %%L) >"%name%/start.bat"
:::start http://127.0.0.1:8080 & tiddlywiki --listen
(for /f "tokens=* delims=:" %%L in ('findstr /b :::: "%~f0"') do echo %%L) >"%name%/offline-copy.bat"
::::tiddlywiki --build index
call tiddlywiki "%name%" --listen

To use :

  • create a text file, copy/paste the above code, then save and change the extension to .bat.
  • If node.js is installed, double-clicking that file in a folder will open a command prompt asking for the name of the wiki to be created, then a folder will be created with that name and the wiki will launch in the default internet browser. I did not find how to automatically set the title of the wiki, creating the corresponding tiddler with the batch script didnt work (at best, the title is blank).
  • A batch file to start the wiki and another to create a single file backup of the wiki will be created inside the wiki’s folder, for later use.
  • You can then create a shortcut of this batch file and place it into “C:\ProgramData\Microsoft\Windows\Start Menu” to be able to pin the shortcut to the start menu, or put it anywhere else you like. It’s also possible to customize the icon of the shortcut, create a keyboard shortcut and schedule your wiki to be opened automatically on startup.

I know that it’s spaghetti code so if anyone want to share a better solution, please do !

It looks fine to me. :clap:

1 Like

Which OS do you use? You may know, that it should be easy to compress the backup folder, to save space.

On windows 10 / 11 it looks like this:

2 Likes

Thanks for reminding me of that possibility ! Does it really make a difference with .tid file though?

You mean if you’re using Saq’s upload plugin? It can’t do this out of the box, can it?

I’ve tried things various ways. Single-file always ends up being more useful.

With node each instance has to have its own port number. Each instance takes up space in memory, obviating any gains on the client side. Each instance has to be invoked separately, unlike Timimi where you can run any file any time.
On the local intranet, it is more likely to corrupt. It is complicated to deploy on mobile devices, and in my experience more likely to be shut down by the Android system to regain memory.

Some people like having individual tiddlers. That’s the primary advantage over other approaches.

If they are text it’s probably about 70% reduction or more. … From your post I thought you have 1000 single file wiki backups. … The reduction there would also be very significant, since the content is very similar between the different saves. eg: core and UI are always the same, it can be compressed very effectively

Oops, you’re right ! It’s tiddlywiki desktop that can do that out of the box, my apologies.

Oh wow, then yes it’s definitively worth enabling it !
I should have tested it myself … It reduced the size by 40% :smiley: