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).
@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 feather.wiki 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.
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.
@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
@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 😅
@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 :)
@bouncepaw That's one thing I don't know—I haven't done any stress testing on the app. But it *should* be able to handle just about anything your browser can handle, RAM-wise. I estimate that it just might make saving/loading take longer with very large files.
@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.
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.
@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. :)