has reached the end-of-life and is now read-only. Please see the EOL announcement for details

My secret projects is complete enough to share! I present Feather Wiki, a tiny, self-contained app that exports into a single HTML file:

Think TiddlyWiki but as small as possible!

Literally the only inspiration for me even starting this project was seeing that a blank TiddlyWiki was >2MB in size

I just remembered a couple things I wanted to change before I announced Feather Wiki... oh well, at least it's easy enough to update to a new version ''>_>

Just pushed up a sneaky version 1.0.1 patch to fix the HTML title issue that @mmu_man let me know about plus some minor changes to the editor that I prefer over what I had before!

Shoutout to my favorite JavaScript framework, , the 4KB framework that makes a tiny app like possible: 🚂

I went ahead and released Feather Wiki version 1.1.0 just now, which includes custom CSS, page sorting, and messaging for browsers that can't run it:


@acousticmirror @Alamantus now, in addition to being able to use it by just saving a copy and opening it in your browser, recycle some of the same principles and make it possible to build from the repo by opening/running the build scripts in the browser (i.e. no NodeJS installation required).

Related: <>

@Alamantus happy to help with this—provide guidance, field questions, etc.

Eliminating NodeJS from build requirements is what I consider one of the things most deserving attention when it comes to contemporary development (Web and otherwise), esp. when the resulting project itself is not something you're expected to run in Node. Consequently, I've already put a bunch of work (and other forms of focus/energy) into this.

Aside from that, I'm interested in for myself. Good job!

@colby Thanks! I'm glad you like Feather Wiki!

As for building in the browser or without Node, I'm not sure I fully grasp the concept. How would I do that and still accomplish the minification that's done using binary files that are fetched from NPM? Specifically, I'm using esbuild and the next version will add Google Closure Compiler to shave off another couple kilobytes.

I'm sure I'm missing something here because it would be great to not need to install a separate tool like Node and still be able to do everything, but then again Node has so much utility that I'm not completely convinced it’s bad to have as a requirement? From another perspective, I'd love to be able to use Python tools without having to deal with installing Python, but it's a Python app so that's that.

I'm rambling now, but I'm kind of curious how this might be doable in a way that's not ultimately more inconvenient after everything is already set up the old way.

@colby Also, I already include the builds as downloads so I'm not sure if the benefit of building from the repo anyway?

@colby Ok so I read the thread you posted a little more closely and I think I understand the purpose better, plus I woke up realizing one of the computers I use isn't set up to build and I wished I could use it to build and release the new version anyway... So I see the benefit now haha

But the issue of binaries remains. Would I simply need to ditch what I'm using and find ways that use pure JS that can run in the browser instead? Or would I need to set up a small server as a compiler or something?

@Alamantus just to clarify: re "How would I do that and still accomplish the minification that's done using binary files that are fetched from NPM"—are you talking about the fact that esbuild is written Go, or some other thing where "binary files" somehow make their way into the end product?

@colby Not that binary files are included in the final product, but that they're an essential part of creating the build. Plus they require file system access to function, which browsers don't have. For example even though esbuild has a web assembly build, the actual Build method requires file system access. Same goes for Google Closure Compiler, which is a Java app that delivers OS binaries if you don't want to use Java.

I tried playing with the esbuild-wasm build yesterday, using HTML input with the webkitdirectory attribute and couldn't make any headway with it because it couldn't figure out how to deal with import and export without the file system. And that's before even trying to figure out what I could possibly do with Closure Compiler in the browser, whose JavaScript version was deprecated some 6 years ago and removed from the main project entirely.

Maybe for other projects I'll look into a web builder, but I'm fairly certain at this point that it's not right for Feather Wiki.

@Alamantus I get it. Mainstream practices involving development for the browser coming from the NodeJS angle have (unfortunately) produced toolchains that are simultaneously overengineered and underengineered (e.g. unable to handle this).

Good place to point out, though, the risk of mistaking incidentals for requirements. The requirement is "build $X" (where $X is whatever). That at any given point this involves various packages/tools—those are incidental.

@Alamantus quick pulse check/thought experiment: suppose you built Feather Wiki without the optimization (minification) pass, so building just produced a "full-fat" version. How hefty would that be?

By my accounting, on the order of 64KB, right? → 47555 bytes of current JS, plus CSS, plus whatever your JS doesn't do but that Feather Wiki needs to be able to do.

@colby Building with all the minification turned off produces a maximum size of 135KB and a minimum of 123.5KB which isn't the worst possible outcome, but it's unacceptable compared to releases already out...

Plus I still have the problem of everything being an ECMAScript module with imports and exports that a drag and drop won't be able to handle because the relative paths get destroyed. I've never really worked with <script> tags with the `type="module"` attribute before, so I also don't know how to make them work together.

You seem to know something I don't though, so I really do want you to keep trying to convince me if you're willing! I just currently don't see how to make it work.

@Alamantus re "Building with all the minification turned off produces a maximum size of 135KB and a minimum of 123.5KB": is that a result of incidentals or requirements?


@colby that's with The code for Feather Wiki itself and the 3 libraries it uses: Choo, the framework that Feather Wiki is built on top of that I'd prefer not to rebuild if I can avoid it, the Pell WYSIWYG editor, and the Snarkdown Markdown parser. Nothing else.

Granted, Choo and the other libraries are intended to be minified, but I don't have a great way to use the package manager and the bundler to only minify certain dependencies and not others. Maybe I could just download the minified distributions of them and add them as scripts to the HTML output, but then I can't really tree shake or modify them down to only the bits I use.

@Alamantus re "I still have the problem of everything being an ECMAScript module with imports and exports that a drag and drop won't be able to handle because the relative paths get destroyed"

Suppose you took the "exploded" dependency tree and flattened all modules into the same namespace. How many name collisions would you end up with, given the current code (what you've written + all dependencies)?

@colby I'm not sure how to do that, but it does get me realizing that most of the dependencies in the node_modules folder right now are just from the build tools and debugger... The actual script files are in separate folders, which results in a handful of `index.js` files as a result...

I have an idea I might be able to try when I have some more time this evening. Let me see if this works...

@robbie (@Alamantus) I just meant as a litmus test. Imagine taking all the modules that make up the codebase, erasing the import and export statements, and then concatenating them into one big file. This will lead to name collisions, of course.* But how many actual name collisions?

*probably—i.e., you can generally expect there there will be >=1, but it's entirely possible that the real answer is "none", depending on the codebase, which actually hints at my angle

@Alamantus hmm the TITLE tag is a bit vague for a bookmark…

@mmu_man what, "Feather Wiki"? But there's a "description" meta tag too! 😁 It's true I didn't put much time into getting all the metadata I could have into the HTML file, but I was excited and wanted to share as soon as it was mostly usable 😅

@Alamantus no, the title tag only says "About", so putting a bookmark on that…

@mmu_man ohhhhh that's a bug worth fixing. Oops haha. It sets the title to just the name of the current page, which I didn't account for when setting a custom home page. Thanks for saying something!

@Alamantus wow this is amazing!!! I accidentally downloaded it on my Android phone and it worked there too! Not just for desktop!

@vera That's awesome! It doesn't work well on my iPhone because iOS hates letting you deal with files, but it's great to hear it works for Android! 😄

@vera 🎉 The real test will be hitting that "Save Wiki" button with some content set and see if 1) it lets you save the new HTML file and 2) loads that HTML file with the content you created! If that works, then it's exactly what I hoped :)

@Alamantus W00t! I'm so happy you made this! Somebody had to. I'm a big fan of TiddlyWiki Classic, but the 5.x line badly suffers from Second System Syndrome.

Just one quick complaint for now: my 2017-vintage smartphone chokes trying to open the FeatherWiki homepage. (My newer tablet doesn't have a problem.) That's odd because even a large TiddlyWiki loads fine.

@felix I would definitely believe that—the JavaScript it utilizes doesn't really take older browsers into consideration. I'll have to double-check what ECMA features I'm using and make a note of that somewhere or at least add some kind of content for when the app can't load.

Thanks for the heads-up!

@Alamantus Speaking of JS, could you please add a message in a noscript tag or something, so visitors using Lynx for example know what's going on? Thanks! Custom CSS would also be nice.

@felix Your first comment did get me thinking about a noscript tag, so I'll see what I can do without bumping the size up too much. Also custom CSS is an idea I was already considering adding in a future version! In the meantime. It *is* possible to add <style> tags to the HTML of individual pages as something of a workaround, but I do understand that's not enough :)

@Alamantus No no, if that's an option, anything fancier can wait. And I was thinking a "please enable JS" message, not a static copy of the wiki.

My phone is running Android 5.1.1 if that helps.

@felix Yeah, I can confirm after looking through a summary of what features were added when, I'm heavily utilizing JavaScript features that were only added to the ECMAScript standard in 2020, so your 2017 phone wouldn't know what to do with it. Sorry about that! I'll definitely try to figure out some way to communicate this when browsers fail to run the JS!

@Alamantus So you could just … use this instead of a static website generator, if you were more interested in publishing text than being pretty? Er, wow. :)

@andy_twosticks Pretty much! I have a few kinks to work out regarding browsers that don't have some up-to-date features, but essentially yes!

Plus a future version may also allow custom styling with CSS so someone determined enough could make it as pretty as they wished!

@Alamantus That is *really* useful. Much as I loved Tiddlywiki, it was never going to look like a web page.

@Alamantus Is the "save wiki and download" mechanism the way Feather Wiki got around not being able to access the local file system? I had been a TiddlyWiki user for a while, but I stopped when saving became problematic due to browser security changes, and I hadn't followed development since.

@cstanhope Yeah, that's how it attempts to get around it at least! I haven't tested with all browsers, but the ones I have tested have been able to open and save & download without trouble! I wouldn't be surprised if some browser security issues caused problems in the future though... if it does cause problems, I'll just have to make a little desktop application shell for it or something!

@Alamantus Hopefully that won't be a problem. I like the approach. It's simple (from UX side) and works within the constraints. :)

@Alamantus Oh, good! Still not working on my phone, but the message helps. And with custom CSS, now I can fix all the stuff broken by CSS reset, such as blockquotes.

@felix Yeah, dropping the ECMAScript version to 2018 was the best I could do. It jumps by at least 1.5KB when I do any lower, and that was a little too much on top of the additional features.

And yeah, that's a perfect use for the custom CSS!

Shame it doesn't seem to work on the Jelly mobile browser, but I guess that's the new JS stuff...

@DHeadshot Most likely... I've never heard of Jelly browser, but if it doesn't support features from up to ECMAScript 2018, then it won't load, unfortunately. Transpiling the code to any lower version causes a jump in file size by up to 1.5KB (and more the lower it goes), and that was just a little too much. As it goes, doing the most recent features would have spared another kilobyte or so, but 2018 was the most comfortable middle ground I could offer.

Sign in to participate in the conversation

the mastodon instance at is retired

see the end-of-life plan for details: