18 comments

[ 2.5 ms ] story [ 37.2 ms ] thread
I do this with CLOG, save-lisp-and-die
From one of these user's most recent posts here https://j3s.sh/thought/blogs-rot-wikis-wait.html:

  p.s. i'm working on a new wiki to replace my website with - something new, from the ground up.

  git.j3s.sh/abyss - stay tuned

I wonder if they'll still be using a similar approach for the new site.
I'm not seeing the point here, TBH. What use-case does this author's single-binary satisfy?

1. You just want to serve static files from your blog? Install a webserver and knock yourself out in your editor, creating html and css (and maybe js) files.

2. You want to serve static files, with some dynamic crap stuffed inside here and there like the examples given in the article? Install the mod_php or equivalent for your webserver, and go mad with the editor.

3. You want fully generated content? Install one of the many backend frameworks in any language you want to use, and then go mad in your IDE.

What use-case does "one binary I wrote in Go" satisfy that isn't covered above? From everything I gleaned from the article, the PHP solution is even easier, while still technically being "one single binary".

EDIT: as an example of over-engineering, here is the authors code for a specific use-case:

    func ipHandler(w http.ResponseWriter, r *http.Request) {
     w.Header().Set("Content-Type", "text/plain")
     fmt.Fprintf(w, r.Header.Get("X-Forwarded-For")+"\n")
    }
    ...
    http.HandleFunc("/ip", ipHandler)
And here is the equivalent in PHP:

    header('Content-Type: text/plain');
    echo $_SERVER['REMOTE_ADDR'];
The author also says they want to be able to understand all of the components of the system. Software that needs upgrades that may not be backwards compatible is an issue. I imagine many web servers can fall under either of these concerns, including Apache and Nginx.

I'm not a fan of Go myself, but I can see how a simple Go HTTP server fits the bill.

(comment deleted)
Anytime I see someone writing without any capital letters, I stop and close the page. I understood that they care more about themselves (the writer) than the reader, so I let them write without my reading, as they signaled they don't care about it. Respectable.
This is actually a great post. Love the idea of single binary and low dependencies to keep things as lean as possible.
Pleasantly surprised how jovial this post was. Thanks!
I was using Python's Pelican static site generator for some time until I wanted to further customize the template fragments of a theme. Started running into issues and even helped fix a bug with the build command. Eventually I couldn't be bothered and wrote my own static site, except with Nextjs instead of plain HTML. Didn't take long and I don't have to mess around with awkward jinja templates anymore.
Yes hugo+template+isso (my Giorgi.com setup) has some hidden dependencies but you can get a fancy site in very little time. A dynamic web site is exciting to design, but require a lot of effort… I suggest to use Python Django: it has a tutorial for a blog!
I like the idea, but I don't like that the result is not accessible. For example, there are no headlines, lists, or paragraphs—just a huge pre, or if you remove the 'thoughtbody' class from the p element, you can see how well a screen reader can read it.

I also have extensive experience with static sites, starting from using just Apache Directory Listing (Footer, Header, SSI), to writing my own in Perl, Ruby on Rails, Go, and TypeScript, using frameworks like Astro, Next, or Zola. Apart from the Apache setup and some Perl scripts, all of them had one thing in common: I used Markdown because it is easy to transform into HTML, which means it is accessible.

It's true, static sites are low energy.
Rather than a compiled blob generated from a language propped up by Google (a company famed for killing beloved projects) that is compiled and therefore unmodifiable and unrecoverable if the source or toolchain is lost, it feels like these goals would have been better served by writing it as some POSIX-compatible sh scripts, or even a (pre-packaged/no-build) JavaScript bundle — we've been trying to kill that thing for decades, and it's still kicking!