> If you didn't know any better, you would expect almost all normal users to have [2] and professional engineers to have something like [1], but it's actually the inverse: only few professional software engineers can "afford" to have the second option as their personal website, and almost all normal users are stuck with overcomplicated solutions.
I am confused, the inverse would be that professional engineers have [2] and normal users have [1]. But then they write that almost no professional engineer can "afford" [2], so everybody seems to have [1]..?
If you continue reading, the reasoning is given in the next sentence:
> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps.
I suppose they meant that only a few people, who are professional software engineers, can afford the second option.
It is indeed written as you say; I suspect - but cannot confirm - that the author meant:
> ... only a few people - professional software engineers - can "afford" ...
which would be the inverse.
However, there is a case for reading as it is written even if it subverts reading expectations, as many (most?) professional software engineers do use COTS systems to publish and only a few have their own sites generated from scratch.
Yes. That is confusingly phrased. Took me a sec too.
Most people's expectations of what a "basic website" should do have gone way up over time.
Even as a programmer, I've fallen into the static site generator trap a few times.
It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.
Nowadays, if I want a static site I just start with a folder of html files. It's way less complicated and quicker to go from idea -> execution without bike-shedding or procrastination on tools.
I'm pretty happy writing html and css manually though—I don't recommend it for everyone.
The other cool thing is if I then decide to "abort" to rails.. I can copy the folder of html files into the rails public/ folder.. pretty easy upgrade path.
I've been posting to my personal website for 20+ years and it's been something like: basic HTML -> Drupal (whew) -> Wordpress -> basic HTML (via Jekyll).
The fundamental rule I've set myself against feature-bloating in my website is defining what I want it to be: an archive of things I've done. As an archive, I want it to be very durable in time. Thus, static file that are dead-easy to copy around, mirror and make it work in any hosting platform.
It did take me a while to nail having a bilingual site, though :) but at least it's a price I paid once.
For blogging I use Hugo because it is just easier to focus on content, not on style. That is why I don't like writing pure html files. Changing style can also be a problem, if something is hardcoded into html file.
For more advanced tasks I write in django, because it so easy for me to add features.
I run a blog for an organization. We do one post per business day on average, with typically around 3 posters. I set it up years ago with Django/Wagtail/Puput and it has happily chugged along ever since. I can’t imagine how annoying it would be to manage if people were creating their own new files for every post and writing their own HTML…
But you've had to maintain that Python/Django stack, as well as a server.. Right?! I've done hundreds of Django release upgrades. They're not automatic or time-free.
Most SSGs, especially those geared to blogging accept nicer markup systems like Markdown. Keeping track of things, even in a multi-user system isn't hard.
Getting non-technical people used to a git workflow is the hardest part.
> Nowadays, if I want a static site I just start with a folder of html files.
Same here. I've considered adding a .md —> .html step for content, but just haven't found it necessary — yet.
> The other cool thing...
I like being able to—easily—view my site via a local sever. The best case would be one that I can view via file:// too, but I couldn't quite crack the organisation and ended up with a 'make local' step that generates a separate copy for file-based viewing.
> When I published SuperHTML, I discovered that it was the first ever language server for HTML that reported diagnostics to the user. I wrote a blog post about it, it got on the frontpage of Hacker News and nobody corrected me, so you know it's true.
Probably because this is something most IDEs have been doing for years, before Microsoft came up with LSP.
Of all the most popular editors, I think none of them had a way of offering diagnostics for vanilla HTML. The only exception that I know of is Webstorm.
Vim, Neovim, Helix, Zed, VSCode all shared the same basic implementation that has no diagnostics support.
Helix will have SuperHTML enabled by default starting from the next release: https://github.com/helix-editor/helix/pull/11609
I wrote IDEs not editors, and I am quite sure that the years doing ASP.NET and Java EE/Spring development I had enough HTML diagnostics to fix since 2001.
> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps
Or you could just use publii, an office suite of your choice, or type bad html and css by hand, then pass raw files on very cheap hosting providers, enjoying a clunky, and sometimes ugly, "website".
The industry for this use-case works on looks and discoverability: the dichotomy of the WP big bloated piece of crap vs static clown generators stands upon having a pretty website which is also functional for Google. Any other alternative (like the builders or the directories) works the same but they also forfeit property of the site from client. It's just because these solutions are pretty for cheap, it's fast fashion.
> Find an SSG (or handcraft everything yourself)
I think this came a bit too late? Astro solves this well, there are other solutions too. From startups building webflow-like SSG platforms to frameworks like astro that requires basic markdown and html.
The reason SSGs are primarily interesting to software developers is that the software architecture of the site is primarily interesting to software developers. Other people (both authors and readers) don't care how the pages are produced, they only care that the pages are there.
> Other people (both authors and readers) don't care how the pages are produced, they only care that the pages are there.
Readers, sure. Authors? Absolutely not true. Some authors might not be tech savvy enough to know better, but they are immensely influenced by the process of getting the content online. That's the whole reason why there's a huge industry around publishing content on the internet.
Maybe I misunderstand, but this feels misdirected. As someone who's employed by "greedy clowns" (web development agencies I guess?), I continuously observe that people pay for what saves them time. Our entire profession is built on this premise. If you have a person doing interesting things, does it really matter if they write their own HTML or pay someone else to write it?
The web is turning increasingly monolithic entirely thanks to the modern social network conglomerate. That has nothing to do with the choice of technology.
> As someone who's employed by "greedy clowns" (web development agencies I guess?)
Maybe click the link so you don't have to guess (wrong)?
Am I wrong? I did click the link. I'm just assuming that the author of this post is not explicitly referring to two particular greedy clowns, but more generally to the WordPress ecosystem. Because it's actually very easy for normal people to avoid being locked into Automattic and WP Engine in particular.
Edit: just made the connection between the domain of this post and your username. So really just wondering what you meant specifically.
Yes, static websites are great! I'm using Jekyll with GitHub - it's 100% free. I agree, though, there is a learning curve.
I'm using hugo. It's great.
> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps:
This doesn't explain the difference, why would you have to figure it out yourself is some other company could just as well sell all those services, just with an SSG?
Static sites are great until you need to have a contact form or want to add basic comments. Yes, you can deploy javascript that uses external services to add such functionality to static sites- but with a basic WordPress site, you get everything right out of the box.
A contact form is a terrible alternative to an email address. Many sites have dropped comments altogether. Yes, these things might be nice-to-haves, but they shouldn't be the factor that determines whether you have a static site or a scripted one.
I have to politely disagree. If you ever run a website for business/portfolio etc. the number of people more likely to contact you using a contact form is far greater than just telling them to email you. Contact forms also scale well if you need to categorize and channel the queries to different people or need more specific info.
Fair enough. I would argue that we're probably talking about different use cases. If you're at the stage of categorising and channelling queries to different people, your site is probably already "heavyweight" enough to justify a backend anyway.
I came here to write this exact comment. The article is wrong in assuming that WP is wasteful. It gives huge optionality to the users: engineers probably can afford going with a static page and then changing the entire architecture of their webpage once they need some interactivity, but non-engineers want to go with a scalable solution: where they start with a contact info and slowly end up with a personal shop or whatnot without reinventing the setup at each phase transition.
Speaking of optionality and opportunity costs: many engineers are trained to see the unseen opportunity costs in technology ("YAGNI" and "tech debt" are often used terms), but often fail to see the economic opportunity costs: those that would waste time and cognitive effort of human beings, not the machines. Example: many engineers like to fantasize about micropayments architectures "because efficiency", but people cannot calculate those. They are better off with a nice round monthly subscription just to minimize number of microdecisions they have to go through daily.
> normal users are stuck with a bunch of greedy clowns that make them pay for every little thing
Huh? You're not confined to Automattic or WP-Engine, there are tons and tons of regular web hosting providers with Wordpress and a bunch of other stuff included in a standard hosting package, you can use the free Wordpress, and you can self-host. That's the whole point of Wordpress being open source, and it's working as intended.
There's absolutely nothing wrong with the status quo around blogging.
Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called. Which is fine too, good for you if that's what you like to do with your time! For "normies" (or SME's who just want to publish their web content and move on), there are more than enough options around.
> Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called
No? Downloading Hugo, getting a random theme and writing a few articles is pretty simple and requires no more tinkering than doing the same with a Wordpress (okay, one's actions are big buttons in a UI, the other is copy pasting commands, but in terms of effort, there's barely any difference).
I use Hugo because it's light and allows me to have a blog running for free and scale to infinity (I have at least two articles that sat high up on the front page of HN, and there was neither a hug of death nor a bill associated), with zero maintenance, while also having flexibility if I need it. I haven't even checked my score on Google's whatever and I don't care about it.
As for WordPress, none of what you described can be had for free, and it requires ongoing maintenance (updates to keep up with the crappy ecosystem).
> okay, one's actions are big buttons in a UI, the other is copy pasting commands,
The difference is that the console is scary to the average user, big buttons are not.
> Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called
It's relatively easy to reach a PageSpeed test result of 100 with WordPress by disabling one or two features and setting up a cache extension. For logged out users, WordPress with SuperCache set up is almost like a static website (except for the occasional cache eviction) because the HTML is almost directly served from the cache.
people who know how to "self-host" can do it for free or very cheap.
Otherwise WP Engine is $30 per site.
OP says it's not only lame to exploit the knowledge asymmetry in this way but also makes web lame long term because normies don't have tools to contribute effectively.
If you are don't know anything about cars but suddenly would need a one, would you go to the nearest car dealer you heard about from somewhere or immediately go to the specific resources where you can find a specific model and make you need at a better price?
You can then move it out of the dealer’s parking spot if you find a place cheaper.
> Whenever we fail to make simple things easy in software engineering
Mandatory Rich Hickey "Simple Made Easy" link => https://youtu.be/SxdOUGdseq4?si=IY8mWzR3C-ru5Das
"This keynote was given at Strange Loop 2011, and is perhaps the best known and most highly regarded of Rich's many excellent talks, ushering in a new way to think about the problems of software design and the constant fight against complexity."
I agree: I've tempted the all-from-scratch way in pure html for my small web corner and well, I give up, it's simply too long to craft a modern website on basic html. I've tried an RSS-only corner but obviously it's not visible, ending up in Hugo/org-mode simply because it's ready made even if needlessly complicated.
The Hacker News site is (a) "static" or (b) "complex"?
A case of irony?
Strongly agree. Wordpress brags as powering whatever % of the internet... but if youve ever taken a look at some of that PHP source code... yikes
Mind boggling to me such an overly complex system has such a large market share.
I'll take my Gatsby TypeScript React components / <<insert your favorite static site generator here>> any day
There is still not a censuses as to the definition of a static website. Is a website without a MYSQL database still static if it has JavaScript or php template include files? A pure static website in which each page has to be manually edited would be a headache.
IME, the closest definition is simply a site containing flat files only. No server-side scripting, but client-side JavaScript very much allowed. That doesn't necessarily mean 'manually editing' each page, although some writing probably has to be done at some point, unless you're outsourcing that to an LLM...
What about fully client-rendered templates/sites that require JS for visualization? (ie, no graceful degradation at all).
Technically static, but absolutely of the worst kind in my opinion.
I totally agree — technically static, but an abomination that should be avoided at all costs!
An abominable default, sadly.
Here's me waffling about this question for about four paragraphs, copied below for your reading pleasure :p :) (source: https://www.evalapply.org/posts/shite-the-static-sites-from-... )
> What is a static website?
> Static simply means as-is. Its inverse is "dynamic", meaning in-transit. The "static" part of "static website" corresponds to stored information. The "website" part corresponds to where from and how, the information gets to one's computer. A web-site is literally a place (site) on the World Wide Web, whence our computer has to fetch the information we want.
> Fetching information, such as a web page, over the Internet is "dynamic" by definition. Even just opening a file on your own computer's disk is "dynamic". The very act of reading a digital file, and/or transmitting it, means copying its bits from one place and showing them in another place 3.
> The Ultimate Static Site, is a file that once written never changes. Thus, once-received we never have to fetch it again (unless we lose it). Reality is of course not so simple. But we will work with the "static means never changing" mental model, because we can go pretty far with just that.
IMO, the pages can be compiled statically on a static website, so the HTML doesn't need to be manually edited for each page. But yeah, I guess there are degrees of staticness. My (brand new) personal website is literally all written from scratch right now, but soon it will probably be pregenerated from Markdown sources. I would still call that static, but to a lesser degree.
Surely a static web site is one that could be downloaded with something like wget or curl and would still work by browsing the files directly from the file system without needing an actual web server?
Thats what I expect a static site to be too. Along with preferably as little js as reasonable.
Static website serves you everything you need as a one HTML file. You can save the source code and open it offline and there will be no difference.
As such any templating is out of the question if that is done via request from the client.
How I manage my static website is with a build script. I write my content in markdown with a option for custom header and then I have a python script that churns out pure HTML with everything embedded into it which I can then host on github pages.
This, but without the "one HTML file" restriction. Unless I misunderstood you—did you just mean "one HTML file per URL"?
I would say a static website is just one that doesn't do any extra work on the client to generate the content. Either SSR or just plain HTML files
The trouble is defining what "the content" means. Are you saying "no JS" — if so, just say so! Otherwise, how are you distinguishing between "content" and ... "other stuff"?
What?
A static website is a website that has no server side generation. That's how simple it is.
This is the first time I've ever heard of somebody being confused about this. If the server is serving dynamically generated documents, then it isn't static. A static website can be perfectly represented as a directory of files being served by python -m http.server. No PHP templates, that should be obvious.
I agree with you; not even SSI.
> There is still not a censuses as to the definition of a static website
Static website can be served by `cat index.html`
> Static website can be served by `cat index.html`
For sure, but that's not a sufficient definition. You need to add some constraints to the contents of the html. Otherwise, you can put a huge javascript program in there that hallucinates a new page each time you render it. This shouldn't count as "static".
> This shouldn't count as "static".
Why not? If it doesn't, where do you draw the line, apart from "absolutely no javascript at all"?
That's a good line to draw!
Static = no scripting (either server-side or client-side)
I'd like to reserve the term "no scripting" for that :) I guess if we popularise the term "no backend", the two could co-exist. I want to talk about sites that are just a collection of flat files, with no server-side processing; for me, "static" does that job perfectly.
Great article.
> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself?
> Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.
Exactly right.