Comment by schemescape
4 years ago
I much prefer tools that run in a browser (both for convenience and for sand-boxing), but... I think a command line tool is better for a simple file system-based case like this, at least beyond an initial first impression.
My workflow is that I write my posts in VS Code, and then if I want to preview or upload, I just hop over to the console and type a command (no mouse needed). Deno's built-in sand boxing is the most convenient command line alternative to browser-based apps that I'm aware of.
Edit to add: I have toyed with the idea of integrating VS Code's Monaco editor into a "dev blog in your browser" type of app, but (the last time I checked) durable storage for web app data wasn't reliable (it was more intended to be a cache). Maybe things have changed.
There's the interactive use case while editing markdown where a UI is very nice, but there's also the use case of putting static site generation into an automated build and deployment process. Command line tools that respect standard command line conventions (exit nonzero meaning error, etc) offer an obvious pathway to automation. Often running a static site generator is but one of many steps in a repetitive process, and one part of usability is how easy it is to call the tool from a bash script or use it inside a rule in a makefile.
I can see you're offering self-contained prebuilt single-file binary releases. From my perspective those are a fine way to address the user request of "I want it to be easy to install without needing to first install and configure n other tools". That's one thing that I reckon hugo got right.
Out of curiosity I downloaded a linux binary md2blog release, and apart from needing to unzip and `chmod +x` it, it ran fine without dependencies -- i don't have any tooling related to deno or typescript installed locally.
Are you using `deno compile` [1] to build these self-contained release binaries?
[1] https://deno.land/manual/tools/compiler
Yes, md2blog's pre-built binaries are created using "deno compile".
> I think a command line tool is better
Why not both? It doesn't need to be mutually exclusive; write md2blog.html so it can run either from the command-line or be opened in the browser—whichever is preferable (easiest) at the time.
I don't understand your comment about durable storage. If you have a directory of Markdown files on your disk, that's already durable storage. I'm just talking about tweaking the development approach so the site generator's business logic can run using the browser process's JS runtime that's almost definitely already in memory. md2blog.html would be written to accept the same directory that the current incarnation reads; use ordinary file APIs—the input element or drag and drop. "Web app data" (I think you're talking about localStorage?) would only seem to come in after starting to expand the scope of the tool and is a separate matter.
The simple answer to "why not run this in a web page?" is that I built this tool based on my own needs and I never had any need to run a file system-based tool in my browser.
On the other hand, if I wanted to ship something similar with a built-in editing experience, then I think running it in the browser would be the way to go. The problem I saw there (last time I checked) was that I couldn't write directories of files to the file system from a web page (and I definitely want to store everything in the file system).
> The problem I saw there (last time I checked) was that I couldn't write directories of files to the file system
You mean to an arbitrary path—why would this be necessary? The only write operation that most static site generators make use of is putting exactly one file tree somewhere after processing the input. The same thing is achieved by the browser's native Save File handling. If it were running in the browser, you'd generate a ZIP containing that file tree.
2 replies →
Perhaps your use case is already supported in a different way, by downloading a single self-contained binary md2blog release, and then
> To build and test the site locally (with automatic reloading), run:
> md2blog --clean --serve
> And open a browser to the "localhost" URL that is written to the console. You can kill the server with Ctrl+C.
as described in https://jaredkrinke.github.io/md2blog/quick-start.html
How does that sound like it might be similar? I'm very confused how someone could think this is at all like what I described. To say "not even close" would be an understatement. It's the exact opposite in every way.
> Perhaps your use case is already supported in a different way
It wasn't a support request.