Dear gods, that it an awful amount of manual work for something that is stupidly simple to automate. I mean, don't get me wrong, it'd be nice to get back to minimalism, but ya should have some...
When I want to post something, I first write it in a text file, copy my last blog post’s HTML file, paste in my new article, make some slight adjustments, update my list of posts, add it to my RSS file, and that’s basically it.
Dear gods, that it an awful amount of manual work for something that is stupidly simple to automate.
I mean, don't get me wrong, it'd be nice to get back to minimalism, but ya should have some formatting in the document, and such. I mean my cms system could probably be scaled back a little, but even it just keeps site layout separate from content, so I can swap styling and page layout, without touching all of the content (Which is just markdown).
You could automate all that using Emacs or another scriptable editor/platform. But since static site generators exist, it's probably not worth the effort.
You could automate all that using Emacs or another scriptable editor/platform.
But since static site generators exist, it's probably not worth the effort.
Not having to write HTML code for pages. The site layout is generally managed by CSS. The rendering just takes markdown and turns it into html for me. You can see it in action at https...
Not having to write HTML code for pages.
The site layout is generally managed by CSS. The rendering just takes markdown and turns it into html for me.
You can see it in action at https ://thunix.net/~ubergeek
The code is here: https ://tildegit.org/ubergeek/wiki.php
It's really not much, but it works well for what I need it to do: Allow me to write content, and not worry much about the rest.
You could still maintain a simple CSS file and have your Markdown convert to HTML when time comes, FYI. They needn't be the same process. I might be misunderstanding the problem here.
You could still maintain a simple CSS file and have your Markdown convert to HTML when time comes, FYI. They needn't be the same process.
Politely, I don't think user's site exactly has the legacy I'd expect it to have. Yeah, HTML-only surely feels liberating. But, considering that all the content on the site is under a month old, I...
Politely, I don't think user's site exactly has the legacy I'd expect it to have.
Yeah, HTML-only surely feels liberating. But, considering that all the content on the site is under a month old, I can say with confidence that they haven't yet found the major issues with their workflow—stuff you only learn from months of living on your workflow.
For instance, consider the following: How many of you traveled to other pages on their site? I'm pretty confident that not many did. There are no links on the page, not even to go up a level or go back home. So you had to manually edit the URL in your browser.
Here's where a static site generator or CMS matters. When they realize that it's a terrible experience to trundle along their site, it's only just updating one template file to add even some sort of navigation/structure on the site. Continuing with an HTML-only trajectory will put them in a situation they'll have to update ~10 pages now—more, as the site grows.
Let's see where their workflow is in a year, and how often the content is updated and maintained. If there are hundreds of pages of content, well, maybe they've got a point. But right now the site is too new for there to give any significance to their perspective.
An odd conclusion when the main thrust of the article is against using the esoteric incantations of other static site generators.
You may find it unnecessarily manual, but I’ve come to realize that if I’m not willing to perform these few steps, then what I have to post may not be worthy in the first place
An odd conclusion when the main thrust of the article is against using the esoteric incantations of other static site generators.
Right? The author claims to want to focus on writing without distraction, and then burdens themselves with the distraction of having to manage HTML. It's clear that the author prefers a different...
Right? The author claims to want to focus on writing without distraction, and then burdens themselves with the distraction of having to manage HTML. It's clear that the author prefers a different kind and level of technological distraction than static site generators. I have deeper objections to this piece that I'll be putting in a top-level comment, but I wanted to highlight this particular bit.
I'd rather write all of my web things manually. I'd also rather not stick my preferences into someone else's face as if it's providence from God. The only benefit derived from sharing tastes is...
I'd rather write all of my web things manually.
I'd also rather not stick my preferences into someone else's face as if it's providence from God.
The only benefit derived from sharing tastes is opening the other person up to possibilities. Acting as if those possiblities are inherently better by default is bad faith.
I may be a nose-to-the-grindwheel motherfucker, but that doesn't mean others want to be.
I wrote my site in static HTML for a long time. It sucked. Generation is way better. With hand-edited documents, you will forget to update something, pages will get out of sync, maintaining...
I wrote my site in static HTML for a long time.
It sucked. Generation is way better. With hand-edited documents, you will forget to update something, pages will get out of sync, maintaining something like a tag list becomes inconceivably laborious.
Even with my… extremely low output, using a static generator has saved me loads of time and made my site more consistent. If it's the messing around with HTML you miss, write your own template—I found it very straightforward in Pelican.
Another tech writer, another "you should do things the way I do them because it's objectively better" post. I have very little patience for articles like this. They are scant on fact-based...
Another tech writer, another "you should do things the way I do them because it's objectively better" post. I have very little patience for articles like this. They are scant on fact-based arguments and rely heavily on opinion presented as facts, often with contradictions.
The big contradiction for me here is that the author doesn't want the distraction of static site generators but does want the distraction of having to wrangle HTML and CSS manually. We each have a different level and kind of distraction or effort that we're comfortable investing in a task before we say "that's too much, man!". For me, touching anything to do with the frontend is too much. I hate working with HTML, CSS, JS, any of it. But I'm completely happy to write some code in whatever language I'm happy with at the time (and in the past have used Makefiles because that's exactly what they were made for).
I will also point out that the styling on the author's site is rather minimal, which is rather different than the theming used by static site generators. This is an orthogonal choice to the plain HTML approach. I think that this is actually what the author wanted, a minimal design rather than just static HTML. The article mentions struggling with theming, and the result is a minimally-themed blog. And this is fine, but it should be stated outright that that's what the author wanted. It's absolutely possible to do that with a static site generator, but it needs more work, so I think this is where the frustration came from.
I also hate the type of article that you're describing, but I came out of this with the complete opposite feeling. I can't pick out a single argument from this article that's framed as an...
Exemplary
Another tech writer, another "you should do things the way I do them because it's objectively better" post. I have very little patience for articles like this. They are scant on fact-based arguments and rely heavily on opinion presented as facts, often with contradictions.
I also hate the type of article that you're describing, but I came out of this with the complete opposite feeling. I can't pick out a single argument from this article that's framed as an objective truth. The author is simply describing their personal experience with these tools and offering up a solution for others who have had similar problems.
I think my reaction may be colored by the post title, which definitely does read that way to me. That pushed me to read the article in a different light. Upon rereading, I don't see arguments...
I think my reaction may be colored by the post title, which definitely does read that way to me. That pushed me to read the article in a different light. Upon rereading, I don't see arguments addressed directly at the audience, but that title... woof. I realize it was written that way to grab attention, so I think, ultimately, my issue is with clickbaity headlines. Who knew? :)
The author strikes me as the sort of person who spends more time tweaking his mod list in Skyrim than actually playing the game. By which I mean no offense, that's a perfectly fine way to get...
The author strikes me as the sort of person who spends more time tweaking his mod list in Skyrim than actually playing the game. By which I mean no offense, that's a perfectly fine way to get enjoyment from something. But it seems like he's blaming tool configuration for distracting him from blogging, rather than using the tools to blog more efficiently. I've spent a lot of time configuring CMS and static site generators, I can relate.
There is an art to implementing any software plan expediently and knowing when to call it "done." LIke @cptcobalt pointed out, publishing two "blog posts" does not indicate a successful workflow. If it were my site I'd likely be burned out by the tenth. Writing the posts themselves shouldn't be too painful, but manually writing the links to them and maintaining the RSS feed will be.
Aside: It's probably worth pointing out that an article document with zero hyperlinks is user-hostile. Even by the web 1.0 standards that inspire "brutalist web design," that's poor UX. The RSS feed is also non-discoverable. A site doesn't need bloated gimmicks, but there are basic accommodations we should all try to make as a baseline when publishing for the web.
Dear gods, that it an awful amount of manual work for something that is stupidly simple to automate.
I mean, don't get me wrong, it'd be nice to get back to minimalism, but ya should have some formatting in the document, and such. I mean my cms system could probably be scaled back a little, but even it just keeps site layout separate from content, so I can swap styling and page layout, without touching all of the content (Which is just markdown).
You could automate all that using Emacs or another scriptable editor/platform.
But since static site generators exist, it's probably not worth the effort.
Probably. And not with much difficulty, either.
What do you need that couldn't be accomplished by maintaining a simple CSS file?
Not having to write HTML code for pages.
The site layout is generally managed by CSS. The rendering just takes markdown and turns it into html for me.
You can see it in action at https ://thunix.net/~ubergeek
The code is here: https ://tildegit.org/ubergeek/wiki.php
It's really not much, but it works well for what I need it to do: Allow me to write content, and not worry much about the rest.
You could still maintain a simple CSS file and have your Markdown convert to HTML when time comes, FYI. They needn't be the same process.
I might be misunderstanding the problem here.
I think so... The "cms" I used pretty much works exactly as you described here.
Politely, I don't think user's site exactly has the legacy I'd expect it to have.
Yeah, HTML-only surely feels liberating. But, considering that all the content on the site is under a month old, I can say with confidence that they haven't yet found the major issues with their workflow—stuff you only learn from months of living on your workflow.
For instance, consider the following: How many of you traveled to other pages on their site? I'm pretty confident that not many did. There are no links on the page, not even to go up a level or go back home. So you had to manually edit the URL in your browser.
Here's where a static site generator or CMS matters. When they realize that it's a terrible experience to trundle along their site, it's only just updating one template file to add even some sort of navigation/structure on the site. Continuing with an HTML-only trajectory will put them in a situation they'll have to update ~10 pages now—more, as the site grows.
Let's see where their workflow is in a year, and how often the content is updated and maintained. If there are hundreds of pages of content, well, maybe they've got a point. But right now the site is too new for there to give any significance to their perspective.
An odd conclusion when the main thrust of the article is against using the esoteric incantations of other static site generators.
Right? The author claims to want to focus on writing without distraction, and then burdens themselves with the distraction of having to manage HTML. It's clear that the author prefers a different kind and level of technological distraction than static site generators. I have deeper objections to this piece that I'll be putting in a top-level comment, but I wanted to highlight this particular bit.
I'd rather write all of my web things manually.
I'd also rather not stick my preferences into someone else's face as if it's providence from God.
The only benefit derived from sharing tastes is opening the other person up to possibilities. Acting as if those possiblities are inherently better by default is bad faith.
I may be a nose-to-the-grindwheel motherfucker, but that doesn't mean others want to be.
I wrote my site in static HTML for a long time.
It sucked. Generation is way better. With hand-edited documents, you will forget to update something, pages will get out of sync, maintaining something like a tag list becomes inconceivably laborious.
Even with my… extremely low output, using a static generator has saved me loads of time and made my site more consistent. If it's the messing around with HTML you miss, write your own template—I found it very straightforward in Pelican.
Another tech writer, another "you should do things the way I do them because it's objectively better" post. I have very little patience for articles like this. They are scant on fact-based arguments and rely heavily on opinion presented as facts, often with contradictions.
The big contradiction for me here is that the author doesn't want the distraction of static site generators but does want the distraction of having to wrangle HTML and CSS manually. We each have a different level and kind of distraction or effort that we're comfortable investing in a task before we say "that's too much, man!". For me, touching anything to do with the frontend is too much. I hate working with HTML, CSS, JS, any of it. But I'm completely happy to write some code in whatever language I'm happy with at the time (and in the past have used Makefiles because that's exactly what they were made for).
I will also point out that the styling on the author's site is rather minimal, which is rather different than the theming used by static site generators. This is an orthogonal choice to the plain HTML approach. I think that this is actually what the author wanted, a minimal design rather than just static HTML. The article mentions struggling with theming, and the result is a minimally-themed blog. And this is fine, but it should be stated outright that that's what the author wanted. It's absolutely possible to do that with a static site generator, but it needs more work, so I think this is where the frustration came from.
I also hate the type of article that you're describing, but I came out of this with the complete opposite feeling. I can't pick out a single argument from this article that's framed as an objective truth. The author is simply describing their personal experience with these tools and offering up a solution for others who have had similar problems.
I think my reaction may be colored by the post title, which definitely does read that way to me. That pushed me to read the article in a different light. Upon rereading, I don't see arguments addressed directly at the audience, but that title... woof. I realize it was written that way to grab attention, so I think, ultimately, my issue is with clickbaity headlines. Who knew? :)
The author strikes me as the sort of person who spends more time tweaking his mod list in Skyrim than actually playing the game. By which I mean no offense, that's a perfectly fine way to get enjoyment from something. But it seems like he's blaming tool configuration for distracting him from blogging, rather than using the tools to blog more efficiently. I've spent a lot of time configuring CMS and static site generators, I can relate.
There is an art to implementing any software plan expediently and knowing when to call it "done." LIke @cptcobalt pointed out, publishing two "blog posts" does not indicate a successful workflow. If it were my site I'd likely be burned out by the tenth. Writing the posts themselves shouldn't be too painful, but manually writing the links to them and maintaining the RSS feed will be.
Aside: It's probably worth pointing out that an article document with zero hyperlinks is user-hostile. Even by the web 1.0 standards that inspire "brutalist web design," that's poor UX. The RSS feed is also non-discoverable. A site doesn't need bloated gimmicks, but there are basic accommodations we should all try to make as a baseline when publishing for the web.
I really consider write my blog (doesn't exist yet) in HTML. no markdown, no org-mode (original plan),