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 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.