https://links.tiddlywiki.com/ is currently presented as an old school static site: clicking on a link navigates to a new URL, retrieving an entirely separate HTML page. The pages are all generated in advance, taking about 80MB. The same data is also presented as a 3.8MB TiddlyWiki HTML file.
It was built this way in order to be friendly for search engines but it has been demanding from a development perspective because it is significantly more complex than any other static TW site build I've built. For example, search has had to be redeveloped as a little custom JS app.
There are also some significant recent bugs (#24, #25, #26) that are all due to shortcomings with the current static site rendering framework.
At this point, I'd rather focus effort on the core link aggregation functionality than on fixing and extending the static site generation framework.
So, I propose to remove the static renderings from links.tiddlywiki.com, and build an equivalent user interface in TiddlyWiki.
https://links.tiddlywiki.com/ is currently presented as an old school static site: clicking on a link navigates to a new URL, retrieving an entirely separate HTML page. The pages are all generated in advance, taking about 80MB. The same data is also presented as a 3.8MB TiddlyWiki HTML file.
It was built this way in order to be friendly for search engines but it has been demanding from a development perspective because it is significantly more complex than any other static TW site build I've built. For example, search has had to be redeveloped as a little custom JS app.
There are also some significant recent bugs (#24, #25, #26) that are all due to shortcomings with the current static site rendering framework.
At this point, I'd rather focus effort on the core link aggregation functionality than on fixing and extending the static site generation framework.
So, I propose to remove the static renderings from links.tiddlywiki.com, and build an equivalent user interface in TiddlyWiki.