Lychee-front VS exiftool-vendored.js

Oh, if I had read further into the README I would have seen this:

> https://github.com/LycheeOrg/Lychee#build

> Lychee is ready to use, right out of the box. If you want to contribute and edit CSS or JS files, you need to rebuild https://github.com/LycheeOrg/Lychee-front.

So their JavaScript source code is in a separate "Lychee-front" repository and they commit the build artifacts into the main "Lychee" repo. Not sure why they would do this.

Know that although ExifTool is written in perl, you can run it in "batch mode" which makes it quite fast--only a couple of ms to parse a file. I've written an open source library to manage the subprocesses for you if you're using node.js (and I also wrote the ruby variant ages ago):

https://github.com/photostructure/exiftool-vendored.js

The frontend is in Vue. Both the FE and BE are in TypeScript.

Parallelism is provided by https://github.com/photostructure/batch-cluster.js/

Metadata reads and writes are via https://github.com/photostructure/exiftool-vendored.js/

My more nerdier blog posts are tagged here: https://photostructure.com/tags/coding/

if you're looking into doing stuff with EXIF, there's a really good library that's also typed: https://github.com/photostructure/exiftool-vendored.js

I needed a good Node wrapper for ExifTool and wrote https://github.com/photostructure/exiftool-vendored.js

When I saw how slow it is to fork child processes in Windows, I then realized I wanted to run ExifTool in "stay-open" mode, which meant I needed to manage 1 or more long-lived child processes that communicate via stdin/stdout, so I wrote https://github.com/photostructure/batch-cluster.js

I also really missed scala's `lazy` operator, so I built that (and several other small, helpful functions/classes) that I documented here: https://photostructure.com/coding/uncertain-lazy-forgetful-a...