I have run both static and Wordpress sites in the past and Wordpress definitely has a better publishing experience for most writers than a static site. Whenever the experience of publishing static sites is criticized, I usually only hear scoffing from developers glancing up from their wall of terminals. “How could this be hard for anyone else?” But the fact of the matter is that for most people, it is. If static is superior, then it would be awesome to see developers making tools that make it easier for the average writer to publish a static site instead of being confused about someone “not getting Jekyll”. Make it easy to do it the right, secure way. My position right now makes me the interface between a lot of “average” users and complicated tools and especially now that we are working remotely, I am intensely interested in making processes easier (and still safe) for my users, even if I have to sacrifice technical purity. But when I can help them complete the task in the best way, easily, then that’s a big win.
The tools exist. You can add a content manager on top of a static generated site, like Netlify CMS or Forestry, just to cite two of them. They’re called headlessCMS and there’re a lot of them.
There’re others advantages on going static that @kev doesn’t talk on this post. For example, I think the most important for me is that you can pass the trouble and cost of maintaining a server with php, a database and a webserver running 24/7.
But at the end of the day I don’t think there’s only one right way to do things. I agree with @kev:
WordPress is far from perfect, but it works for me. If using a static site works for you, that’s great. It would be a very boring world if we all liked the same thing.
I’ve tried Netlify, and I wasn’t impressed. Compared to just unzipping a version of WordPress on an Apache server and setting up a MySQL database, it felt very counter-intuitive and complicated to use and setup and I didn’t even get it to work in the end. All these headless CMSs seem very ad-hoc.
I think the most important for me is that you can pass the trouble and cost of maintaining a server with php, a database and a webserver running 24/7.
As @kev mentioned elsewhere in this thread, you still need a web server running to serve static content, which almost certainly has PHP enabled anyway. The only difference is that you don’t need a database. And I admit that databases are somewhat opaque compared to how static site generators structure the content, but there’s a reason that most CMSs store their data in a SQL database rather than in plain text files.
(As a sidenote, I’m not a huge fan of CMSs either. I myself have a static site, I just don’t use a static site generator.)
You generally don’t host a static site on an actual web server; Netlify or GitHub/GitLab Pages or S3 or whatever is a layer of abstraction on top of that. I use Google Cloud Storage for https://snazz.xyz, so I build my site locally and have a script that copies the files to my GCS bucket.
For my site’s traffic usage, replicated hosting on multiple continents is free (and then I pay by the GB of bandwidth after the first 5GB). Plus, I don’t have to do any maintenance whatsoever.
I just can’t see how this is simpler than just having a web server running. And I feel much more in control running my own web server on a VPS than hosting my site in Amazon’s or Google’s cloud.
I understand the need for control but I think that one of the main benefits of running a static website is that there is almost no vendor lock-in. That’s why I feel confident about hosting my personal blog on Netlify. If the company goes out of business tomorrow, migrating to something else will take 10 minutes at most.
There’s still much more vendor lock-in than with a simple web server. A WordPress installation looks identical, no matter what VPS it is hosted on. Same goes for Apache. But Netlify’s “in-browser edit” interface is different than GitHub’s, which is different than GitLab’s, and so on. If you want to be truly free, you can never really allow yourself to get used to Netlify/GitHub/etc, because if you get used to any specific service, the barrier for leaving it will be higher.
It’s not a huge deal, but it’s a big enough deal for me to feel uncomfortable with it.
From my observations, people treat the web editor as last resort (among github users, its use for anything is strongly discouraged—in collaborative development context, for valid reasons).
The advantage people love those things for is pushbutton deploy: you push generated pages to git, and the rest happens without you. With Github Pages’ built-in Jekyll, you push source files/configs/templates to git and generation also happens without you.
Myself I’m not fond of autogenerated files in git, and rsync+ssh to my own web server is all deployment automation I want (I made it a make target), but for some it’s a real selling point.
From my observations, people treat the web editor as last resort (among github users, its use for anything is strongly discouraged—in collaborative development context, for valid reasons).
The reason I focus on the web editor is that lots of people in this thread are presenting it as a perfectly viable alternative to WordPress’ web editor, which I don’t really think it is.
The advantage people love those things for is pushbutton deploy: you push generated pages to git, and the rest happens without you. With Github Pages’ built-in Jekyll, you push source files/configs/templates to git and generation also happens without you.
I don’t know… I can’t see how this isn’t just another step in the process of updating the site that just makes it more complicated. Wouldn’t the most effortless solution just be a traditional shared web host with FTP access?
(Also, with GitHub + Jekyll, you still need to generate it on your own system to preview it, so I don’t see the benefit of any generation happening on GitHub, and don’t get me started on issues of version mismatch between GitHub’s Jekyll and my local installation…)
version mismatch between GitHub’s Jekyll and my local i
on Netlify you can specify the version of SSG you’re using. I use Hugo and I can it to the same version as my local one.
I think it’s just a tradeoff. Instead of managing SSH keys, apt unattended-upgrades, and Certbot, I just run this script on my computer every time I want to upgrade my site:
#!/bin/sh
cd ~/everything/site
rm -rf public
zola build && cd public
gsutil -m rsync -d -r . gs://www.snazz.xyz
gsutil -m rsync -d -r . gs://snazz.xyz
Maybe this is more complex overall, but the amount of stuff I have to keep in my head is much reduced this way. I can see why you might prefer to maintain control over the web host, but I’m perfectly happy not having to do any sysadmin tasks.
Instead of managing SSH keys, apt unattended-upgrades, and Certbot
None of these are strictly necessary. I have no need for a non-self-signed SSL certificate, so I don’t need to worry about renewing it.
Maybe this is more complex overall, but the amount of stuff I have to keep in my head is much reduced this way. I can see why you might prefer to maintain control over the web host, but I’m perfectly happy not having to do any sysadmin tasks.
I understand, I didn’t mean that managing a web server is zero-effort in any way.
10 years back, my friends over at TheConversation.com.au created a “live” static site generator.
The public site was nginx serving html files off disk, but there’s a full CMS with a database, versioning, etc generating those files when an article is updated.
This architecture had the significant advantage that it was really, really hard to cause a public facing outage.
Also, truly huge amounts of traffic could be handled by a single, quite small server, even before adding a CDN to the picture.
Yes, the ability for even a small server to handle enormous numbers of page views is a definite technical advantage of a static site. I just think the number of moving parts in an SSG end up nullifying the advantages in the eyes of the prospective publisher. Tools that couple the publishing interface (especially on mobile) of WordPress with the speed and small attack surface of a static site are definitely in order. @kev mentioned Grav as one such tool in some of his comments, although I haven’t had the chance to try it. But my experience with SSGs eventually drove me back to just writing straight HTML in a decent IDE.
I started blogging with UserLand Radio and later Movable Type. While primitive by today’s standards, this software attempted to bridge these worlds. The blogging experience was through a dynamic application and the publishing output was static HTML.
As time progressed, I would often output “SHTML” (server-side includes) or PHP with these tools. That way you include more complicated dynamic pages for contact forms, surveys, etc. without using CGI scripts.
I’m curious as to whether the authors of tools like Grav, etc. have any experience with these older tools? Once Wordpress appeared on the scene, everyone ran in that direction of the easy of publishing, but we’ve had a lot of pain with maintenance and security vulnerabilities. I’m considering building something dynamic for my personal site which combines link blogging and photography because I know I’m more likely to publish to it when I have time, which also happens to be when I’m on my phone.
I think the thing missing from this discussion is that a lot of writers have their preferred text editor. I hate environments where I’m expected to write a large amount of text in anything other than my favourite text editor. Most writers I have met have an editor that they like (and often have customised a lot, with off-the-shelf plugins and custom key bindings / macros, even if they’re not programmers). If they’re using WordPress, they’ll write in something else, then copy and paste. If their favourite editor has native Markdown support, then they’ll use that and then copy it, otherwise they’ll paste text and then faff getting the formatting right.
The thing that they usually want is a mechanism to push directly from their editor to a live preview and then to deployment. That’s generally easy to hook up with a static site generator driven from git and a scriptable editor (these days, that means anything that’s not Notepad), but for a lot of commercial sites it often ends up having a manual step involving someone emailing a word document.
I find the ‘I need to edit in a web browser’ argument pretty weak.
I run a static website. It’s repository is currently hosted on GitLab GitLab has a web interface to edit files. Changes are automatically tested and pushed to the public through CI. And best of all, as I use markdown I usually prefer to edit in Vim, but I can use a million other tools if I’d like.
I’m not too sure about this workflow on an iPad, but I’m sure it isn’t as bad as the article author states for a static website.
If he really wanted the pragmatic approach on iPad, he could’ve used Working Copy app, which allows you to edit your code and push it up to your Git repo. Then at this point he could have the setup that is described above, where it’s all automated.
does GitHub have CI pipelines? because you would need to create a CI pipeline to deploy changes from your repo to production in order for the web UI to be usable for this use case.
For a team blog I’m working on at the moment, I’m using GitHub’s GitHub Pages mechanisms to automatically deploy whatever is on the gh-pages branch of the blog’s repository. It’s free, it’s easy, and it works.
Yeah, it’s not as robust as GitLab’s but is fairly easy to set up. I was able to go from never using actions to having a commit trigger build and FTP everything over in about two hours [0] and most of that was figuring out sftp command line quirks between Mac, Ubuntu and my host.
I was able to teach a retired journalist to use this workflow (and Markdown) without much trouble. The website was simple, he had a lot of time on his hands, and he was eager to learn.
Agreed, compared to that workflow my argument in regards to using a web browser is weakened. I’ll edit the post to reflect that. Thanks for the feedback.
I think there is still an important point in that argument. The only alternatives that have been presented have been ad-hoc solutions like a headless CMS – yet another separate component that you need to setup – or GitHub/GitLab’s in-browser editing – yet another external service that you need to rely on. With an actual CMS like WordPress, you have a single consistent interface that you can totally own and control yourself.
I don’t think this is an easy option for everyone. You still have to know a thing or two about git, github/gitlab, and continuous integration. It might be easy for you, but it’s not easy for everyone. You wouldn’t need to learn an insane amount of stuff, but I imagine it’s still more work than using WordPress.
I find the name “static site generator” kind of subconsciously promotes the idea of this just being all about some static files that move from here to there. What they usually come with though is a super complicated, fragile, and regularly updating toolchain that puts at risk your ability to generate the static part that was supposed to be simple. We have a couple “static” sites that are almost impossible to update now because the tooling that generates them is no longer being maintained, so it’s harder and harder to run that tooling successfully. They don’t feel like “static” sites very much anymore.
If the generation code is exercised on very web page visit it’s likely to degrade much more slowly than if it’s only exercised when there’s new content.
You’re not the first person I’ve heard say that. I know a few people who spend an inordinate amount of time administering issues on their static sites.
Another reason, from the opposite point of view, is that static site generators are often an unnecessary burden. You can just write the HTML5 directly, very easily. Most tags do not need to be closed in modern html, and it is just as readable as markdown. No need to write your text in a slightly different language and then compile it.
To be honest, I find writing HTML for prose painful; it’s hard to write and hard to read, and there are a bunch of caveats you need to be careful about (like writing < as >). Writing stuff like <strong>bold</strong> or <code>quote me</code> just takes too much time when writing; I want to focus on actually writing content, not typing HTML tags. For me, the biggest advantage of Markdown is that it gets out of my way and allows me to focus on the actual content – which is already hard enough – instead of the syntax.
YMMV, and whatever works for you of course, but I think this is the added value for a lot of people.
Prose rarely has boldface or other fancy stuff. If you need to use it too much, then you are doing something wrong. That said, you can use the “i” and “b” tags which are shorter. The only thing that I find annoying when writing html prose is “p” the paragraph tags. I would prefer if a blank line started a paragraph. But I can live with those.
In the cases when you need some markup, html5 tables are actually easier than markdown tables, and lists and links are mostly equivalent.
Maybe prose is the wrong word (not native speaker 😅); I mostly mean stuff like articles (i.e. longer versions of comments on Lobsters) where various forms of formatting are fairly common. Common enough for me to be distracted by it, anyway.
I actually find tables to be one of the more ugly parts of HTML; so many tags, and often not that readable as source code.
Regarding tables, notice that with HTML5 you don’t need to close any table tags besides “table”. It’s actually cleaner than the many flavors of markdown tables.
How do you handle HTML that should be common to all pages, like the <head> section or the top nav? Do you copy it over to each new page’s source, or do you have some kind of preprocessor to keep it defined separately?
I saw a post (maybe on here) a while ago where the author said that they write their HTML by hand and they were asked how they manage these bits of common markup. Their response was that they explicitly do not make sure every page has the same header/footer/layout. When starting a new article, they would start by copying a previous post and then tweak the design. The upshot is that a user can follow the evolution of the design from older posts to newer posts, and the design can even be adjusted to better match the content of each individual article. I don’t think I’d like it if every website worked like this but it’s a neat idea for a personal website.
On the subject of this thread, I’m a tablet hater and I think “SSH is painful on tables” is an argument against modern day tablet UIs.
Now, a shameless plug: my generator supports extracing metadata from HTML natively. ;)
The blog index at https://soupault.neocities.org/blog/ is autogenerated. The config basically says “use <h1> for the post title, <time id="post-date"> for the date and first paragraph for excerpt”. However, ["p#post-excerpt", "p"] means “use <p id="post-exceprt"> if it’s present, else just use the first paragraph”, so I can use any paragraph for the blog index page, not just the first.
`dump_json = “index.json” saves extracted metadata to a file, that’s what I generate an Atom feed from with a script.
Now, a shameless plug: my generator supports extracing metadata from HTML natively ;) The blog index at https://soupault.neocities.org/blog/ is autogenerated.
As far as static site generation, I think this is a much better idea than YAML front matter. I do a similar thing, except not for my index page, only for my RSS feed, which is generated on the fly with a PHP script (example).
I chose PHP specifically because I wanted to avoid local generation. There are just two many drawbacks, like the fact that you can’t update your site on another system, where your generation tools aren’t installed or even supported.
Ah, the feed is dynamically generated. For some reason I thought you wrote a local feed generator in PHP.
If you find yourself working on random machines often, that’s a valid concern indeed. Soupault itself is “download the executable and run” for all major OSes, though my Atom feed generator script is not. CI deploys can also solve that problem though.
I used to do that for my site years ago. When it got to a certain size, I decided to do something about it and converted my entire site to XML and use XSLT to convert it to HTML. The XSLT handles the generation of each page and ensure all the links work properly. I use CSS to handle the style, and rsync to move the files to the server.
For my blog I wrote my own blogging engine (that I’ve been using for 20 years now), with three ways to import new entries:
a web page with a textarea entry field
via email (my preferred method)
via a file on the server
Each entry is stored as a separate HTML file; it’s the blogging engine that strings all the entries together for a view. I used to write each entry in HTML, but for the past year I’ve been using a custom markup (that’s geared toward how I write and is a mashup of Markdown and Org Mode) but saving the resulting HTML.
Good question. At the moment, I copy from an existing page in the same directory location and edit the content. When I need to change something for all pages, if I can, I use the “find and replace all” tool in my editor (VS Code) to do the change in bulk. If I can’t use that, then I have to tediously go page by page and make the change, and verify they are all the same.
My site is still small and simple- but today I was thinking about how I’d like to write my own little preprocessor to handle that stuff. As I start adding more pages to my site, it’ll become too annoying to do it by hand. Once I have that little tool though, as long as I stay with my “simple” themes, I’ll be fine. I don’t have any intention currently to make it complicated (ex- my site has no JS).
One of my blog setups was HTML written in Pug: it had a master.pug with the html root and a block body-section down below, then post.pug would extend ./master.pug on the first line and fill in block body-section, leaving another block for me to define in a blog post.
Each post would look like extends ../post and then it would just define block post. This isn’t maybe exactly what you had in mind, but I find using Pug a pretty reasonable way to write HTML. Right now I blog via markdown/hugo, but I consider switching back to my Pug setup.
Ghost is really good. I love their UI. I was one of their kickstarter backers actually. I’d love to go back to Ghost, but I find their pricing very expensive. I could self-host of course, but introduces all the reasons you listed above.
You’re right about the $$$. $30/mo is about the absolute max of what I’d be willing to pay for a professional development blog.
For me, I think it is worth it. As someone who doesn’t have a college degree whatsoever, I think it’s important that I can sound smart about things people w/ college degrees know about, so it serves a more critical role for me than the average tech worker.
I’ve said before that, since it’s open, some company should do a 3rd-party version hosted dirt cheap. It could just run on $5 VM’s and such. If they make real money, they can contribute back to Ghost’s platform and/or just send some of it their way.
run the most bug filled insecure CMS you can find. Leave it somewhere not publicly accessible. (e.g. have apache hide it behind http basic auth and https)
on publish, use wget --mirror -k to generate static pages from it
publish those in public
Presumably something like this already exists as a plugin for WP? Any dynamic site generator that doesn’t do anything too surprising in the frontend code is probably one wget invocation away from doubling up as a (slow) static site generator. ;)
I’ve done exactly this in the past and am in the process of doing it again for my personal site.
WP has a decent plugin to offload its media library to an S3 bucket; that combined with wget was all I needed.
Caveats: you lose comments (no loss in my case) and you will want to edit your theme a bit to remove links to login pages etc. which won’t work from the static mirror. This time I’m planning on putting the whole thing (content pages plus media lib) onto S3.
Why bother? I do my photo editing on my iPad these days, and I read a lot on it. The iOS WordPress app provides a very nice “share to” feature that would be tricky to reimplement with some combination of Siri Shortcuts, git, Hugo etc.
WordPress is software that is always running. I don’t like software that is always running and accepts input. If something’s on, it can be turned off or its inputs abused. I ran WordPress for more than a decade and if I spent as much time writing as I did maintaining the server and the WordPress installation, I imagine I’d be retired from what I’d contributed to the world 2¢ at a time.
GitHub, GitLab, and a host of others, plus a basic CI tool, delegate the maintenance of the “always on” software to someone else. Don’t like that? GitBucket or Gitea let you keep it private and run things locally or on your home network. Different moving parts than WordPress but much more easily secured and thus fewer things to worry about so you can focus on the main goal at hand: writing your thoughts and sharing them with the world.
Is that not the case for Apache, Nginx etc? All servers run software 24x7.
Different moving parts than WordPress but much more easily secured and thus fewer things to worry about so you can focus on the main goal at hand: writing your thoughts and sharing them with the world.
I disagree. I don’t think a static site offers a means of just writing your thoughts down.
Is that not the case for Apache, Nginx etc? All servers run software 24x7.
I do think there is a difference between a web server, that basically just reads, and a program within a web server that works with databases, changes files, etc.
I try to minimize the pieces. If I could get by without Apache and nginx, I could.
I disagree. I don’t think a static site offers a means of just writing your thoughts down.
I think this is some mixture of training and preference. I’ve used both and try to use markdown as much as possible. Being able to create a markdown anywhere, in any editor and publish later is easier for me than having to log into WordPress.
I’ve had an easier time training non-techs to use WordPress but that also involves perpetual support and debugging. When markdown takes, it requires less support from me. And markdown is pretty common via reddit, Wikipedia, and other sites.
I ran my blog with a static site generator, Pelican to be specific, for a few years. I even came up with a nice bunch of Chef recipes to make managing a static site using Pelican easier.
But ultimately? The whole experience just didn’t work for me. Like this post’s author, I found myself being inspired to write a blog post at the very times a static site made that incredibly inconvenient.
There’s also the fact that I’m not a web designer. I write HTML/CSS that’s ugly as sin. I recognize that these aesthetic muscles can be developed just like any other, but I’m focusing on my core development competencies for the foreseeable future and am happy to delegate this to others.
One day I realized that I wasn’t writing anymore simply because the activation energy required had grown past the point where I wanted to do it at all regularly, so I decided to switch back to Wordpress.
Not being an infosec professional, and having done a REALLY bad job of running a Wordpress instance myself a number of years back, I decided to outsource and now use Wordpress.com to manage my Personal Blog.
They handle the hard work of keeping everything up to date and managing attack surfaces, they have excellent policies around data ownership (At least good enough for my personal needs) and I get the super smooth user experience Wordpress provides.
I’m very glad I did. The moral of this story is to find the tools that work for you and embrace them with aplomb.
I think that static site generators have their use, but maybe not for the average user. It’s definitely nice to have a web interface and content management system, rather than controlling your servers from the command line. Where static site generators shine is non-standard content, and more “advanced” functionality. For instance, in my compiler series I frequently include fragments of code from the work-in-progress compiler. With a static site generator, I can write a macro to load parts of another file (or the whole file), and move on working on my compiler without worrying about having to update the post content. Crafting Interpreters has its own static site build system, which it uses to display incremental changes to the codebase.
Additionally, there are content management systems for static site generators, like Forestry. I have never used them, so maybe someone more qualified can comment!
In this thread: programmers fail to realize static site generators are tools only a programmer could love. (In their current form, at least. iWeb works for normie people.)
I’ve been in the programming game for over 20 years and one thing programmers love to do is torture themselves with bad tools. There needs to be a serious study done on this by anthropologists because clearly the development community can’t break the cycle.
We lionize terrible tools and practice lots of ancestor worship; that’s ground for anthropologists if I found any…
(On topic: I might be a programmer, but I don’t like the kind of programmer tools programmers love; that and SSGs require so much ceremony or fragile automation that I never bothered. Between WP being more effort to administrate, I write plain HTML…)
For me, the reasons to use a static site generator are:
Ability to use my favourite editor. Editing in a web page feels so cramped and none of the keybindings I’m used to are working. I vaguely understand that one can set up a browser to have vim or emacs keybindings, but that’s painful in its own way. I ran Vimperator for a while, but in the end decided it’s not really the same.
Security. It really doesn’t appeal to me to use some overcomplicated system which requires constant attention / updates just to publish a few pages of text.
Ease of customization. This is probably just me, but I find static site generators simpler and more malleable than most CMSes.
Revision history. Not as important for posts, but sometimes it’s nice to be able to go back in git and look at why I changed something. And it just feels nice, knowing you can never lose anything you’ve already committed.
Finally, I don’t understand why it’s so important to be able to publish anywhere, anytime. When I write a post, I spend days on it editing and tweaking it before it’s ready to publish. You can do that anywhere, anytime, in any text editor. Then when you’re ready to publish, you just move the file over to the target machine and publish it. The advantage of using something like Markdown is that you don’t lose markup (of course, there are CMS plugins to support Markdown, too; you don’t have to use a WYSIWYG editor - but again, that’s not really standard).
Ability to use my favourite editor. Editing in a web page feels so cramped and none of the keybindings I’m used to are working.
While I agree with this in principle (I edit my own blog (in Emacs, of course), I’ll note that I have probably written 10x more text on this site alone than on my blog since I became a member (my blog output was not larger before then).
For some people, OP and me among them, immediacy does matter.
That’s a very good point, and I probably have written more here than on my own blog too. The main difference is that here I don’t mind so much if I make a typo, it’s all informal and there’s very little need to edit and re-edit what I’m saying.
When I write a blog post, I tend to go all out and spend days on it, writing and re-writing. That requires a lot more editing comfort than spending a couple of minutes to reply to a post here. Having said that, if one writes many shorter blog posts, I’m sure something like Wordpress, where you can just type and submit to publish is more convenient.
I agree. I’m a big fan of online expression (blogging was the most fun thing that happened in a long time!) and I’m all for people using the tools they prefer to get their words out. I must admit I’ve found some of the comments in this thread rather amusing, in that it seems a lot of people think the technology they use to get their words published is more important than the words themselves.
Tech folks (myself included) can get really caught up in the tools they use. Many wear it as a point of pride to be using only the best tools, or perhaps the ones that are most difficult to master. You could call it snobbery or elitism if you’re feeling less charitable.
That sounds like “I like to edit in production unless there are particular reasons against it, and here’s a list of reasons that don’t apply to my blog: 1) … 2) … 3) …”
I suppose he’s right in principle, the consequences of a misstep are his own, but I can’t say I like it. Editing in production is the kind of activity we should habituate ourselves against doing.
Editing prose in production is vastly different than editing code in production. Did you write that comment on production Lobsters? And honestly, are you really implying that home setups should be doing things the way big operations are doing things, with a staging environment etc.? That costs a lot of time, and probably real money. (If I’m misunderstanding please do correct me, but that’s what it sounds like.)
That prose is the payload — the most important thing on that server. It’s what everything else supports.
I have a staging environment etc., and it cost me nothing, and no time either. I didn’t even consider not doing it.
It cost me no time, because I know how to git clone etc., there was nothing new to learn. Using version control is a habit now. Once I had the git repository for running the server, running the same thing on a second computer wasn’t a problem at all, why would it be? And I had a computer at home with disk space to spare, and of course that computer is running whenever I’m typing.
Maybe I’m saying that editing in production makes kevq sound like the kind of person who does not use version control by default. As a matter of habit.
It’s easy to think something is simple and make a big mistake. So I avoid manually touching prod.
When I was young, a senior programmer at my company logged into production to edit prose. He crashed the janky dos/Novell system because his editor saved the file with a different character encoding or byte order mark or something like that. He was a retired navy commander and thereafter his nickname was “Commander Crash.” He was/is a really smart dude.
Of course if he was smarter or luckier he could have avoided the error. But it’s very possible to not understand everything and think a change is simple. I don’t have to see the train or even the train tracks to be run over by a train.
I’ve brought down a production server by editing XML config files (yikes!) in production, and forgetting the BOM. But that was a footgun entirely of our own making, starting with the braindead decision to use UTF-16 XML as a config language…
WordPress is a CMS (“content management system”) and at least when I self-hosted there was a whole raft of permissions and roles available so that you could monitor and sign off on people’s content before it got published. I don’t know if that part is emphasized anymore outside of bigger blog outfits.
When I publish a blog post, I might find a spelling error after the fact. Considering that my readership is probably in the low 10s (similar to the vast majority of blogs out there) this is acceptable to me.
A misunderstanding, perhaps… by “we” I meant the kind of people who use words like “fosstodon” and “multi-factor authentication”. I didn’t mean “the rest of us”, which I expect wordpress serves quite well.
The author is not wrong - online editing is something I sometimes miss when I moved my blog over to a home-built static site generator. But there is nothing stopping somebody from making an interactive site that allows editing from a webpage for admins but generates static pages for normal users when you hit post. I really wished WordPress and similar sites worked that way (there are probably plugins that do) - best of both worlds.
I actually prefer the static site as it least gets in the way of making content. If I used a CMS, I’d be too tempted to preview and tweak how things look. By forcing myself to just write a markdown file and get going I’m more likely to get something written.
I do occasionally have the temptation to tweak, but generally have been good about avoiding it. I do want to add sidenotes at some point that are mobile-friendly, and expect that to take a weekend as I obsess over which style I want to adapt.
But 90% of my usage is open markdown file, run ./site server to do a quick check over how images and figures rendered, and run ./site deploy
I have my simple blog hosted on WordPress.com, and considering switching to a static site generator.
What bothers me a lot about WordPress.com is that basically unsuited for authoring technical content. I had troubles inserting tables at one time, and I eventually desisted.
Not sure if this counts but possibly NetlifyCMS? I haven’t tried it myself but I’ve heard it works with Hugo and a bunch of other systems out of the box.
If you’re looking for something a bit more flexible/custom, I have a CraftCMS + NuxtJS setup that works well. The CraftCMS install is private and has a JSON API with my blog feed in it. When I post a new blog, Craft then sends a request to the Netlify webhook to regenerate my static site. NuxtJS then fetches the data from the Craft API and generates the HTML.
I don’t use dynamic sites, but if I had to, I think I’d just put a CDN or Varnish cache in front of them.
The website is dynamic, but unless there is a new article every second, you can cache the homepage and each article as if they were static HTML, right? Thus achieving the performance of a static site.
As for the case when it’s a high-traffic & high-frequency updating website (e.g., newspaper site), caching 1 minute or 2 can avoid a lot of useless same calls to the PHP or other backend code.
Pretty much, yeah. I cache my site and use a CDN. That’s what makes its performance comparable to an SSG.
I suppose the advantages are that an SSG wouldn’t have to set that up in the first place, but once done, the writing process is much easier (I think) with WP.
Maybe my approach (for https://medv.io) isn’t popular, but I do NOT use any CMS, static sites generators; it’s just plain HTML/CSS (with include instructions for nginx) files on a server with self-hosted cloud ide.
I even NOT using git. Just edit and save it.
Before I was tried WordPress, Jekyll, Gatsby (an awesome one), and then deleted my blog at all 😁
Static files allow me to easily host subdirectories with my other projects.
I have a soft spot for WordPress; that being said I no longer use it for my personal websites opting instead for using a git repository with hooks on dev, staging and master branches that spin up deployment to one of three environments. I am able to edit and deploy through either an IDE or web interface although neither currently have the comforts and easy to use tooling that something like WordPress affords.
His intro quote calls out the difficulty of editing a SSG on an iPad. This is an easy problem to avoid. One of the main reasons I like SSG is the ease of editing and deployment. I run a blog off of Jekyll that is rebuilt every time I edit a file on GitHub. Just a simple Action that builds and ftps it over to a host. So I typically just use GitHub’s browser editor on my phone. Can’t get much simpler than that and the security on GitHub is probably better than the security on the WordPress sites I run.
It’s cool that people like WordPress, it’s a popular tool. But the post seems to tl:dr; to “I am familiar with WordPress and like it.” And that’s perfectly fine.
But I like SSGs because they are much harder to crash and easier to recover and scale. WordPress takes more skill to maintain and requires a more expensive host.
I run a blog off of Jekyll that is rebuilt every time I edit a file on GitHub. Just a simple Action that builds and ftps it over to a host.
How do you handle authentication? I’ve thought about setting up something similar, but the idea of putting SSH keys on github/gitlab/… makes me nervous.
I created a limited access ftp account and store the password as a GitHub encrypted secret. GitHub’s security seems pretty decent and worst case scenario is that the password is compromised and all they can do is put something up on my site. At which point, I reset the account, wipe, and rebuild.
Are you saying there is not security issue in wordpress?
No, I never said that. In fact, I said the exact opposite of that in the post. I’m not sure where you got that from.
It is harder to write plain text file and run a command than maintain a wordpress website?
It’s not just running a command though it is? To write a post from the CLI, you have to SSH, run the command to launch vim/nano/emacs/whatever. You then need to write the post, save it, re-generate the site and potentially upload any changed files to your web server.
On wordpress, I launch the app, tap “new post”, write the post and hit publish.
Anyway, horses for courses. I’m glad a static site works for you.
What about a text editor with git support on a tablet?
Then one launches the app, tapp “new file”, write the post and hit “git commit” ?
Different tasks are of different difficulty for different people.
I honestly hope you get wodpress going fine. Most WP security issues I’ve crossed were coming from plugins and not-so-maintained setups, so I guess it should go fine if you keep up with updates & so on.
I have run both static and Wordpress sites in the past and Wordpress definitely has a better publishing experience for most writers than a static site. Whenever the experience of publishing static sites is criticized, I usually only hear scoffing from developers glancing up from their wall of terminals. “How could this be hard for anyone else?” But the fact of the matter is that for most people, it is. If static is superior, then it would be awesome to see developers making tools that make it easier for the average writer to publish a static site instead of being confused about someone “not getting Jekyll”. Make it easy to do it the right, secure way. My position right now makes me the interface between a lot of “average” users and complicated tools and especially now that we are working remotely, I am intensely interested in making processes easier (and still safe) for my users, even if I have to sacrifice technical purity. But when I can help them complete the task in the best way, easily, then that’s a big win.
The tools exist. You can add a content manager on top of a static generated site, like Netlify CMS or Forestry, just to cite two of them. They’re called headlessCMS and there’re a lot of them.
There’re others advantages on going static that @kev doesn’t talk on this post. For example, I think the most important for me is that you can pass the trouble and cost of maintaining a server with php, a database and a webserver running 24/7.
But at the end of the day I don’t think there’s only one right way to do things. I agree with @kev:
I’ve tried Netlify, and I wasn’t impressed. Compared to just unzipping a version of WordPress on an Apache server and setting up a MySQL database, it felt very counter-intuitive and complicated to use and setup and I didn’t even get it to work in the end. All these headless CMSs seem very ad-hoc.
As @kev mentioned elsewhere in this thread, you still need a web server running to serve static content, which almost certainly has PHP enabled anyway. The only difference is that you don’t need a database. And I admit that databases are somewhat opaque compared to how static site generators structure the content, but there’s a reason that most CMSs store their data in a SQL database rather than in plain text files.
(As a sidenote, I’m not a huge fan of CMSs either. I myself have a static site, I just don’t use a static site generator.)
You generally don’t host a static site on an actual web server; Netlify or GitHub/GitLab Pages or S3 or whatever is a layer of abstraction on top of that. I use Google Cloud Storage for https://snazz.xyz, so I build my site locally and have a script that copies the files to my GCS bucket.
For my site’s traffic usage, replicated hosting on multiple continents is free (and then I pay by the GB of bandwidth after the first 5GB). Plus, I don’t have to do any maintenance whatsoever.
I just can’t see how this is simpler than just having a web server running. And I feel much more in control running my own web server on a VPS than hosting my site in Amazon’s or Google’s cloud.
I understand the need for control but I think that one of the main benefits of running a static website is that there is almost no vendor lock-in. That’s why I feel confident about hosting my personal blog on Netlify. If the company goes out of business tomorrow, migrating to something else will take 10 minutes at most.
There’s still much more vendor lock-in than with a simple web server. A WordPress installation looks identical, no matter what VPS it is hosted on. Same goes for Apache. But Netlify’s “in-browser edit” interface is different than GitHub’s, which is different than GitLab’s, and so on. If you want to be truly free, you can never really allow yourself to get used to Netlify/GitHub/etc, because if you get used to any specific service, the barrier for leaving it will be higher.
It’s not a huge deal, but it’s a big enough deal for me to feel uncomfortable with it.
From my observations, people treat the web editor as last resort (among github users, its use for anything is strongly discouraged—in collaborative development context, for valid reasons).
The advantage people love those things for is pushbutton deploy: you push generated pages to git, and the rest happens without you. With Github Pages’ built-in Jekyll, you push source files/configs/templates to git and generation also happens without you.
Myself I’m not fond of autogenerated files in git, and rsync+ssh to my own web server is all deployment automation I want (I made it a make target), but for some it’s a real selling point.
The reason I focus on the web editor is that lots of people in this thread are presenting it as a perfectly viable alternative to WordPress’ web editor, which I don’t really think it is.
I don’t know… I can’t see how this isn’t just another step in the process of updating the site that just makes it more complicated. Wouldn’t the most effortless solution just be a traditional shared web host with FTP access?
(Also, with GitHub + Jekyll, you still need to generate it on your own system to preview it, so I don’t see the benefit of any generation happening on GitHub, and don’t get me started on issues of version mismatch between GitHub’s Jekyll and my local installation…)
I think it’s just a tradeoff. Instead of managing SSH keys, apt unattended-upgrades, and Certbot, I just run this script on my computer every time I want to upgrade my site:
Maybe this is more complex overall, but the amount of stuff I have to keep in my head is much reduced this way. I can see why you might prefer to maintain control over the web host, but I’m perfectly happy not having to do any sysadmin tasks.
None of these are strictly necessary. I have no need for a non-self-signed SSL certificate, so I don’t need to worry about renewing it.
I understand, I didn’t mean that managing a web server is zero-effort in any way.
10 years back, my friends over at TheConversation.com.au created a “live” static site generator.
The public site was nginx serving html files off disk, but there’s a full CMS with a database, versioning, etc generating those files when an article is updated.
This architecture had the significant advantage that it was really, really hard to cause a public facing outage.
Also, truly huge amounts of traffic could be handled by a single, quite small server, even before adding a CDN to the picture.
Yes, the ability for even a small server to handle enormous numbers of page views is a definite technical advantage of a static site. I just think the number of moving parts in an SSG end up nullifying the advantages in the eyes of the prospective publisher. Tools that couple the publishing interface (especially on mobile) of WordPress with the speed and small attack surface of a static site are definitely in order. @kev mentioned Grav as one such tool in some of his comments, although I haven’t had the chance to try it. But my experience with SSGs eventually drove me back to just writing straight HTML in a decent IDE.
It’s been a loooong time, but isn’t that basically how MovableType worked?
MovableType definitely has a mode which does that. Charlie Stross’ blog is static and built with MovableType (or used to be)
One of the big features of WP over MT back in the day was “instant publishing”, you didn’t have to wait for the time-consuming “rendering” step.
I used to do something very similar with a home baked thing in ruby. Once I hit on it I was surprised it wasn’t a more common pattern.
Couldn’t agree more.
By the way, if you’re looking for a happy medium, check out Grav (https://getgrav.org). I used it for a while, but did run into some issues with it.
I started blogging with UserLand Radio and later Movable Type. While primitive by today’s standards, this software attempted to bridge these worlds. The blogging experience was through a dynamic application and the publishing output was static HTML.
As time progressed, I would often output “SHTML” (server-side includes) or PHP with these tools. That way you include more complicated dynamic pages for contact forms, surveys, etc. without using CGI scripts.
I’m curious as to whether the authors of tools like Grav, etc. have any experience with these older tools? Once Wordpress appeared on the scene, everyone ran in that direction of the easy of publishing, but we’ve had a lot of pain with maintenance and security vulnerabilities. I’m considering building something dynamic for my personal site which combines link blogging and photography because I know I’m more likely to publish to it when I have time, which also happens to be when I’m on my phone.
Radio and Frontier were quite advanced. They still have many features that are not present elsewhere. I miss Radio…
I think the thing missing from this discussion is that a lot of writers have their preferred text editor. I hate environments where I’m expected to write a large amount of text in anything other than my favourite text editor. Most writers I have met have an editor that they like (and often have customised a lot, with off-the-shelf plugins and custom key bindings / macros, even if they’re not programmers). If they’re using WordPress, they’ll write in something else, then copy and paste. If their favourite editor has native Markdown support, then they’ll use that and then copy it, otherwise they’ll paste text and then faff getting the formatting right.
The thing that they usually want is a mechanism to push directly from their editor to a live preview and then to deployment. That’s generally easy to hook up with a static site generator driven from git and a scriptable editor (these days, that means anything that’s not Notepad), but for a lot of commercial sites it often ends up having a manual step involving someone emailing a word document.
I find the ‘I need to edit in a web browser’ argument pretty weak.
I run a static website. It’s repository is currently hosted on GitLab GitLab has a web interface to edit files. Changes are automatically tested and pushed to the public through CI. And best of all, as I use markdown I usually prefer to edit in Vim, but I can use a million other tools if I’d like.
I’m not too sure about this workflow on an iPad, but I’m sure it isn’t as bad as the article author states for a static website.
GitHub also allows you to edit, preview, and commit directly from their web UI. So no, I don’t buy the argument either.
If he really wanted the pragmatic approach on iPad, he could’ve used Working Copy app, which allows you to edit your code and push it up to your Git repo. Then at this point he could have the setup that is described above, where it’s all automated.
Another aspect that’s important with a setup like this is having a deploy pipeline keyed off changes to the master branch.
Between github/gitlab webui PR authorship, and circleci deploying the changes, we don’t need a webui either for our static blogs.
does GitHub have CI pipelines? because you would need to create a CI pipeline to deploy changes from your repo to production in order for the web UI to be usable for this use case.
I don’t use their CI, but apparently yes they do have this.
For a team blog I’m working on at the moment, I’m using GitHub’s GitHub Pages mechanisms to automatically deploy whatever is on the
gh-pagesbranch of the blog’s repository. It’s free, it’s easy, and it works.Yeah, it’s not as robust as GitLab’s but is fairly easy to set up. I was able to go from never using actions to having a commit trigger build and FTP everything over in about two hours [0] and most of that was figuring out sftp command line quirks between Mac, Ubuntu and my host.
[0] http://prepend.com/setup/2019/12/figuring-out-actions.html
I was able to teach a retired journalist to use this workflow (and Markdown) without much trouble. The website was simple, he had a lot of time on his hands, and he was eager to learn.
Agreed, compared to that workflow my argument in regards to using a web browser is weakened. I’ll edit the post to reflect that. Thanks for the feedback.
I think there is still an important point in that argument. The only alternatives that have been presented have been ad-hoc solutions like a headless CMS – yet another separate component that you need to setup – or GitHub/GitLab’s in-browser editing – yet another external service that you need to rely on. With an actual CMS like WordPress, you have a single consistent interface that you can totally own and control yourself.
That’s true, thanks.
I don’t think this is an easy option for everyone. You still have to know a thing or two about git, github/gitlab, and continuous integration. It might be easy for you, but it’s not easy for everyone. You wouldn’t need to learn an insane amount of stuff, but I imagine it’s still more work than using WordPress.
I find the name “static site generator” kind of subconsciously promotes the idea of this just being all about some static files that move from here to there. What they usually come with though is a super complicated, fragile, and regularly updating toolchain that puts at risk your ability to generate the static part that was supposed to be simple. We have a couple “static” sites that are almost impossible to update now because the tooling that generates them is no longer being maintained, so it’s harder and harder to run that tooling successfully. They don’t feel like “static” sites very much anymore.
I agree with you on this, but surely these issues can happen to any CMS.
If the generation code is exercised on very web page visit it’s likely to degrade much more slowly than if it’s only exercised when there’s new content.
You’re not the first person I’ve heard say that. I know a few people who spend an inordinate amount of time administering issues on their static sites.
This gets easier if your tooling isn’t on a platform that gets old.
My static site generator is written in Clojure. Last commit, 2015. Going strong, no changes necessary to run it today.
Another reason, from the opposite point of view, is that static site generators are often an unnecessary burden. You can just write the HTML5 directly, very easily. Most tags do not need to be closed in modern html, and it is just as readable as markdown. No need to write your text in a slightly different language and then compile it.
To be honest, I find writing HTML for prose painful; it’s hard to write and hard to read, and there are a bunch of caveats you need to be careful about (like writing
<as>). Writing stuff like<strong>bold</strong>or<code>quote me</code>just takes too much time when writing; I want to focus on actually writing content, not typing HTML tags. For me, the biggest advantage of Markdown is that it gets out of my way and allows me to focus on the actual content – which is already hard enough – instead of the syntax.YMMV, and whatever works for you of course, but I think this is the added value for a lot of people.
Prose rarely has boldface or other fancy stuff. If you need to use it too much, then you are doing something wrong. That said, you can use the “i” and “b” tags which are shorter. The only thing that I find annoying when writing html prose is “p” the paragraph tags. I would prefer if a blank line started a paragraph. But I can live with those.
In the cases when you need some markup, html5 tables are actually easier than markdown tables, and lists and links are mostly equivalent.
Maybe prose is the wrong word (not native speaker 😅); I mostly mean stuff like articles (i.e. longer versions of comments on Lobsters) where various forms of formatting are fairly common. Common enough for me to be distracted by it, anyway.
I actually find tables to be one of the more ugly parts of HTML; so many tags, and often not that readable as source code.
Regarding tables, notice that with HTML5 you don’t need to close any table tags besides “table”. It’s actually cleaner than the many flavors of markdown tables.
Maybe I’m just old-fashioned, but that’s what I do. I write the HTML by hand. It’s not difficult and my site is very fast.
How do you handle HTML that should be common to all pages, like the
<head>section or the top nav? Do you copy it over to each new page’s source, or do you have some kind of preprocessor to keep it defined separately?I saw a post (maybe on here) a while ago where the author said that they write their HTML by hand and they were asked how they manage these bits of common markup. Their response was that they explicitly do not make sure every page has the same header/footer/layout. When starting a new article, they would start by copying a previous post and then tweak the design. The upshot is that a user can follow the evolution of the design from older posts to newer posts, and the design can even be adjusted to better match the content of each individual article. I don’t think I’d like it if every website worked like this but it’s a neat idea for a personal website.
That was my post :-) You can look at the different articles here on my site to see an example of the difference in styling.
On the subject of this thread, I’m a tablet hater and I think “SSH is painful on tables” is an argument against modern day tablet UIs.
Now, a shameless plug: my generator supports extracing metadata from HTML natively. ;) The blog index at https://soupault.neocities.org/blog/ is autogenerated. The config basically says “use
<h1>for the post title,<time id="post-date">for the date and first paragraph for excerpt”. However,["p#post-excerpt", "p"]means “use<p id="post-exceprt">if it’s present, else just use the first paragraph”, so I can use any paragraph for the blog index page, not just the first.`dump_json = “index.json” saves extracted metadata to a file, that’s what I generate an Atom feed from with a script.
As far as static site generation, I think this is a much better idea than YAML front matter. I do a similar thing, except not for my index page, only for my RSS feed, which is generated on the fly with a PHP script (example).
I chose PHP specifically because I wanted to avoid local generation. There are just two many drawbacks, like the fact that you can’t update your site on another system, where your generation tools aren’t installed or even supported.
Ah, the feed is dynamically generated. For some reason I thought you wrote a local feed generator in PHP.
If you find yourself working on random machines often, that’s a valid concern indeed. Soupault itself is “download the executable and run” for all major OSes, though my Atom feed generator script is not. CI deploys can also solve that problem though.
I used to do that for my site years ago. When it got to a certain size, I decided to do something about it and converted my entire site to XML and use XSLT to convert it to HTML. The XSLT handles the generation of each page and ensure all the links work properly. I use CSS to handle the style, and rsync to move the files to the server.
For my blog I wrote my own blogging engine (that I’ve been using for 20 years now), with three ways to import new entries:
Each entry is stored as a separate HTML file; it’s the blogging engine that strings all the entries together for a view. I used to write each entry in HTML, but for the past year I’ve been using a custom markup (that’s geared toward how I write and is a mashup of Markdown and Org Mode) but saving the resulting HTML.
Good question. At the moment, I copy from an existing page in the same directory location and edit the content. When I need to change something for all pages, if I can, I use the “find and replace all” tool in my editor (VS Code) to do the change in bulk. If I can’t use that, then I have to tediously go page by page and make the change, and verify they are all the same.
My site is still small and simple- but today I was thinking about how I’d like to write my own little preprocessor to handle that stuff. As I start adding more pages to my site, it’ll become too annoying to do it by hand. Once I have that little tool though, as long as I stay with my “simple” themes, I’ll be fine. I don’t have any intention currently to make it complicated (ex- my site has no JS).
check out m4, a pre-processor capable of doing exactly what you want, built into *nix. :) That said, if you want to write one, don’t let me stop you!
Oh perfect, thank you! I’ll check it out.
you can see a very, very simple way to use it for html here: https://gitlab.com/aslrocks/aslrocks/-/blob/master/bin/convert_html and the template is there as well, obviously.
One of my blog setups was HTML written in Pug: it had a
master.pugwith thehtmlroot and ablock body-sectiondown below, thenpost.pugwouldextend ./master.pugon the first line and fill inblock body-section, leaving anotherblockfor me to define in a blog post.Each post would look like
extends ../postand then it would just defineblock post. This isn’t maybe exactly what you had in mind, but I find using Pug a pretty reasonable way to write HTML. Right now I blog via markdown/hugo, but I consider switching back to my Pug setup.That sounds painful. It would be better to write markdown and at least generate HTML from it and upload those files manually, if nothing else.
After years and years of maintaining a blog via a static site generator, last year I switched over to Ghost (not self-hosted) and haven’t looked back.
Ghost is really good. I love their UI. I was one of their kickstarter backers actually. I’d love to go back to Ghost, but I find their pricing very expensive. I could self-host of course, but introduces all the reasons you listed above.
You’re right about the $$$. $30/mo is about the absolute max of what I’d be willing to pay for a professional development blog.
For me, I think it is worth it. As someone who doesn’t have a college degree whatsoever, I think it’s important that I can sound smart about things people w/ college degrees know about, so it serves a more critical role for me than the average tech worker.
I’ve said before that, since it’s open, some company should do a 3rd-party version hosted dirt cheap. It could just run on $5 VM’s and such. If they make real money, they can contribute back to Ghost’s platform and/or just send some of it their way.
Obvious idea:
wget --mirror -kto generate static pages from itPresumably something like this already exists as a plugin for WP? Any dynamic site generator that doesn’t do anything too surprising in the frontend code is probably one wget invocation away from doubling up as a (slow) static site generator. ;)
I’ve done exactly this in the past and am in the process of doing it again for my personal site.
WP has a decent plugin to offload its media library to an S3 bucket; that combined with wget was all I needed.
Caveats: you lose comments (no loss in my case) and you will want to edit your theme a bit to remove links to login pages etc. which won’t work from the static mirror. This time I’m planning on putting the whole thing (content pages plus media lib) onto S3.
Why bother? I do my photo editing on my iPad these days, and I read a lot on it. The iOS WordPress app provides a very nice “share to” feature that would be tricky to reimplement with some combination of Siri Shortcuts, git, Hugo etc.
Nice.
I should maybe have mentioned the comments thing but I figured it could be assumed since it’s par for the course on a static site.
There’s a version of Wordpress packaged for Sandstorm that does something like that: https://apps.sandstorm.io/app/aax9j672p6z8n7nyupzvj2nmumeqd4upa0f7mgu8gprwmy53x04h
WordPress is software that is always running. I don’t like software that is always running and accepts input. If something’s on, it can be turned off or its inputs abused. I ran WordPress for more than a decade and if I spent as much time writing as I did maintaining the server and the WordPress installation, I imagine I’d be retired from what I’d contributed to the world 2¢ at a time.
GitHub, GitLab, and a host of others, plus a basic CI tool, delegate the maintenance of the “always on” software to someone else. Don’t like that? GitBucket or Gitea let you keep it private and run things locally or on your home network. Different moving parts than WordPress but much more easily secured and thus fewer things to worry about so you can focus on the main goal at hand: writing your thoughts and sharing them with the world.
Is that not the case for Apache, Nginx etc? All servers run software 24x7.
I disagree. I don’t think a static site offers a means of just writing your thoughts down.
I do think there is a difference between a web server, that basically just reads, and a program within a web server that works with databases, changes files, etc.
I try to minimize the pieces. If I could get by without Apache and nginx, I could.
I think this is some mixture of training and preference. I’ve used both and try to use markdown as much as possible. Being able to create a markdown anywhere, in any editor and publish later is easier for me than having to log into WordPress.
I’ve had an easier time training non-techs to use WordPress but that also involves perpetual support and debugging. When markdown takes, it requires less support from me. And markdown is pretty common via reddit, Wikipedia, and other sites.
Wow this guy hit the nail firmly on the head.
I ran my blog with a static site generator, Pelican to be specific, for a few years. I even came up with a nice bunch of Chef recipes to make managing a static site using Pelican easier.
But ultimately? The whole experience just didn’t work for me. Like this post’s author, I found myself being inspired to write a blog post at the very times a static site made that incredibly inconvenient.
There’s also the fact that I’m not a web designer. I write HTML/CSS that’s ugly as sin. I recognize that these aesthetic muscles can be developed just like any other, but I’m focusing on my core development competencies for the foreseeable future and am happy to delegate this to others.
One day I realized that I wasn’t writing anymore simply because the activation energy required had grown past the point where I wanted to do it at all regularly, so I decided to switch back to Wordpress.
Not being an infosec professional, and having done a REALLY bad job of running a Wordpress instance myself a number of years back, I decided to outsource and now use Wordpress.com to manage my Personal Blog.
They handle the hard work of keeping everything up to date and managing attack surfaces, they have excellent policies around data ownership (At least good enough for my personal needs) and I get the super smooth user experience Wordpress provides.
I’m very glad I did. The moral of this story is to find the tools that work for you and embrace them with aplomb.
I think that static site generators have their use, but maybe not for the average user. It’s definitely nice to have a web interface and content management system, rather than controlling your servers from the command line. Where static site generators shine is non-standard content, and more “advanced” functionality. For instance, in my compiler series I frequently include fragments of code from the work-in-progress compiler. With a static site generator, I can write a macro to load parts of another file (or the whole file), and move on working on my compiler without worrying about having to update the post content. Crafting Interpreters has its own static site build system, which it uses to display incremental changes to the codebase.
Additionally, there are content management systems for static site generators, like Forestry. I have never used them, so maybe someone more qualified can comment!
I like your compiler series. Having a reasonably readable compiler in not-Haskell/OCaml/SML is really nice.
I’ve been able to not update my blog with blosxom, wordpress and hugo equally throughout the years.
In this thread: programmers fail to realize static site generators are tools only a programmer could love. (In their current form, at least. iWeb works for normie people.)
I’ve been in the programming game for over 20 years and one thing programmers love to do is torture themselves with bad tools. There needs to be a serious study done on this by anthropologists because clearly the development community can’t break the cycle.
We lionize terrible tools and practice lots of ancestor worship; that’s ground for anthropologists if I found any…
(On topic: I might be a programmer, but I don’t like the kind of programmer tools programmers love; that and SSGs require so much ceremony or fragile automation that I never bothered. Between WP being more effort to administrate, I write plain HTML…)
How are these low effort posts getting so many upvotes, it surprises me.
I guess it’s some sort of bikeshedding effect…
I upvoted it because I think OP is right.
The number of comments vehemently disagreeing tells me somehing though.
For me, the reasons to use a static site generator are:
Finally, I don’t understand why it’s so important to be able to publish anywhere, anytime. When I write a post, I spend days on it editing and tweaking it before it’s ready to publish. You can do that anywhere, anytime, in any text editor. Then when you’re ready to publish, you just move the file over to the target machine and publish it. The advantage of using something like Markdown is that you don’t lose markup (of course, there are CMS plugins to support Markdown, too; you don’t have to use a WYSIWYG editor - but again, that’s not really standard).
While I agree with this in principle (I edit my own blog (in Emacs, of course), I’ll note that I have probably written 10x more text on this site alone than on my blog since I became a member (my blog output was not larger before then).
For some people, OP and me among them, immediacy does matter.
That’s a very good point, and I probably have written more here than on my own blog too. The main difference is that here I don’t mind so much if I make a typo, it’s all informal and there’s very little need to edit and re-edit what I’m saying.
When I write a blog post, I tend to go all out and spend days on it, writing and re-writing. That requires a lot more editing comfort than spending a couple of minutes to reply to a post here. Having said that, if one writes many shorter blog posts, I’m sure something like Wordpress, where you can just type and submit to publish is more convenient.
I agree. I’m a big fan of online expression (blogging was the most fun thing that happened in a long time!) and I’m all for people using the tools they prefer to get their words out. I must admit I’ve found some of the comments in this thread rather amusing, in that it seems a lot of people think the technology they use to get their words published is more important than the words themselves.
Tech folks (myself included) can get really caught up in the tools they use. Many wear it as a point of pride to be using only the best tools, or perhaps the ones that are most difficult to master. You could call it snobbery or elitism if you’re feeling less charitable.
That sounds like “I like to edit in production unless there are particular reasons against it, and here’s a list of reasons that don’t apply to my blog: 1) … 2) … 3) …”
I suppose he’s right in principle, the consequences of a misstep are his own, but I can’t say I like it. Editing in production is the kind of activity we should habituate ourselves against doing.
Editing prose in production is vastly different than editing code in production. Did you write that comment on production Lobsters? And honestly, are you really implying that home setups should be doing things the way big operations are doing things, with a staging environment etc.? That costs a lot of time, and probably real money. (If I’m misunderstanding please do correct me, but that’s what it sounds like.)
That prose is the payload — the most important thing on that server. It’s what everything else supports.
I have a staging environment etc., and it cost me nothing, and no time either. I didn’t even consider not doing it.
It cost me no time, because I know how to git clone etc., there was nothing new to learn. Using version control is a habit now. Once I had the git repository for running the server, running the same thing on a second computer wasn’t a problem at all, why would it be? And I had a computer at home with disk space to spare, and of course that computer is running whenever I’m typing.
Maybe I’m saying that editing in production makes kevq sound like the kind of person who does not use version control by default. As a matter of habit.
It’s easy to think something is simple and make a big mistake. So I avoid manually touching prod.
When I was young, a senior programmer at my company logged into production to edit prose. He crashed the janky dos/Novell system because his editor saved the file with a different character encoding or byte order mark or something like that. He was a retired navy commander and thereafter his nickname was “Commander Crash.” He was/is a really smart dude.
Of course if he was smarter or luckier he could have avoided the error. But it’s very possible to not understand everything and think a change is simple. I don’t have to see the train or even the train tracks to be run over by a train.
I’ve brought down a production server by editing XML config files (yikes!) in production, and forgetting the BOM. But that was a footgun entirely of our own making, starting with the braindead decision to use UTF-16 XML as a config language…
WordPress is a CMS (“content management system”) and at least when I self-hosted there was a whole raft of permissions and roles available so that you could monitor and sign off on people’s content before it got published. I don’t know if that part is emphasized anymore outside of bigger blog outfits.
When I publish a blog post, I might find a spelling error after the fact. Considering that my readership is probably in the low 10s (similar to the vast majority of blogs out there) this is acceptable to me.
A misunderstanding, perhaps… by “we” I meant the kind of people who use words like “fosstodon” and “multi-factor authentication”. I didn’t mean “the rest of us”, which I expect wordpress serves quite well.
The author is not wrong - online editing is something I sometimes miss when I moved my blog over to a home-built static site generator. But there is nothing stopping somebody from making an interactive site that allows editing from a webpage for admins but generates static pages for normal users when you hit post. I really wished WordPress and similar sites worked that way (there are probably plugins that do) - best of both worlds.
You should try Grav (getgrav.org) it’s basically what you described.
I actually prefer the static site as it least gets in the way of making content. If I used a CMS, I’d be too tempted to preview and tweak how things look. By forcing myself to just write a markdown file and get going I’m more likely to get something written.
That’s very true actually. I don’t play around in the CMS that much, but it can be a distraction.
Based on previous discussions here about SSGs, around 70% of the time is spend developing and tweaking the software, and the rest is for content.
(BTW this mirrored my own experiences back when I bothered to tweak my blog).
I do occasionally have the temptation to tweak, but generally have been good about avoiding it. I do want to add sidenotes at some point that are mobile-friendly, and expect that to take a weekend as I obsess over which style I want to adapt.
But 90% of my usage is open markdown file, run ./site server to do a quick check over how images and figures rendered, and run ./site deploy
I have my simple blog hosted on WordPress.com, and considering switching to a static site generator.
What bothers me a lot about WordPress.com is that basically unsuited for authoring technical content. I had troubles inserting tables at one time, and I eventually desisted.
I’d love a static site generator that has a dynamic backoffice. I could run it behind https auth on a different domain.
Seems the most obvious idea to me, but I am not aware of any.
Not sure if this counts but possibly NetlifyCMS? I haven’t tried it myself but I’ve heard it works with Hugo and a bunch of other systems out of the box.
If you’re looking for something a bit more flexible/custom, I have a CraftCMS + NuxtJS setup that works well. The CraftCMS install is private and has a JSON API with my blog feed in it. When I post a new blog, Craft then sends a request to the Netlify webhook to regenerate my static site. NuxtJS then fetches the data from the Craft API and generates the HTML.
Thank you. I’ll investigate these.
getpublii.com getlektor.com
This looks very promising, particularly lektor.
Damn, I have much investigation and playing around to do.
I don’t use dynamic sites, but if I had to, I think I’d just put a CDN or Varnish cache in front of them.
The website is dynamic, but unless there is a new article every second, you can cache the homepage and each article as if they were static HTML, right? Thus achieving the performance of a static site.
As for the case when it’s a high-traffic & high-frequency updating website (e.g., newspaper site), caching 1 minute or 2 can avoid a lot of useless same calls to the PHP or other backend code.
Pretty much, yeah. I cache my site and use a CDN. That’s what makes its performance comparable to an SSG.
I suppose the advantages are that an SSG wouldn’t have to set that up in the first place, but once done, the writing process is much easier (I think) with WP.
How do you handle traffic spikes e.g. like getting to the top of Lobste.rs or HN or Reddit with a WordPress installation on a VPS?
Maybe my approach (for https://medv.io) isn’t popular, but I do NOT use any CMS, static sites generators; it’s just plain HTML/CSS (with include instructions for nginx) files on a server with self-hosted cloud ide. I even NOT using git. Just edit and save it. Before I was tried WordPress, Jekyll, Gatsby (an awesome one), and then deleted my blog at all 😁 Static files allow me to easily host subdirectories with my other projects.
[Comment removed by author]
I have a soft spot for WordPress; that being said I no longer use it for my personal websites opting instead for using a git repository with hooks on dev, staging and master branches that spin up deployment to one of three environments. I am able to edit and deploy through either an IDE or web interface although neither currently have the comforts and easy to use tooling that something like WordPress affords.
His intro quote calls out the difficulty of editing a SSG on an iPad. This is an easy problem to avoid. One of the main reasons I like SSG is the ease of editing and deployment. I run a blog off of Jekyll that is rebuilt every time I edit a file on GitHub. Just a simple Action that builds and ftps it over to a host. So I typically just use GitHub’s browser editor on my phone. Can’t get much simpler than that and the security on GitHub is probably better than the security on the WordPress sites I run.
It’s cool that people like WordPress, it’s a popular tool. But the post seems to tl:dr; to “I am familiar with WordPress and like it.” And that’s perfectly fine.
But I like SSGs because they are much harder to crash and easier to recover and scale. WordPress takes more skill to maintain and requires a more expensive host.
How do you handle authentication? I’ve thought about setting up something similar, but the idea of putting SSH keys on github/gitlab/… makes me nervous.
I created a limited access ftp account and store the password as a GitHub encrypted secret. GitHub’s security seems pretty decent and worst case scenario is that the password is compromised and all they can do is put something up on my site. At which point, I reset the account, wipe, and rebuild.
I found this analysis of Hacker News’ users’ personal blogs quite interesting: https://www.dannysalzman.com/2020/04/08/analyzing-hn-readers-personal-blogs
Are you saying there is not security issue in wordpress?
Say that to the first admin you meet to get a free knee-jerk reaction.
Also, even if iPad and iPhone are pretty limited operating systems, they still provide ways to access to a server through SSH.
Are we really there? It is harder to write plain text file and run a command than maintain a wordpress website?
No, I never said that. In fact, I said the exact opposite of that in the post. I’m not sure where you got that from.
It’s not just running a command though it is? To write a post from the CLI, you have to SSH, run the command to launch vim/nano/emacs/whatever. You then need to write the post, save it, re-generate the site and potentially upload any changed files to your web server.
On wordpress, I launch the app, tap “new post”, write the post and hit publish.
Anyway, horses for courses. I’m glad a static site works for you.
What about a text editor with git support on a tablet?
Then one launches the app, tapp “new file”, write the post and hit “git commit” ?
Different tasks are of different difficulty for different people.
I honestly hope you get wodpress going fine. Most WP security issues I’ve crossed were coming from plugins and not-so-maintained setups, so I guess it should go fine if you keep up with updates & so on.
That’s one way to run it. I just edit files in GitHub with my browser and that’s it.
Or you could have your WordPress post trigger a static site generation [0].
It kind of depends on what process you have set up and there’s lots of browser interfaces to SSG.
[0] this and many others, https://wordpress.org/plugins/static-html-output-plugin/