Shell script eh ... OK - that'll work ...
And now you want to adjust your style and have it apply it to all your existing page. Another shell script? That'll work, though you're on your way in recreating a static site generator.
I think the moral of the story here is that if you're going to be advocating for HTML over a SSG, then perhaps it would make sense to invest a bit of time on a styleguide page, or take a bit more effort to leverage default styles (in the style of http://motherfuckingwebsite.com/), or just commit to inline styles to lock down the individualistic look of each page (if that's what they want). Being wishy-washy about style management over time is not going to age well.
There's Blogit shell script https://pedantic.software/git/blogit as well as many others, no reason to write your own.
The arguments are fairly weak, notably:
1. Using a static site generator, you have to keep track of the source code and the build (which the author suggests is more “source code”)
Nope. I could look at the dozen or so static sites sitting on my hard drive — I’ve kept none of the build directories. I simply git push the source and Netlify takes care of managing everything else.
2. > Let's say you want your site to have a specific directory structure, where pages are sorted under various categories. With Jekyll, this is practically impossible
Again, I don’t agree that this is even an issue, but there’s also nothing stopping you from using whatever directory structure you want. I don’t use Jekyll much, but that’s the thing about SSG: you can use the one that’s as simple or as complicated as you’d like!
You could even generate your site with a simple bash script:
for p in in/*.html; do cat common/header.html in/$p common/footer.html > out/$p; done
As you can see there’s very little stopping you from preserving whatever structure you want.
In fact, the author even suggests this! >If you find the previous step too much work, write a shell script that copies the directory and removes the old content for you.
Okay, so if you already have a script that copies content, you basically have a very bad manual SSG that doesn’t keep everything in sync.
I don’t really think any of this is easier than just spending the afternoon figuring out a basic SSG.
You're suggesting an SSG, Git, Netlify, and shell scripts. Is this really easier than HTML files on a server? I can do everything with HTML files, and if I need templating I can just use PHP.
Netlify is easier than HTML files on a server. Basically no effort to host a static site, even one that is generated.
An SSG such as Jekyll, Hugo, Gridsome is potentially easier than HTML files because it uses abstractions to avoid repetitive, error prone HTML such as your lists of posts, previous next, sitemap, etc etc etc. And writing articles in Markdown is so much nicer than HTML.
Git is easier than not using Git, whether or not you use an SSG.
Shell scripts were offered as a poor mans SSG, so lets ignore them.
SSG can be annoying when the templating sucks. I found Hugo annoying in this regard, Jekyll is fine, Gridsome is great, at least on par with PHP when you step outside the box. I think an SSG oriented framework is going to reduce how much templating/scripting you have to write massively.
Hosting on your own server, setting up IPs, SSL, Nginx, some kind of deploy script (sftp or whatever) are not particularly hard but with Netlify it's all handled so easily.
Theres no contest here
Your solution requires researching a bunch of SSGs, deploying and configuring them, and setting up a version control system (which you don't need for a low-stakes personal blog).
My solution is a text file on a web server, using HTML (which I already know) instead of a pseudo-format with a gazillion implementations.
that's external dependencies. I guess that's a nogo for the author.
The author's thoughts about layers of indirection are confusing to me, I'd actually take the comparison the other way. If I'm not using markdown plus a static site generator now I have to keep track of things like layout, styling, script tags, etc myself plus the actual writing I was intending on doing.
I used to have an extremely simple markdown server. It presented 2 types of page, an index and an article. The index simply read the /content directory on the server. Requesting any file under /content would render the markdown into the article page and affix a date and time from the .md file's metadata.
Takes <1 hour setup and means you never have to copy and paste random files or do whole site page transformations (as the author has admitted to in that very post) to clean your mishmash HTML beast.
Otherwise we'd all be making sites in Microsoft Word given its ubiquity! :D
However, Microsoft Word generates extremely bad HTML. Don't use it.
what happened to it?
At this point I don't write about much, so I haven't revived it.
Then compound this problem with something like a blog where you have hundreds of pages who all need to have their menus updated every time you post something, and yeah...pure HTML is just unacceptable.
The original assumption from TBL was there would be much richer tooling to allow everyone to compose HTML without knowing tags, but for various reasons that's not the direction Andreesen et al took Netscape. And third-party tooling (like SiteMill) end up focusing on developers and evolved into things like DreamWeaver.
Hence the mess we're in today: the world's greatest publishing platform, and it's near-impossible for non-technical users to start publishing directly to it as conceived. Good news for Wordpress and CMS vendors, but a road sadly not taken in so many other aspects
I'm not saying it's bad to design a website in plain HTML, but it is critically limiting, and I wouldn't recommend it over a simple generator setup. If you're really opposed to using a fully-featured SSG, it'd be pretty simple to write a shell script that uses mustache(5)  to plug html articles into a template. That's almost as simple and clean as plain html, but it's a real step up when it comes to what it lets you do.
What we have is, essentially, a blog post that could be written in pure HTML, and a link to the user's profile, which looks like this: https://ashley-richmond.medium.com/ This is one of the most popular blogging platforms and follows exactly the hub-and-spoke navigation model that I described.
Now, I do what to clarify, what I proposed is how I would build a website using plain HTML. I would certainly not go so far as to claim that it is the best way to build any website, SSG's have many advantages, but what I'm saying is that if one is going to write a plain HTML website, the easiest way is to accept the fundamental limitations of that approach, including a hub-and-spoke navigation vs a navbar. If you're writing a plain HTML site, you're probably a bit iconoclastic and willing to accept breaking some standard practices.
I find myself coming back to a metaphor that was in the comments here yesterday - yes, this is a beautiful, stylistic self portrait, but if your job is to paint the whole house this is a terrible way to do it.
I'd say for a simple web blog managing its entries by means of html files on the server is a valid solution. I am not sure how the author maintains an index of his blog entries this way, but updating an HTML index page manually does not seem like a huge effort to me.
Copy and pasting bits of HTML around was a chore and was prone to error.
No decent source control (the source control at the time was garbage and tbh was a relatively new concept in web dev) meant that you had no idea what you had done previously or why. I remember have lots of zip files with dates and README.txt in there.
No package managers meant that I had to keep track manually of scripts and CSS in folders.
Nah I don't think I will be going back to that madness thanks.
People have no idea how this simple thing cost so much money in so many companies. The time we spend shoe-horning stuff into stubborn frameworks someone senior, architect, or powerful in general like without having used it is sometimes more than half the budget clients pay for a solution.
And it's not just HTML. It's using Mule for API connection (70% of our time spent fixing Mule, swearing at it or hacking it), using Grails for Java servers (this was horrible and already happened to me twice, I could convince the CEO and bypass the leads to rewrite it in a language we all understood the first time, but the second time the company had to close due to endless productivity sinkholes and 200 employees turn around in 1 year...BECAUSE no one understood what the hell was being done), it's using custom made code generators to consume field lists in very complex models which everyone forgot the workings of 10 years later and new guys spend most of their time for months just hacking the generator to add very low value changes, and the list goes on.
Adding level of indirections to solve simple problems in an evolving system is now something I try to avoid. I even have to fight "geniuses" by telling them that we need to do the dumbest possible solution first and see what we need, rather than one more crazy framework solving a problem we may never have. And I don't always win...
I draft my articles in plain text or in a WYSIWYG editor, without markup. After I'm satisfied with the content, I go and manually wrap the text in the appropriate markup tags. This includes both inline tags such as <strong>, <code>, <var>, <abbr>, as well as block tags such as <h2>, <p>, <ul>, <li>, <table>, etc.
The major reason I use HTML is because I want to use the full palette of HTML features. I don't want to figure out how to use <dl>/<dt>/<dd>/<thead>/<th> and nested lists in Markdown for example. And if I needed to use attributes like <span lang="ja" class="animate">, then any syntax other than HTML offers no simplification anyhow.
Literally only using either Notepad++/FileZilla on desktop or an iOS FTP text editor combined with iOS Shortcuts if on mobile to generate and apply new posts.
For Notepad++ I saved macros for different post formats, the macro pulls the URL from my clipboard and wraps it in the HTML according to which shortcut key.
The iOS workflow does the same thing and lives as a cluster of app icons that trigger custom iOS Shortcuts in a folder on my Home screen, I just tap it, it pops-up an iOS input modal asking for the post title, then automatically wraps the HTML around both the text I input as well as the URL I already copied onto my clipboard, then takes the entire HTML chunk and overwrites my clipboard with it so I can paste into the index.html via the iOS FTP text editor.
In both cases it’s simple and fast, on iOS the FTP editor is always editing the live file, on desktop I just download the latest using FileZilla prior to doing any edit/upload. When on desktop I also (when not in a hurry) commit the latest version to a git repo.
(For larger and less commonly used updates, like formatted sections or special link highlights, I just have a templates.html file that I copy from as needed.)
So far, the ability to change the formatting and add custom edits without having to do any real development or deploying anything has been higher value and lower barrier of entry so I’ve yet to find the need and I can update the site in seconds.
The only real motivation to automate is for some things like the publishing date and Bitcoin/gold/silver prices at the time, but so far I still have just been editing it manually, and sometimes neglecting to update entirely if I’m in a hurry to just add a breaking headline.
I hadn’t thought of the take away but to me that’s what it should be if I were to highlight one, let the productive outcome vs. cost dictate the level of effort, which for web may naturally fall into somewhere on a spectrum between static HTML and cloud container deployments with automated testing and builds from CI deploying a dynamic data driven platform, depending on your needs.
Any non-trivial page written in only html will eventually evolve into a self-written static site generator, the author even suggests that by recommending shell script to automate html generation.
The real simple solution is to use a static site generator, however one could debate whether it is better to write it yourself or to use an existing one.
Is it really, though? HTML is a very deep toolbox, but to write blog articles you really only need a handful of tools on the surface level. If you were previously using markdown, all you need to do is review the basic syntax to figure out the equivalent HTML tags. Writing HTML is hardly any less pleasant, albeit a little more verbose, if you just stick to those tags.
I think primary value of languages like markdown is input sanitation. If a user makes a mistake in their markdown syntax, there's no risk of it breaking other elements on the page. But when you as the host are the only user, I say pure HTML is the way to go.
where markdown_py is your markdown-to-html tool of choice.
This will take the whole buffer and turn it into HTML;
Otherwise, just select what you want transformed in visual mode, press : and go use it like this:
Just felt the need to share - any command line utility can be used in VIM :)
(Emacs, VSCode and other editor-using people feel free to chime in, I'm sure there's lots of cool approaches to this)
It's a way of styling markup so that you don't have to manually enter P/BR tags.
Add ~30 lines of PHP to handle standard boilerplate (html, head, body, etc) and you can manage your website by uploading nearly pure text files to a remote folder. Or by authoring them via command line editor through SSH.
If you don't want any languages at all except HTML/JS/CSS, you might even use Server Side Includes.
And if you want to do this again, see the followup post they made more recently 6 months ago:
I had since went through (more than one) wiki, a custom Python server, m4 and make scripts and several SSGs. (My latest website uses Hugo.) Nowadays however I don't really care; as long as I can read that damn thing I can write anything I want. Do not pursue the perfect website solution; pick a working one, stick to it and don't look back. If it means a plain HTML, so be it.
If we're talking about "Developer Experience", it's cool: I can edit everything with ease in my IDE of choice. To be honest, what I'm missing most with these solutions is a Content Management part: the ability to add content to the website from a mobile device, for example, would be killer.
Now all I need is an awesome WYSIWYG HTML editor for mobile...
I still use Markdown for most of my blog posts. I just let GitHub build it for me. But I'm a fan of always thinking about the simple solution.
Old-fashioned HTML/CSS with minimal server-side scripting can do all of this stuff easier with fewer limitations. And you can have dynamic content.
- the ability to quickly change styling details on all of your pages
- a markdown engine, so that you can write posts more quickly and ergonomically
There are other nice features SSGs bring to the table (automatic RSS feed generation for instance) but those two features are the main things that stop me from writing directly in HTML. Especially the first one.
And just help a little bit with consistency in terms of keywords & navigation so as there can be a bit of structure in the chaos.
Maybe one could even go so far to add a xslt (html -> html) and amend that navigation etc. late in the browser.
There’s an opportunity cost to spending a bunch of up-front time setting up a bunch of crap you may never take full advantage of. You could be focusing on the content, finding an audience.
It’s helpful to zoom out and remember the timeless mantra: “You ain’t gonna need it.”
The problem is tech churn, versions are obsolete faster than you can download the packages and the whole ecosystem moves way to fast.
The solution is to choose simple and stable solutions. Build a shell script, use low-churn technologies, etc.
Blog post: don't use static site generators.
Top comment: take a look at my static site generator!