Nice, I wouldn't have thought that simple approach "download/overwrite" of self-modifying page served via file:/// protocol would be this viable and, after all, even intuitive.
For similar purpose (not-so-important semi-ephemeral notes and doodles) I usually (ab)use dataURI documents with "#hash" part and rely on browsers' history/bookmarks persistence, so both "editor engine" and "data" remains in URL and does not need to leave the browser.
Example: simple "HTML sandbox" with live preview under 1kb [1].
(Hypothetically they could be even synced to browser profiles, but. Also there presumably is a size limit for URI (or perhaps bookmarks database) but I haven't ran into it yet.)
Most probably not advisable for larger apps (even tiny feather wiki) but for it's super small purposes it has a nice advantage of "un-hosted" application/data can be passed around with clipboard. (Naturally, the "engine" works from a file as well [2], but the persistence remans in the "#hash" nevertheless.)
Similar to your interest. I've been experimenting with Data URIs and base64 encoded html pages. I could manage around 400kb in url, beyond which it wouldn't load in chrome and firefox.
A plugin for Feather Wiki to export to itty bitty would be awesome. I've personally did some experiments. I'll share the finding to the Feather Wiki author to give him an idea and also add an issue for a plug in request, so some hackers can work on it...
I've created an issue at itty bitty github some time ago so that wikis like tiddly wikis and feather wiki could be fully compatible:
My personal Tiddlywiki instance is 5300kb so nearly half of it is content now. This is why I don’t care much about its size. At least saving 300kb for Feather would not be worth any effort.
It's inspired by TiddlyWiki, but it's not nearly as feature-packed by design. Literally the only reason I even started this project was because I noticed how big an empty TiddlyWiki 5 file was and thought I could make one that was smaller. :)
I'm actively working on a way to extend individual wikis, which will hopefully pave the way for more features through hacking it.
I once made a very crude and simple TiddlyWiki work-alike I called "HulloWurld" https://github.com/calroc/HulloWurld It's 143 KB, but it includes copies of Knockout, Underscore, Zepto, and the "Marked" markdown parser... ¯\_(ツ)_/¯
For me, the planned "Feather Wiki Nest" tool is the most interesting, as an internet-accessible, editable, organised set of notes is a killer-app.
I currently use Noteself (tiddlywiki + local / remote database saving function) for this, and it's an excellent solution that I'd be loathe to migrate away from. The main issue is having to setup and host a CouchDB instance, but once it works it works well. If 'Feather Wiki Nest' has a lower barrier to entry than Noteself, then I could see it being very popular.
Whilst I use Noteself for personal notes and life organisation, I may use Featherwiki as a blog platform, just to keep a thicker separation between the two (I've previously considered using Noteself for blog content to then publish as static HTML).
Pro tip: For the present you could use widdly https://gitlab.com/opennota/widdly with tiddlywiki for the db saving which is a damn simple set up. You could use caddy as reverse proxy when hosting on a VPS. On my home system I have a custom widdly and a full bells and whistles TiddlyWiki. I use it also on a server to share ideas with my partner who also has an instance.
Feather Wiki Nest is the thing I am looking forward too. It would be a single application, start it and forget it, your wiki just works. That's immense awesomeness!
I see you're laving a lot of room for much heavier versions, like the "chicken", "eagle", "stork", and "emu." Smart. Who knows how big the future client-side tech stack will get.
I'm not the author. This is a new project and these versions are there so that the core could be minimum at the same time have versions with more features. As the project grows, I'm sure there will be only one variant or options for features could be specified during build time. For now, see it as pre alpha and the variants as a form of A/B testing to strike a balance between minimum size, essential features and good to have features. Bit tricky to balance. Invite you to hack and help balance - need more people there.
But be careful because it seems very easy to lose data. At least in my testing, if you create a new page but don't save and close the tab then you lose all data without any warnings. Similarly, if you are in the middle of adding content to a page and close the tab then it is gone without any confirmation box. A built-in browser confirmation box when closing tab/window should be relatively easy to add in I think.
This is very true. I added a warning when switching pages within the app itself when the editor is open, but it would definitely be worth the extra bytes to add a warning when closing the tab!
Seems like an excellent way to lose data and the best kind, thoughts typed.
Tiddlywiki will prevent a page close, this does not and will lose the entire wiki. Feather warns on not saving individual pages, but saving in this context means so little, this should just be part of the ephemeral internal state. No saving required. Save to disk is the only permanent storage and Feather doesn't have any guardrails here.
I don't do browsers, but can locally loaded file set cookies and/or use browser storage? I shouldn't ever have to consciously think about saving a file, let alone an entire wiki in 2022.
I must say I am mildly amused that the author went to the effort to specify six SKUs based on size when the largest is only 10% larger than the smallest. And this approaches 0% as you add content to your wiki. But I always love seeing some blazing-fast web pages!
I think the creator(s) should just simplify to the one full download. It'll make support and releases easier, and I genuinely can't see any reason why someone would download the other releases: https://feather.wiki/?page=downloads
Here, I'll simplify the options:
- All features, transpiled
- All features, not transpiled
- No Markdown, transpiled
- No Markdown, not transpiled
- No WYSIWYG, transpiled
- No WYSIWYG, not transpiled
And the difference in gzipped size from the largest to the smallest size is... 2KB.
I thought so, too, but maybe the author got a bit carried away with the bird analogies and needed a reason to add more bird photos (which is totally understandable).
Exactly this. I wanted to see how small I could get it (Hummingbird) and then got obsessed with the idea of bird names for the build versions and just had fun with it :)
The goal is making it smaller and smaller at the same time improving usability. It will never be like TiddlyWiki, it sort of complements TiddlyWiki. This project is very new. So I think there will be lot of improvement. Any willing hackers here can check this out and contribute code: https://codeberg.org/Alamantus/FeatherWiki and help make it smaller, faster, better
Stunning. It looks straightforward, and it is an improvement over a PDF in almost all cases. I'm wondering if there are other specific features that may be eventually added. For wikis intended to not have much content, this is a delightful tool.
Looks pretty cool, I love lightweight stuff! I am curious, what does the word "quine" mean in this context? I always thought quines were just programs which output their own source code. I suppose that's technically true in this case, but only if you view the source, and under that logic couldn't you say all static websites with 100% client-side javascript are quines?
In this context: Saves both content and the web application itself as and output html.
The wiki/app is the html file itself. If you add / remove content, you get another html file that contains the wiki app and the added / modified content.
No need for complicated applications, compatible wherever a browser runs (All OS), always compatible cos html (the raw html is human readable). No proprietary format lock in.
Quine Relay - A Ruby Program that generates Rust program that generates Scala program that generates ...(through 128 languages in total)... REXX program that generates the original Ruby code again. https://github.com/mame/quine-relay
It refers to the fact that if you hit "save" it'll first modify its own code, then spit it out again as a download. So it does output its own code, and not in the sense of just having viewable code.
So it’s a bit scary that I could press edit and appear to be able to edit the Feather Wiki landing page? Would it have required auth if I tried to save changes? If not can you put basic http auth in front? I suppose the idea is to just use it locally and then publish any resultant http page and/or updates/edits to a static host?
When you press save once, the changes are applied in your browser. When you press the save button on the top your browser is triggered to let you save the edited HTML to your computer.
Afaict, the edit and save is local and not sent to the server. So to persist changes and make them visible to others you’d need to then upload the edited HTML file to the server, using for example scp or sftp, or whatever method is used for deploying changes.
So for example you could put this in a git repo and have GitHub or Cloudflare Pages host it, and after you make an edit to a page from the browser you’d put the edited HTML file for the page in the git repo, commit that and push it to GitHub or whatever.
Not sure about Feather, but you can give TiddlyWiki a GitHub personal access token (saved in localstorage) to have the save button do a git commit automatically.
Actually I discovered it by chance as I was looking for a tiddly wiki alternative that can display on my Jail broken Kindle - it didn't work cos the browser is crippled - but loved it and started writing to the author on his repo via issues. Somebody changed that title for me. Didn't know that on HN people can edit other peoples titles...
I'd like to syntax highlight code blocks. I tried to add PrismJS to the html file. The CSS survives, but my <script> tag seems to disappear no matter where I put it. I guess this is because Feather Wiki is rewriting itself. How can I add a <script> tag that survives?
The Choo framework is set up to replace the <body> with its render, but any <script> on the page when it's loaded should run—it just won't appear in the inspector after Choo renders.
EDIT: Unless you're talking about it surviving after saving the wiki, in which case it won't remain. I'm actively working on support for extending Feather Wiki that allows whatever custom JavaScript you want, in a very similar way to how the custom CSS is preserved. But it's not ready yet. Keep an eye out for version 1.3.0 in the near future!
FYI there's experimental support for Feather Wiki on https://tiddlyhost.com/ . If you click "Show advanced settings" when creating a site you can find Feather Wiki in the drop down list.
It could be used as a note app like Obsidian, Roam Research etc. with some caveats: it's hard to use on mobile and you have to take care of the sync process yourself using Dropbox, OneDrive, GoogleDrive.
So I would like to see these additions: synchronization and a mobile app.
You can also pay for Obsidian Sync, which is more or less required if you're mixing Apple and non-Apple devices, as there's no proper support for OneDrive or alike on iOS, but also no proper support for iCloud on Windows/Android.
yes this is a must, as much as I like the solution, if it doesn't support good mobile and sync , then it's not good enough for my usecase.
Currently use one note for windows, it's pretty fast compared to the old one note and mobile's support is great.
I'm getting close to finishing the extension/plugin functionality for Feather Wiki, and I was able to successfully write a search extension using Fuse.js! The plugin will be included on the website when the new version with the extension support is ready :)
Unfortunately with respect to Feather Wiki, fuse.min.js is too large (23KB) :) But the fuzzy search is a good idea. If you find a very tiny js search lib, please post it here on HN or here: https://codeberg.org/Alamantus/FeatherWiki/issues
I did note your ":)", and I agree that compared to a total of 63kb, a 23kb addition can be quite large, but search is too important a feature, and I think it will be worthwhile.
I'm impressed. A serverless/internetless wiki.
How would upgrading the "engine" work though? e.g implementing a search or adding code highlighting in the the wiki.
I'm currently working on a way to extend the code by revealing the underlying [Choo](https://choo.io) framework to enable easier hacking! Search is one feature that theoretically won't be too hard to add, but I excluded it from the core because it would have made it too big.
Note: I have no solid reference point for what "too big" actually means for this project—my only guideline so far has been "as small as possible"
I absolutely love this app concept! It's probably not the most efficient in terms of computation overhead but it is definitely practical and absolutely wonderful in terms of compatibility! Web browsers are the operating system of the 21st centry after all!
For similar purpose (not-so-important semi-ephemeral notes and doodles) I usually (ab)use dataURI documents with "#hash" part and rely on browsers' history/bookmarks persistence, so both "editor engine" and "data" remains in URL and does not need to leave the browser.
Example: simple "HTML sandbox" with live preview under 1kb [1].
(Hypothetically they could be even synced to browser profiles, but. Also there presumably is a size limit for URI (or perhaps bookmarks database) but I haven't ran into it yet.)
Most probably not advisable for larger apps (even tiny feather wiki) but for it's super small purposes it has a nice advantage of "un-hosted" application/data can be passed around with clipboard. (Naturally, the "engine" works from a file as well [2], but the persistence remans in the "#hash" nevertheless.)
[1] https://gist.github.com/myfonj/c8ce74bf549e19600026ce9022388... [2] http://myfonj.github.io/sandbox.html