And that’s bad in my opinion. Not because of an abstract appreciation for simplicity, but because the web doesn’t belong just to software engineers. The more we make the web complex, the more we push normal users into the enclosures that we like to call social networks.
Most of the complexity of a social network has nothing to do with the web as a platform - it has to do with the logistics of publishing anything at all online at scale and with reasonable uptime, and crucially delivering content people who want to see to people who want to see it (subject to the very real political constraints around this).
And so, while we software engineers enjoy free hosting & custom domain support with GitHub Pages / Cloudflare Pages / etc, normal users are stuck with a bunch of greedy clowns that make them pay for every little thing, all while wasting ungodly amounts of computational power to render what could have been a static website in 99% of cases.
The company that runs GitHub Pages is made up of greedy clowns just as much as the company behind Wordpress is. Indeed, I avoid hosting things on GitHub Pages myself, and I would advise any skilled software engineer to avoid it as well. But many skilled software engineers do not care as much about self-sovereign computation as I do, and are happy to use GitHub pages because it’s easy, just as people use Wordpress or whatever the Wordpress hosting site is that’s involved with that linked controversy, because it’s easy. And in any case even Wordpress is still mostly used by some kind of professional web content person - the vast majority of ordinary, nontechnical people are posting their words for public consumption on major social media networks that are run by some of the most well-known companies in the world, and are an important factor in real-world-politics.
Social media networks are incredibly complicated pieces of software, and they’re mostly complicated for essential reasons rather than accidental ones. The amount of effort that would go into, for instance, replacing DNS with something easier for a nontechnical user to use is staggering. It would entail literally ripping out a core portion of the internet’s infrastructure that dates back decades.
I agree that it would be good if it were easier for nontechnical people to use computers to publish their writing in a way that didn’t require them to be dependent on a large company with a complicated web frontend. But I’m under no illusions that this is an easy problem - and treating the complexity of the web frontend as the primary thing to be worried about seems like it is greatly missing the forest for the trees.
Indeed, I avoid hosting things on GitHub Pages myself, and I would advise any skilled software engineer to avoid it as well. But many skilled software engineers do not care as much about self-sovereign computation as I do, and are happy to use GitHub pages because it’s easy
It’s not just that it’s easy, it’s easy to leave. I host cheriot.org on GitHub Pages, for example. The source is all in a git repo. When I push to the main branch, a GitHub Action runs, builds the site, generates an artefact, and pushes it to the site.
If GitHub ever annoys me sufficiently, it would take about ten minutes to set up a server that had a post-receive hook that ran the deployment (that’s what I do for my personal University of Cambridge page, which isn’t on GitHub but uses the same tooling) and deploy it on another web server. Most of the migration time would be waiting for cached copies of the DNS record that points to the GitHub Pages servers to expire. Until that point, I’m happy for GitHub to pay for the hosting.
And this, to me, is the key thing for sovereignty: freedom from lock in.
It’s been a while, but my experience of non-technical people publishing websites is that they are perfectly capable of managing an FTP client. It’s all just files and folders. Shared hosting where you can upload files to some web space remains a straightforward service to purchase. However they aren’t going to be writing HTML, with or without an LSP. It’s the FrontPage, iWeb sort of thing that has gone out of vogue. I think we’d do better to bring that back rather than trying to get folks up to speed with static site generators intended for technical people.
I wonder why those have gone out of vogue. Is it because more people are on mobile systems and simply don’t like running such local programs anymore? Or is it the hassle of connecting over FTP (which can be rather janky, leaving you with truncated files or half-synced sites and such)? Or is it the wide availability of themes for Wordpress and co?
Or maybe it’s the extensibility - start with a simple Wordpress site, but add some plugins and you have a working web shop. Also, comments are tricky to do unless you have something dynamic running on the server. That’s a pain point of static sites, too. Although perhaps nowadays comments aren’t as important anymore because almost nobody blogs anymore.
[1] probably better known as the co-creator of Stack Overflow now
Also, I thought there was a thing where “Gen Z” supposedly doesn’t know how to use windows/mouse/folders as much anymore, since they grew up with phones and tablets. So I am not sure you could bring back Front Page, because the UI is for people who are used to MS Word and PowerPoint and the like.
I have seen a few mobile apps for publishing web content, but it seems like they are niche (?)
In what turned out to be a monumentally wrong bet, I thought that people would want to blog on Windows, with all the slick WYSIWYG editing goodness that wasn’t yet available in early versions of HTML.
This line is interesting
I think the problem is that people didn’t want to install Windows software, and also they perhaps didn’t have “one device” anymore – they had multiple devices that they wanted to publish from (work and home, etc.)
It’s been a while, but my experience of non-technical people publishing websites is that they are perfectly capable of managing an FTP client. It’s all just files and folders.
They might be more technical than you think if they can handle that.
A lot of people are technical enough to understand the concept of dragging files from one folder to the other, yes. It’s a fairly common problem to assume that all “non-technical” people are equal to the least capable person.
I worked with (bank) office workers in the late 90s and my coworkers were very comfortable with IBM mainframe interfaces but really intimidated by Windows.
And I also remember people with all their files on the desktop, because at least they knew where they were.
The other is a collection of static HTML files and one or two CSS files. No JavaScript anywhere.
Where does this no JavaScript assumption came from? It’s completely unrelated to how the browser content is assembled/served. That is the whole point of javascript. Looks like people still get awfully confused about this in 2024.
The JavaScript would be optional for both a Wordpress-like CMS site and a static site. But let’s be real, it’s way more common for framework-heavy CMSes to inject loads of JS garbage into your site than it is for static website generators to do so.
I have not been too active in web development the last few years, but my perception is almost the opposite. Themes for static sites generators are all slick full of effects and other javascript overhead even for layout purposes.
It probably depends a lot on the theme, but I’ve not seen much JavaScript in Jekyll themes I’ve considered using. The only places I’ve used JavaScript on a web site thing[1] was for interactive maps (via leaflet). CSS is incredibly powerful now (there’s a reason WebKit added a JIT for CSS in 2014) and pretty much everything that I would have done for UI things with JavaScript I’d now do with CSS.
[1] As opposed to a web app. I used a bunch of JavaScript in a demo to display a code editor in a browser that could push code to an Azure Function that compiled JavaScript to bytecode and used MQTT to push it to a device.
In front of you are two personal websites, each used as a blog and to display basic contact info of the owner
This isn’t skating towards where the puck is, it’s skating towards where the puck is stored after the match and the ice has been floored over for a rock concert. Statistically, people don’t use blogs to express themselves online anymore. Telling normal people that you still blog will give a similar reaction as if you’d said you build your own keyboards or are a competitive fish breeder. Worthwhile hobbies, sure, but not that impactful to wider society.
The real reason behind all of this is that most users don’t want to pay for software at all, and the ones that do want to own it, but companies only want to offer you software tied to their servers so they get control over which version you’re running, and the reduced support burden that comes with it, as well as recurring income from paying customers, as well as the ability to monetise the “free” customers via ads and surveillance and selling data. Governments everywhere are doing everything they can to support this model and suppress others, because they see it as a lever for general surveillance as well as the ability to write arbitrary rules like “right to be forgotten” and have them applied by companies with weaknesses rather than trying to enforce them on users’ hardware.
So software like HoTMetaL and Frontpage and Dreamweaver have all gone away. Too hard to support, too hard to secure against piracy, too hard to update, compared to the tiny number of pay-up-front users. So it’s built from the ground up with the idea of being tied to a live application server running through every line of code.
is still around, although nowadays like all the other Adobe stuff subscription-based. And very much a niche, and probably very rarely used by people just doing one website.
Most of the complexity of a social network has nothing to do with the web as a platform - it has to do with the logistics of publishing anything at all online at scale and with reasonable uptime, and crucially delivering content people who want to see to people who want to see it (subject to the very real political constraints around this).
The company that runs GitHub Pages is made up of greedy clowns just as much as the company behind Wordpress is. Indeed, I avoid hosting things on GitHub Pages myself, and I would advise any skilled software engineer to avoid it as well. But many skilled software engineers do not care as much about self-sovereign computation as I do, and are happy to use GitHub pages because it’s easy, just as people use Wordpress or whatever the Wordpress hosting site is that’s involved with that linked controversy, because it’s easy. And in any case even Wordpress is still mostly used by some kind of professional web content person - the vast majority of ordinary, nontechnical people are posting their words for public consumption on major social media networks that are run by some of the most well-known companies in the world, and are an important factor in real-world-politics.
Social media networks are incredibly complicated pieces of software, and they’re mostly complicated for essential reasons rather than accidental ones. The amount of effort that would go into, for instance, replacing DNS with something easier for a nontechnical user to use is staggering. It would entail literally ripping out a core portion of the internet’s infrastructure that dates back decades.
I agree that it would be good if it were easier for nontechnical people to use computers to publish their writing in a way that didn’t require them to be dependent on a large company with a complicated web frontend. But I’m under no illusions that this is an easy problem - and treating the complexity of the web frontend as the primary thing to be worried about seems like it is greatly missing the forest for the trees.
It’s not just that it’s easy, it’s easy to leave. I host cheriot.org on GitHub Pages, for example. The source is all in a git repo. When I push to the main branch, a GitHub Action runs, builds the site, generates an artefact, and pushes it to the site.
If GitHub ever annoys me sufficiently, it would take about ten minutes to set up a server that had a post-receive hook that ran the deployment (that’s what I do for my personal University of Cambridge page, which isn’t on GitHub but uses the same tooling) and deploy it on another web server. Most of the migration time would be waiting for cached copies of the DNS record that points to the GitHub Pages servers to expire. Until that point, I’m happy for GitHub to pay for the hosting.
And this, to me, is the key thing for sovereignty: freedom from lock in.
Indeed. As long as you use a custom domain and stay clear of extra dynamic features, static hosting providers are really easy to replace.
It’s been a while, but my experience of non-technical people publishing websites is that they are perfectly capable of managing an FTP client. It’s all just files and folders. Shared hosting where you can upload files to some web space remains a straightforward service to purchase. However they aren’t going to be writing HTML, with or without an LSP. It’s the FrontPage, iWeb sort of thing that has gone out of vogue. I think we’d do better to bring that back rather than trying to get folks up to speed with static site generators intended for technical people.
I wonder why those have gone out of vogue. Is it because more people are on mobile systems and simply don’t like running such local programs anymore? Or is it the hassle of connecting over FTP (which can be rather janky, leaving you with truncated files or half-synced sites and such)? Or is it the wide availability of themes for Wordpress and co?
Or maybe it’s the extensibility - start with a simple Wordpress site, but add some plugins and you have a working web shop. Also, comments are tricky to do unless you have something dynamic running on the server. That’s a pain point of static sites, too. Although perhaps nowadays comments aren’t as important anymore because almost nobody blogs anymore.
Ironically I think it is the decline of the desktop!! If you knew how to use MS Word (and a lot of people did), then it was easy to use MS Front Page
But now MS Front Page is out of vogue, in favor of web editors, which are less rich
I thought Squarespace had a pretty rich web GUI editor though
Trivia - Joel Spolsky’s [1] first product was CityDesk, a GUI for publishing HTML, like MS Front Page
https://www.softpedia.com/get/Internet/WEB-Design/HTML-Editors/CityDesk.shtml - screenshots
Launched in 2001 - https://www.joelonsoftware.com/2001/10/12/what-does-citydesk-do/
Shutdown in 2016 - https://www.joelonsoftware.com/2016/12/09/rip-citydesk/
[1] probably better known as the co-creator of Stack Overflow now
Also, I thought there was a thing where “Gen Z” supposedly doesn’t know how to use windows/mouse/folders as much anymore, since they grew up with phones and tablets. So I am not sure you could bring back Front Page, because the UI is for people who are used to MS Word and PowerPoint and the like.
I have seen a few mobile apps for publishing web content, but it seems like they are niche (?)
This line is interesting
I think the problem is that people didn’t want to install Windows software, and also they perhaps didn’t have “one device” anymore – they had multiple devices that they wanted to publish from (work and home, etc.)
They might be more technical than you think if they can handle that.
A lot of people are technical enough to understand the concept of dragging files from one folder to the other, yes. It’s a fairly common problem to assume that all “non-technical” people are equal to the least capable person.
That was a fairly typical thing to ask office workers to do in the late 1990s
I worked with (bank) office workers in the late 90s and my coworkers were very comfortable with IBM mainframe interfaces but really intimidated by Windows.
And I also remember people with all their files on the desktop, because at least they knew where they were.
Where does this no JavaScript assumption came from? It’s completely unrelated to how the browser content is assembled/served. That is the whole point of javascript. Looks like people still get awfully confused about this in 2024.
The JavaScript would be optional for both a Wordpress-like CMS site and a static site. But let’s be real, it’s way more common for framework-heavy CMSes to inject loads of JS garbage into your site than it is for static website generators to do so.
I have not been too active in web development the last few years, but my perception is almost the opposite. Themes for static sites generators are all slick full of effects and other javascript overhead even for layout purposes.
Oh my, that’s bad. I fiddled only with a handful of static site generators and never bothered to dive into the available themes.
It probably depends a lot on the theme, but I’ve not seen much JavaScript in Jekyll themes I’ve considered using. The only places I’ve used JavaScript on a web site thing[1] was for interactive maps (via leaflet). CSS is incredibly powerful now (there’s a reason WebKit added a JIT for CSS in 2014) and pretty much everything that I would have done for UI things with JavaScript I’d now do with CSS.
[1] As opposed to a web app. I used a bunch of JavaScript in a demo to display a code editor in a browser that could push code to an Azure Function that compiled JavaScript to bytecode and used MQTT to push it to a device.
This isn’t skating towards where the puck is, it’s skating towards where the puck is stored after the match and the ice has been floored over for a rock concert. Statistically, people don’t use blogs to express themselves online anymore. Telling normal people that you still blog will give a similar reaction as if you’d said you build your own keyboards or are a competitive fish breeder. Worthwhile hobbies, sure, but not that impactful to wider society.
The real reason behind all of this is that most users don’t want to pay for software at all, and the ones that do want to own it, but companies only want to offer you software tied to their servers so they get control over which version you’re running, and the reduced support burden that comes with it, as well as recurring income from paying customers, as well as the ability to monetise the “free” customers via ads and surveillance and selling data. Governments everywhere are doing everything they can to support this model and suppress others, because they see it as a lever for general surveillance as well as the ability to write arbitrary rules like “right to be forgotten” and have them applied by companies with weaknesses rather than trying to enforce them on users’ hardware.
So software like HoTMetaL and Frontpage and Dreamweaver have all gone away. Too hard to support, too hard to secure against piracy, too hard to update, compared to the tiny number of pay-up-front users. So it’s built from the ground up with the idea of being tied to a live application server running through every line of code.
is still around, although nowadays like all the other Adobe stuff subscription-based. And very much a niche, and probably very rarely used by people just doing one website.
I’m impressed, that’s very much unlike them to have something with so few users still up and running at all. God I hate what Adobe has become.