[HN Gopher] Show HN: Md2blog - A zero-config static site generat...
___________________________________________________________________
Show HN: Md2blog - A zero-config static site generator for dev
blogs
Author : schemescape
Score : 36 points
Date : 2021-11-29 16:55 UTC (6 hours ago)
(HTM) web link (jaredkrinke.github.io)
(TXT) w3m dump (jaredkrinke.github.io)
| alphabet9000 wrote:
| the layout of the demo blog looks really nice, loads immediately,
| no bloat
| schemescape wrote:
| Yes, the bloat (e.g. Facebook/Twitter logos) associated with
| many themes for other static site generators was one of the
| aspects that drove me to create md2blog's templates from
| scratch, by hand.
| threatofrain wrote:
| Do you have plans for Latex by any chance?
| shoo wrote:
| I recently wrote a few documents in latex after ignoring it for
| over a decade. Trying to get a working setup with latex +
| bibtex + a few custom styles was quite annoying (and i work as
| a backend developer, so i probably tolerate annoying command
| line tools more than most people). I can appreciate that people
| (e.g. researchers) who just want to author a document with some
| equations in latex but who are not programmers or avid command
| line users might find the entire experience of getting a
| tolerable latex workflow set up very challenging. I guess that
| might be partly why https://www.overleaf.com/ has a business
| model! Hide all the package management and command line tooling
| nonsense behind a simple web interface.
|
| I was very excited to find Thomas Weise had wrangled latex and
| a Tex Live installation into a docker container:
| https://github.com/thomasWeise/docker-texlive-thin
|
| Another useful tool is latexmk, which is already installed
| inside the docker-texlive-thin container :
| https://mg.readthedocs.io/latexmk.html
|
| By containing the madness of latex tooling and package
| management with docker and some volume mounts, I could have a
| reasonably sane build process to manufacture PDFs from latex
| source files.
|
| I don't recommend md2blog add mandatory dependencies on
| anything related to latex. Another way to think about it might
| be offering optional latex support through some md2blog plugin
| mechanism that doesn't know anything about latex. But that path
| sure won't produce anything resembling a "zero config" static
| site generator! Might end up with something closer to apache
| httpd.
| schemescape wrote:
| Do you mean embedding Latex in a Markdown code block and having
| that render at build time (perhaps to SVG) that is embedded in
| (or linked from) HTML?
|
| If so, that might be something I could look into. Version 1 of
| md2blog actually did almost exactly that for Graphviz diagrams
| (but I removed that feature because, frankly, I didn't
| understand the Graphviz license). A quick look indicates that
| Latex also has its own unique license that is... quite lengthy.
| powersnail wrote:
| Mathjax has server-side rendering now, which could be used
| for this purpose.
| cxr wrote:
| It would be nice if as part of the zero config effort, programs
| (esp. programs that aim to be easy-to-use Web-authoring tools)
| would focus even more on being as close to zero setup/zero
| installation as possible, too. To wit:
|
| This program is written in TypeScript, a browser-incompatible
| dialect of JS that is nonetheless regularly compiled to standard
| JS, e.g. to transform a given module into a form that can run in
| the browser--and yet md2blog itself doesn't. You are expected to
| either download an out-of-band, platform-specific binary or use
| Deno to run it.
|
| Instead, one should be able to use md2blog and similar programs
| by using the browser itself to open and run the program,
| considering it's the universal platform that everyone already
| has, and it's reasonable to expect that you're going to use it at
| some point in the pipeline, anyway (e.g. for proofing your work).
|
| Even better quick start instructions would look something like
| this:
|
| 0. Start with a directory that contains the site sources that you
| intend to publish.
|
| 1. Save a copy of "md2blog.html" there, too (or anywhere,
| really).
|
| 2. Open the md2blog program in your browser by double clicking
| md2blog.html.
|
| 3. Drag and drop the directory with your Markdown sources (same
| one from steps 0 and 1) into the newly opened md2blog tab.
|
| (For good measure, a copy of these quick start instructions would
| be shown when you open md2blog.html.)
| schemescape wrote:
| 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.
| shoo wrote:
| 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
| schemescape wrote:
| Yes, md2blog's pre-built binaries are created using "deno
| compile".
| cxr wrote:
| > 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.
| shoo wrote:
| 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
| schemescape wrote:
| 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).
| cxr wrote:
| > 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.
| dvtrn wrote:
| Your instructions sound like the description for tiddlywiki.
| [deleted]
| philipwhiuk wrote:
| > Instead of fiddling with options and themes, your focus is
| strictly on writing and publishing content.
|
| > FAQ (e.g. themes, command line options, support)
|
| Just saying.
|
| In the long term I suspect Md2blog will evolve to be little
| different to Jekyll.
| Zababa wrote:
| The thing is that this cycle is important, because you can
| learn it when it's easy to learn and as it evolves. Jekyll has
| been very frustrating for me to learn because of all the
| accumulated cruft, even if it solves very real problems.
| Sometimes you just need to restart to get the new people on
| board.
| schemescape wrote:
| My solution to scope creep was to put the "generic static site
| generator" part in a separate library (modeled after
| Metalsmith), so that I can leave md2blog as _featureless_ as
| possible.
| 4kelly wrote:
| I definitely have spent too long learning and fiddling with
| SSG's.
|
| Going to give this a try!
| schemescape wrote:
| I'd greatly appreciate it if you let me know how it goes (even
| if you hate it).
|
| I built it for my own needs, but I'd like to know if anyone
| else finds it useful. Thanks!
| olaven wrote:
| This looks great! I actually made a very similar tool called
| Markblog[1]. We did a lot the same way (even using Deno!), but we
| did themes a little differently. I used custom CSS-files, but
| your approach is even simpler.
|
| Not to detract from Md2blog, I just want to add it to the
| converstaion for anyone interested in these things :) Keep up!
|
| [1]: https://github.com/olaven/markblog
| schemescape wrote:
| Thanks for sharing! Is there an example site built with
| Markblog? I didn't see a link in the readme.
|
| It certainly sounds very similar!
|
| Edit: Found this link on the Markblog docs: https://olaven.org/
|
| Edit again: I like that you appear to have an automated
| approach to deploying to GitHub Pages.
___________________________________________________________________
(page generated 2021-11-29 23:01 UTC)