I still like to implement my own ideas, especially in fun languages like Erlang and Perl. I’m glad I can program, because personal programming in the small is fertile ground and tremendously useful. For starters, this entire site is generated by 269 lines of commented Perl, including the archives and the atom feed (and those 269 lines also include some HTML templates). Why? Because it was pleasant and easy, and I don’t have to fight with the formatting and configuration issues of other software. Writing concise to-the-purpose solutions is a primary reason for programming in the twenty-first century.
my own blog’s been a shitty static site generator forever. I also happen to comaintain a build tool where I eventually refactored a DAG for partial rebuilds and used its compiler plugins interface to turn my shitty site generator into a compiler hook and now I get a shitty static site generator that does minimal rebuilds with full dependency analysis across templates.
There was a post about switching static site generators earlier this last month. Rather than rehash why I use Wordpress after having used static site generators, I’ll simple link to the discussion. :) https://lobste.rs/s/byh0mf/migrating_my_blog_zola
I have recently migrated from Hugo to Zola, but gods yes, I want ASCIIDoc support there. Maybe Eclipse Foundation will standardise the ASCIIDoc enough that there will be more implementations and it will became more popular format than it is nowadays.
The main problem with ASCIIDoc is that there is only one popular implementation (AsciiDoctor) which is in Ruby and there is no spec (yet) so writing alternative implementations is at least hard. Hopefully Eclipse Foundation will manage to provide EBNF/spec for the ASCIIDoc and maybe that will help with alternative implementations. I tried implementing ASCIIDoc in Erlang, but lack of formal spec made it troublesome. Also ASCIIDoc still has some problems of ambiguity in few places (macros and definition lists), it would be nice to see that cleaned up, so it would make implementations much simpler.
I agree with all of what you said, and am also hopeful that a spec helps the situation.
Aside: There is a javascript machine translated version of the ruby asciidoctor implementation (asciidoctor.js). I have used it successfully via asciidoctor-browser-extension, to view local asciidoc files as rendered. It is pretty handy!
The “problem” is that it is still Ruby implementation, just translated with Opal. There is no non-Ruby implementation of ASCIIDoc in common use. We need such implementations
Hobby code for hobbies is fine. Where I work someone pushed through their own version of this to production. I asked them why they didn’t use a static site generator and they said it wasn’t possible with no additional explanation. Then they went to deploy it and it was a disaster but content administration team had already gotten pulled into rewriting everything as markdown so it was going to be a embarrassment if it failed. People stepped into help. This ended up with each node having needing a half dozen manual deploys of flask apps for every update since the original person didn’t consider the production aspects of their site generator. Then more work was done to fix the painful deploy. Later that person with the site generator left the project.
Their vision was flask apps in docker containers deployed to kubernetes with helm. During the first 2020 presidential debate I redid the whole thing in mkdocs. Two hours later it was static files that could go anywhere. Want a template from the rest of the site? no problem, want code highlighting, no problem, want put yaml in their .md and have a custom template render that part, no problem, search? plugin + single config line, no problem, site map? single config line, no problem. Many of the existing SSG are concise to-the-purpose solutions.
I mean, just like with most jobs there are people who are bad at it. You don’t necessarily avoid <field-of-endeavor> projects* just because someone did a crap job of it, you fire them if they continually produce crap, or get them some training, or have them work on something more suited to their skillset.
I also wouldn’t consider a flask app running in k8s to be a “static site generator” by any means! Yikes!
*: Assuming they are qualified in the first place - nuclear, medical, cryptography, etc.
Interestingly, horror stories of less-bespoke software constructs such as frameworks are usually painted as a fault of the user, rather than the approach.
Software reuse at the largest scope possible is the prevailing orthodoxy still.
Yeah, there are varying degrees of InventedHere, NotInventedHere, and a lot of YourHoldingItWrong out there!
I guess much like the old adage of never getting fired for buying IBM, you aren’t likely to get fired (or heckled by colleagues) for picking popular framework du jour.
But we shouldn’t forget that along with the benefits (time savings, shared effort, etc), there are usually downsides to yielding control of your feature-set to the whims of a third party – features you may not need or desire, and if your needs happen to diverge far enough from the framework orthodoxy, then good luck to you!
I’m a bit more “for libraries” I guess, and a bit “framework skeptical” (caveat: I don’t work in the frontend/GUI/UI space, which may influence my leanings)
I also surveyed the static site generator ecosystem a few years back and found them kind of, I don’t know, tasteless? Faddy? Limited but promising unlimitedness? Requiring horribly bloated dependencies? Relying on templates?
So I wrote my own site in Common Lisp. The static elements are in Lisp itself, the blog elements are in Markdown directories that get rendered into html.
I just implemented my own Shitty Static Site Generator in Dart. The backend services share the same library (written in dart) with the web/android clients, so I did not want to bring alien tech. It took me 1 day to implement:
saving markdown files from POST requests
rendering them back in GET requests
showing listing of files (stories in markdown format) at /catalog/
showing different version of the story at /catalog/<story_id>/
showing rendered markdown for the given story + its version: /catalog/<story_id>/
At first I wanted to add some ‘mature’ SSG but it would be an overkill.
The solution cannot handle edge cases, but be opened for hacking but it is running in docker so who cares?
Similar sentiment from https://prog21.dadgum.com/56.html:
my own blog’s been a shitty static site generator forever. I also happen to comaintain a build tool where I eventually refactored a DAG for partial rebuilds and used its compiler plugins interface to turn my shitty site generator into a compiler hook and now I get a shitty static site generator that does minimal rebuilds with full dependency analysis across templates.
is the source available? is the build tool rebar3?
Yes and yes: https://github.com/ferd/blog3r
I’d still need to re add the demo structure (as a template for rebar3) to make it complete if anyone is interested.
I’ve added templates and such.
There was a post about switching static site generators earlier this last month. Rather than rehash why I use Wordpress after having used static site generators, I’ll simple link to the discussion. :) https://lobste.rs/s/byh0mf/migrating_my_blog_zola
I have recently migrated from Hugo to Zola, but gods yes, I want ASCIIDoc support there. Maybe Eclipse Foundation will standardise the ASCIIDoc enough that there will be more implementations and it will became more popular format than it is nowadays.
I have a similar hope. I really wish Zola supported asciidoc too!
I vastly prefer asciidoc everywhere I can!
EDIT: Just ran across this list of SSG’s with asciidoc support. Seems potentially useful.
The main problem with ASCIIDoc is that there is only one popular implementation (AsciiDoctor) which is in Ruby and there is no spec (yet) so writing alternative implementations is at least hard. Hopefully Eclipse Foundation will manage to provide EBNF/spec for the ASCIIDoc and maybe that will help with alternative implementations. I tried implementing ASCIIDoc in Erlang, but lack of formal spec made it troublesome. Also ASCIIDoc still has some problems of ambiguity in few places (macros and definition lists), it would be nice to see that cleaned up, so it would make implementations much simpler.
I agree with all of what you said, and am also hopeful that a spec helps the situation.
Aside: There is a javascript machine translated version of the ruby asciidoctor implementation (asciidoctor.js). I have used it successfully via asciidoctor-browser-extension, to view local asciidoc files as rendered. It is pretty handy!
The “problem” is that it is still Ruby implementation, just translated with Opal. There is no non-Ruby implementation of ASCIIDoc in common use. We need such implementations
Hobby code for hobbies is fine. Where I work someone pushed through their own version of this to production. I asked them why they didn’t use a static site generator and they said it wasn’t possible with no additional explanation. Then they went to deploy it and it was a disaster but content administration team had already gotten pulled into rewriting everything as markdown so it was going to be a embarrassment if it failed. People stepped into help. This ended up with each node having needing a half dozen manual deploys of flask apps for every update since the original person didn’t consider the production aspects of their site generator. Then more work was done to fix the painful deploy. Later that person with the site generator left the project.
Their vision was flask apps in docker containers deployed to kubernetes with helm. During the first 2020 presidential debate I redid the whole thing in mkdocs. Two hours later it was static files that could go anywhere. Want a template from the rest of the site? no problem, want code highlighting, no problem, want put yaml in their .md and have a custom template render that part, no problem, search? plugin + single config line, no problem, site map? single config line, no problem. Many of the existing SSG are concise to-the-purpose solutions.
I mean, just like with most jobs there are people who are bad at it. You don’t necessarily avoid
<field-of-endeavor>projects* just because someone did a crap job of it, you fire them if they continually produce crap, or get them some training, or have them work on something more suited to their skillset.I also wouldn’t consider a flask app running in k8s to be a “static site generator” by any means! Yikes!
*: Assuming they are qualified in the first place - nuclear, medical, cryptography, etc.
Interestingly, horror stories of less-bespoke software constructs such as frameworks are usually painted as a fault of the user, rather than the approach.
Software reuse at the largest scope possible is the prevailing orthodoxy still.
Yeah, there are varying degrees of InventedHere, NotInventedHere, and a lot of YourHoldingItWrong out there!
I guess much like the old adage of never getting fired for buying IBM, you aren’t likely to get fired (or heckled by colleagues) for picking popular framework du jour.
But we shouldn’t forget that along with the benefits (time savings, shared effort, etc), there are usually downsides to yielding control of your feature-set to the whims of a third party – features you may not need or desire, and if your needs happen to diverge far enough from the framework orthodoxy, then good luck to you!
I’m a bit more “for libraries” I guess, and a bit “framework skeptical” (caveat: I don’t work in the frontend/GUI/UI space, which may influence my leanings)
I also surveyed the static site generator ecosystem a few years back and found them kind of, I don’t know, tasteless? Faddy? Limited but promising unlimitedness? Requiring horribly bloated dependencies? Relying on templates?
So I wrote my own site in Common Lisp. The static elements are in Lisp itself, the blog elements are in Markdown directories that get rendered into html.
I’ve done the same for similar reasons. Most of all it’s really just fun. I definitely see it as more of a personal, “intimate” kind of project.
For those who love Python, here is a similar one in Python: https://github.com/sunainapai/makesite
Disclosure: My wife created this project and I have been using a modified version of it for my own website.
I just implemented my own Shitty Static Site Generator in Dart. The backend services share the same library (written in dart) with the web/android clients, so I did not want to bring alien tech. It took me 1 day to implement:
At first I wanted to add some ‘mature’ SSG but it would be an overkill.
The solution cannot handle edge cases, but be opened for hacking but it is running in docker so who cares?