@Alamantus And, what's more (looking at the "Features" page): it's a #quine!

https://alamantus.codeberg.page/FeatherWiki/?page=features

@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: <https://kosmos.social/@colby/107383954959125641>

@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.

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?

<https://news.ycombinator.com/item?id=25423730>

@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

@juliana Need something? :D

@Alamantus nah, you already gave it to me :3

@juliana 💖 Let me know if you find anything wrong with it!