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...
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?
> 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.
> 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".
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.
It generally does count as static though. In this context static has a technical meaning, not the dictionary definition. It's static from the server side, meaning that you don't need any special logic to serve it.
That is static though. It may not conform to a particular notion of aesthetic purity, but a website is static if and only if you can serve it from a static file server. Client-side scripting is orthogonal to that.
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"?
A dynamic website is generated by the server in response to client queries. Static websites—pre-existing flat html files served as-is to viewers—came first, then PHP and CGI made dynamic websites possible & popular. SSR is the very definition of a dynamic website. Client-side scripting came after dynamic websites, but it is not technically, in and of itself, "dynamic."
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 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.
Good question, with answers ranging from "a bunch of hand-edited HTML files" to "a set of HTML files generated from a non-HTML syntax such as a markdown derivative or a programming language's object-literal syntax", with the latter (static site generators) being quite different from the former.
And then there's also SGML which has everything HTML, as a last-mile markup language for delivery to browsers, assumed to have available for authors, such as text macros and shared fragments for eg. menus, auto-generating document outlines for page navigation, processing markdown into HTML, filtering into RSS or SERPs, etc., and even moderately complex dynamic site features such as integrating external/syndicated content and screening/validating user comments for malicious or other undesired input such as script, broken comments, external/spam links, and the like.
> There is still not a censuses as to the definition of a static website.
No server side scripting. OK to have client side scripting (e.g. JS). Basically, how things ran back in the 90's for most people who couldn't afford ASP or a paid web host.
> 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.
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?
> 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).
I think you should reexamine the Hugo getting started workflow. I think it is pretty scary for a non tech literate person. Even as a programmer, I thought the initial bootstrap to getting a theme in place is clunky. Should come with an out of the box template that lets someone immediately bang out content.
I could guide Mom how to connect to a Wordpress host. I could not say the same for Hugo.
> 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
This is not even remotely true. There are more hosts than I can count offering one click wordpress installs that dump you straight into a point where you can begin publishing.
> (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).
For the average non-engineering background user, this is a huge difference.
I've spent most of my IT career in hosting. You are vasltly overestimating the capabilities or care factor of a significant chunk of the user market.
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.
> 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.
> 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.
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.
Yeah, I’ve found Astro to be the perfect solution without compromise. You can have a 100% static site without JS, and you can add in JS only as needed.
It doesn’t feel heavyweight like similar/older SSGs doc and it lets you write TSX-like syntax for reusable components (which I really like).
> 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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
Yes, it depends on the target audience. For a personal website which the article was about, it would probably be fine for most hacker news users. If someone can’t manage to send me a mail, they probably wouldn’t see my website anyways. If you do your grandparents personal website, a proper form with a backend is better though.
Maybe you just haven't found the right static site generator for your needs?
Jekyll is the most well known in Ruby space, but it's tailored to a specific niche - authoring a blog with Markdown or another lightweight markup language. You can certainly massage it into doing other things, but it's not that ergonomic as a general purpose static site generator.
If you want something that's easy to copy/paste into rails, a rack based static site generator like middleman is great because you can start writing with erb/haml and ActiveSupport from the very beginning.
If you're looking for the simplicity of handwriting HTML and CSS but you want some niceties like includes, partial templates, link helpers, nanoc is a good static site generator that's progressive. Start with plain HTML/CSS, only add additional features as you need them.
> 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.
Hard to discuss without examples. I started using Pelican over a decade ago, and am still happy with it. Every once in a while I write code to customize the behavior, but it's once every few years. It's simple and just works.
There are things I miss from dynamic sites, but I don't see how a simple folder of HTML files is in any way superior to Pelican...
How are you handling commonality between pages with plain html pages? As long as you don’t use iframes, you have to manually sync everything that’s shared or almost the same on alle pages (header, footer, navigation). That’s pretty annoying.
Yeah nah, for me it's exactly that: plain html/js/css files. For simple things, I copy/paste.. not a big deal.
If it's getting more complicated, I'll abort and upgrade to rails to use layouts etc.
The middle ground of static site generators are a trap in my personal opinion.
If I need to add a feature, I've found it's easier for me to implement it directly rather than try mess around configuring a static site generator with plugins etc.
> Nowadays, if I want a static site I just start with a folder of html files.
? With that argument, we can also calculate 10 million digits of pi in HTMl by renaming our C files to .html. If someone tells me they’re using a collection of html files, I’m assuming they mean static html pages without server side scripting.
Amusing how underneath this comment, there are several comments saying "ah, you just haven't found the right SSG, this one is good". Well-intentioned, but completely missing the point.
I've been doing this too, but as a Python expert who always meant to learn Ruby but never really got around to it, I hate having to wrap my head around the suite of Ruby development tools (Bundler and the Gem system etc.) to do local builds, and it's currently taking up a seemingly absurd amount of disk space when this is the only reason I have any of it installed. Considering switching over to Nikola soon so that I can just use Python in the ways I'm familiar with.
> 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.
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.
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.
Technical purity does not win business. Solutions do. WP has delivered a rich ecosystem that lets normal people put content on the web. Even if it annoys programmers at its technical debt.
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.
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.
Wouldn't a blog be generally simpler and, thus, generally comparatively a better candidate for a "static" site than "a social network application"?
The Hacker News pages are "static" -- correct?
For my startup's Web site, I wrote the code in ASP.NET and made the site "static" before I heard about "static": So, "static" is okay with me for what I did write. When I finally (whew!!) go live, I hope the candidate users will not mind, or even notice, that the site is "static" and not single page. Today, do nearly all users expect a "single page" site and not like "static"?
Last time I checked, my pages send for ~44KB per page, and I'd guess that that is comparatively small?
If only as a user, a single page site can be amazing, subtle, surpising, not really intuitive or obvious, but by now there may be millions of such sites with significant differences between any two, thus, requiring users, by try it and find out, to learn how to use the site. In contrast, a static site seems to stand on a history of computer interaction, e.g., with the standard controls -- text boxes, check boxes, radio buttons, links -- that go back to some IBM work for the airline industry and the 3270 terminals and that by now maybe 3 billion people understand immediately, and if so then that can be an advantage.
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.
"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."
> 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.
> 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".
WordPress folks are working to enable static generation using WordPress Playground. It will work pretty much like Publii does today.
It's a good starting point. Quite late at the game after strattic, cache plugins and offloading queries on sqlite, let's see when and how will they play out with unavoidable interaction parts like contact forms.
I would never recommend someone making their first site use a static site generator or anything PHP or dynamic like that. Just make a simple html document in a wysiwyg editor and upload it to the server.
> 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.
I think the better word for this is "straightforward"; see the Mythical Man Month:
> For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice.
> Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.
In 2016, I was working at an agency making brochureware for local businesses. I remember one of our clients wanted us to add a small iframe for a reservation system to their website they had built. They sent us a single word document. Turns out they were just exporting it as HTML (which it seems like Word does still support today!) and throwing it onto some cheap shared web hosting provider. It worked great for them. They could always keep their online menu updated because... it was exported from the word doc they create the print menu from. At the time we sort of made fun of them internally... which I feel bad thinking about now. It's actually a genius idea when you have a million other more important things to do at a restaurant.
It's still easier to make a static site. I think the authoring tools to generate HTML just currently suck, or if they don't suck they have some process that needs to run on the server to serve the site.
I mean, isn't the whole idea of a web browser kind of contrary to the ideals of the web? It implicitly divides people into speakers and listeners.
In a parallel universe, web browsers are called webitors, and they can edit websites as well as view them. People can suggest changes. People can publish annotations. Web hosting is like email--pick (or build) any service you like and pick (or build) any client you like. The protocols will sort it out.
Under the hood, the bones of that system are there! `PATCH` is a HTTP verb for a reason.
Though making the web this big publicly editable pile of documents would create a lot of spam. You already have to filter a lot if you have a form on a website, imagine if instead of filtering structured data, you had to filter diffs.
I think maybe a good half measure is just bringing web authoring tools BACK to web browsers! Netscape Navigator had one if I remember correctly. This would just allow you to write HTML files to disk though.
Bonus point for some standard protocol where you login with HTTP Basic Auth, and POST/PUT/PATCH/DELETE HTML directly to a page. You'd need some special server that understands that, but ideally it would be open for anyone to implement. You point your browser to https://yoursite.com/my/page.html and assuming you've logged in with HTTP Basic Auth, your browser suggests creating the page, rather than rendering the responded error page.
Edit: Protocol is the wrong word, someone correct me what this is really called. HTTP based... editing? A standard API? It's now something I want to make so I'll need to figure that out haha.
Edit 2: CamperBob2 in a sibling comment mentioned wikis. Just realized I'm describing a wiki lol
There was an effort many years ago to provide browser extensions that allowed users to mark up, edit, and annotate existing web pages in a way that would be visible to the community of users. It never went anywhere, unfortunately, probably because it would have gored way too many sacred oxen. (And/or it would have been co-opted by spammers, turning it into a social networking/reputation management project.)
Every so often someone announces that they've reinvented that idea but it doesn't go anywhere. These days the problem is probably mostly mobile Internet, but also the sheer difficulty bootstrapping enough of a community for it to be worthwhile.
And of course any such project that became popular would either ruin the creators as they try to keep up with moderation, or devolve into an unusable mess if they don't moderate.
What you describe came and went, subsumed under the homogenizing effect of silos like Facebook. Mashups were the big new thing. There have been various attempts to bring it back, but the inertia of silos makes it hard to find anyone interested.
Back in the day mozilla (the browser, before the mozilla org made firefox) edited html in a wysiwyg fashion. All my early websites were made with it. I never did work out how to remove a <br>
I love when businesses do stuff like this. If it works, it works.
My job isn't to ridicule them because it could be better, but make their solution better and ensure my solution for them works as well as theirs, if not better, without hampering the success they already had with what they were doing already.
A lot of developers don't want to admit this—in my experience at least—but tons of these ad-hoc web solutions actually work better than a ton of strategies experienced web developers would implement on their own.
So much of what counts is what the business offers and how they relate and interact with customers. Sometimes all that takes is a word doc exported to HTML. We can use our skills to improve it, but the real magic is in the humans running the business. I love it.
I find something fun is that finding ways to improve these solutions can actually be genuinely challenging. Sure, you can make a better website, you can deploy it with sophisticated infrastructure, etc. but at the end of the day, do their customers prefer it? Does it improve their business? Sometimes that part isn't trivial at all.
Totally! The magic of using your print menu word doc as the website is its so little work to keep the site updated. No one really cares that a family restaurant in a Toronto suburb has a visually stunning website. You just want to see the menu, hours, address and phone number. It's always going to be updated, exactly the same content as the print menu that you actually pay from, and they already knew how to make things look legible in word.
It's actually even more charming than any solution we ended up providing because this particular restaurant (sadly closed now) was run by a 60-70ish year old man, who's cropped portrait photo was their logo, `float:left` in the header of their index.html exported from Word. I don't think you can buy authenticity like that.
I of course thought that was hilarious because I was 19, an idiot, with my first tech job thinking I'm such a professional cranking out CodeIgniter-based contact forms and static About Us pages.
Looking back, I'm pretty sure we did them dirty. Whatever solution we sold them on (IIRC, they got a wordpress site with a custom theme) was probably less useful. Which sucks.
I've been volunteering with a local political party to help them with their technology decisions, primarily on the web, and... based on this and prior experiences, I've come to the conclusion that agencies do their clients dirty quite often. In some cases it looks borderline intentional, in others I think it's a disconnect between client needs, agency capabilities, communication, and what's ultimately delivered.
It seems weird to say it since so many people rely on it, but wordpress is overkill for so many things. It frustrates so many clients to no end, requires ongoing maintenance that's quite expensive in some cases, and well, it requires an active server handling server-rendering and form submissions and such. The vast majority of clients simply don't need it. They don't even need themes.
This party I'm helping has something like 7 wordpress sites strewn about, all on hosts that cost way too much, some not even updated or maintained at all, sitting on servers that peak at like 40% utilization and otherwise hum along at near-zero utilization beyond what the wordpress isntance requires.
This is a lot of the internet. My experience with these folks has inspired me to build something that would meet their needs, but it's one of these things where... I don't know, if I build it, I doubt anyone would come. But yeah. Most people's needs for the internet are remarkably simple. Even Wix or similar are way, way too much. Yet those basic blogging engines totally miss the mark too. Most of these business users aren't interesting in blogging. They just want a simple home base where they can dump various types of information and let it hang out forever.
I can think of a few products which aim to fix this, but they aren't quite simple enough for the types of people we're describing. The people who know they need stuff online, but don't want to know much about it and don't want to learn much either.
People forget to keep track of how long it takes them to do things.
I see people bifurcated into "people good at time estimates" and "people who think time estimates are always wrong." The former have been keeping track, improved continuously, and have become good. The latter have no clue.
Setting up a website from scratch is not hard, but it is time consuming, especially when you throw in maintenance.
I do consulting for a few restaurants, and despite my experience building full-stack web applications, I find myself reaching for Excel for most of my deliverables. These are "applications" that "non-technical" restaurant operators need to be comfortable in. Having a sheet where they paste in some data and get their needed output has required the least amount of continued maintenance and training. They can drag the file around in Dropbox / Google Drive and that works for them.
I still try to "engineer" to the best of my ability—separating raw input from derived data from configuration, data normalization, etc. With Lambda functions in Excel now, I kinda just pretend I'm writing Lisp in an FRP editor / runtime environment. The ETL tools with PowerQuery are quite good for the scale that these restaurants operate at.
Hard for me to turn off my brain in my full-time job when I am tasked with poorly recreating a feature that Excel nailed years ago.
It’s a shame that Access died, because that’s what you would have built this in 25 years ago, and it would have been better for your client in every respect.
I have been cursing for a long time over the death of Frontpage. Yeah we made fun of it because the HTML it created was/is awful. But what it also was was a program that normal businesses/people could use to update a small and cheap website without having to worry about security beyond picking a good password.
I have been looking for a good alternative that can create more correct HTML and which gives you more options than Words HTML exporter for a couple years now.
There was a restaurant I went to in CDMX this summer and their menu was a public preview link to a document in Figma. I couldn't stop laughing at the fact but delighted by how well it just worked. I love this stuff.
I have tons of little single HTML file sites I make from this [Vue template](https://vue-template.spaghet.me/). I also have sites just published as public Notion docs, inline photo libraries from iCloud, etc. Its amazing how easy and available it is to just connect stuff, and how often I want to over complicate things and build something from scratch when I can just link stuff together.
On an aside I also love things like [mmm.page](https://mmm.page/) for quickly stitching together little micro sites or single use sites if I don't have time to do something else. Its fun exploring all these tools
We have a "Data App" built for one of our clients, which does all sorts of fancy stuff for managing their metadata, quality checks, etc.
But some of the pages have "documentation" which is basically a bunch of tables with dates and text, which they handle themselves. And the solution we landed on was very similar - they just have a Word doc with this table, they give it to us, we export it to html/css, and dump it into the appropriate place.
It's not elegant and not a scalable solution, but for the use cases where it's relevant, it's the easiest way, hands down.
Germany’s entire humanitarian response to the Russian invasion of Ukraine worked like this before the official authorities could catch up, a few days to a few weeks later. Notion, Telegram, WhatsApp and Google Docs saved the day. This awed me at the time and still awes me now. Quietly, we have achieved the dream of bringing computing to everyone.
> 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.
Big up this author. Here’s a recent podcast about the recent conference this quote came from (Squiggle Conf), https://changelog.com/jsparty/339
If you like WordPress and want to use it to create a static site, you can.
1. Run a local installation of WordPress on your PC. For one option, see localwp.com (no affiliation).
2. Use WordPress to design whatever website you want, using almost any WordPress plugins you want. Just don't make any calls for time-varying external resources!
3. Use one of the WordPress plugins for exporting a WordPress site as a static site, i.e. as a folder of files that you can upload to GitHub Pages, Netlify, Neocities, or wherever. For one option, see simplystatic.com (no affiliation).
There is no paradox at all: simplicity is beautiful but complexity sells. The author thinks that value come from realized utility. However, in most market segments, value came from perception. With complexity (even useless ones), you can boost perceived value. How do you impress people when all the greatness is under the hood?
I use several SSGs and wrote one myself. I still can't recommend any SSG to people willing to pay.
> The author thinks that value come from realized utility.
For the majority of the world, Wordpress indeed does provide more utility than an SSG. Wordpress is famous for their 5 minute installs, and then everything just works.
Also, the article is about fully managed Wordpress vs self-hosted (or PaaS hosted) SSG. If the choice is between self-hosted Wordpress vs self-hosted SSG, I bet the outcome will be very different.
Now, you may wonder why the OP was not make an apple to apple comparison, like fully managed Wordpress vs fully managed SSG. Well, fully managed SSG does not exists, because it won't sell!
The killer app of WordPress is comments. No SSG, almost by definition, allows comments; WordPress blogs almost always come with them built in.
If you want something like Hugo to really take off in the blogging sphere, all you need to do is create some good looking themes with comments. Figure that out at scale - maybe by using per-blog sharded SQLite, which you can host as a third party for pennies on the dollar - and you have a tiny golden goose on your hands.
I think that was true during the age of the blog, but far less so now.
Comments and discussion of a post are to be found on third-party communities like Reddit, HN, or even Facebook. How many of us scan the list of comments under, say, a Substack post vs. will scroll through a page or two of HN comments for the same post?
IMO it's a foregone conclusion that a discussion on HN will be higher quality for a tech-related post than a comment chain on a specific post, since HN has already attracted a wider set of readers than 99.9% of all blogs.
The main advantage of commenting directly on a blog post is that the author is far more likely to see it vs. the ephemeral state of the post being on the HN front-page.
The more people join a social media site the worse the conversation gets.
This is already happening to HN as tech people flee Reddit.
Most of the new comments on any given post are people that didn't read the linked content and complain about stuff addressed in the second paragraph.
This is an evolutionary process where the commenters that get the most engagement are those that are first to respond or react. First-mover advantage entrenches itself as those posts are boosted higher due to the engagement they receive.
Those that think deeply before responding are discouraged when a well-thought out comment is buried beneath a sea of first impressions.
This reward cycle is amplified by more people, because engagement is very unequal on platforms that share a top comment or front page for everyone. You either make it to the first few comments or get nothing at all.
Sites like Discord or Facebook try to counteract the monopolization of engagement by an impulsive few by splitting users into smaller groups. Less competition for social interaction creates more diversity in winning strategies. Evolutionary pressures still exist, but you don't need to perfect a "winning strategy" solely to interact with other people on the platform.
Contrast Reddit or YouTube videos. The concentration of attention means it has monetary value due to SEO, product reviews, or advertising. The value of a large audience makes a platform more competitive. Competitiveness means many YouTubers and Redditors professionalize attention-seeking behaviour. This comes at the cost of quality.
Most of the new comments on any given post are people that didn't read the linked content and complain about stuff addressed in the second paragraph.
Almost everyone does that since I’m here and that is at least for 10 years. We even have a thread about it from time to time. HN is absolutely fine and didn’t change that much cause it disincentivizes attention seeking, at least cheap one. They may slip in from time to time but mostly get a cold shower from users and mods. Also this forum is much more tricky than it seems, from a technical standpoint.
Yes but that's okay at a smaller scale where all the users are more aligned and there's less karma to get. HN now is big enough that gaming the karma system by commenting quickly with rage or nostalgia bait is a winning strategy and for most general appeal topics on the site these days that's exactly what happens.
Part of that may be you learned to detect these behaviors and not always correctly. Another part may be old commenters getting nostalgic and/or angry (a thing in life).
Did my homework though and checked top ten threads and their first comments where all these karma people should be. All top comments are pretty HN spirited. One of these may be called nostalgic but has a specific request in it and doesn’t look like a bait.
Yeah these things are all pretty relative of the reader's perspective. FWIW I mean this specifically for the less technical threads. Technical threads still seem to rank contributions appropriately. But the moment you touch on something more cultural, like the long term computer thread, or the Mr Beast thread from the other day, you get a lot of pretty low signal comments that get a lot of karma. I do find that the very top of the comments page stays okay but the moment you get past the very top you get lots of low effort comments.
> Those that think deeply before responding are discouraged when a well-thought out comment is buried beneath a sea of first impressions.
A specific capability oh HN, that I take advantage of often, is being able to skip thread branches. It’s not uncommon for me to go a few messages, think “Nah”, tap “root”, then “next”, and, boom, a 100 first impressions vanish in a click of disinterest.
It’s a really great feature and can act as a crude filter for first impressions.
Exactly. Sometimes you see that a subthread goes sideways and just parent/root [-] it, and you’re back in the thread without parsing through non-interesting parts.
Grate post! Hey, check my websight about "WordPress blogs" at https://www.sevarg.net/ I think youll like it! ;)
Are you sure comments are still desirable? Isn't step 1 of the internet anymore "Never read the comments"?
That said, I did actually work out a solution for "static site with dynamic comments" on my blog that could easily be done for a lot of people if they're willing to use a hosted service. Discourse (the modern forum software that a lot of places moved to after PHPBB) has a way to integrate with pages for comments, and so I've been using that for at least three years now with no real trouble. I host my own Discourse install (I'm weird, I still have a server racked up in a datacenter), but there's no reason you couldn't pay someone else to do that and provide comments.
Interestingly, the amount of spam I've gotten with my Discourse comments is a tiny fraction the amount I got even with Blogger back when I was hosting there. It's just not a big problem anymore for me, and it was a constant annoyance with PHPBB forums and Blogger.
The rest of the site is just Jekyll, based around a template I bought (because I can't make a decent looking website). I've then hacked on it a lot over the years to make it do things I want (responsive images, mostly - I'm still sensitive to people on low bandwidth connections), but it's not bad at all in terms of maintenance. Just launch a render job and some scripts upload the new files.
>Are you sure comments are still desirable? Isn't step 1 of the internet anymore "Never read the comments"?
It very much depends on who you ask. As a reader, I always check the comments on an article. It's easily 75% of the fun of the Internet to me, more so if it's a shitshow. I can understand not everyone feels the same. I've been hearing for years from many different people how Twitter is a garbage dump, but to me it's no worse or better than any other place where people can respond to each other.
I'm looking at going static and this is literally the problem I have. Is there any out-of-the-box way (e.g. something in Javascript) to bolt comments onto a static site?
I'm also seeing a moderate number use javascript to pull activitypub replies, as those APIs are (generally) public and GET-friendly. And don't have the various spam-rolls that other free options add.
The killer app for Wordpress isn’t comments, it’s their plugin ecosystem. Everything you’d spend a weekend configuring in Hugo has a plugin in Wordpress that your mom could enable in two clicks.
I use Hugo myself, but the user experience is much friendlier in Wordpress even if the footprint is unnecessary from an engineering perspective.
Honestly, the last thing I want is to allow randos unfettered access to deface my personal site. Maybe it brings value to somebody somewhere, but my mental health got better when I finally turned them off for good.
Not every business site wants comments, but they'll probably want a contact form. Putting an email address out is an alternative, but handling the input pipeline is better.
On a static site that requires finding a service they trust to handle the submission and correctly plug it in their site. It becomes another moving part, potentially another bill that needs to be paid separately, another bit to deal with when the industry consolidates etc.
More often than not, the contact forms that I encounter impose one or more hassles on the visitor:
Please enable JavaScript. Please allow scripts from these off-site domains to execute on your computer. Please enter a return address hosted by an approved email provider. Please read through all the categories in this drop-down list and select the one that best fits your message. Please fill in these required fields and re-submit the form. Please unblock challenges.cloudflare.com. Please waste your time repeatedly solving annoying puzzles, until our CAPTCHA provider can sufficiently fingerprint you and your browser. Please re-type the text you already entered, because we reset some or all of the form fields due to one of the above complaints.
No thanks. If I'm at a contact page, it is most likely because I have something of value to the site owner, such as potential business or knowledge of something broken on their site. If they expect me to jump through hoops, I won't bother.
In principle, contact forms could be nice enough, just as many web sites could be clear, simple, quick-loading, static pages. In practice, they're generally a burden.
Given that they don't offer much to the visitor even in the best case,
I would rather just see an email address.
Yes! It's a plague that's hurting most generic content submissions services.
Most Saas in that area can't see the difference between a freelance portfolio site where you can send work offers and the support form of your local telecom where people will send death threats.
At the end of the day, for the lambda user it's just better to have the forms handled on the same platform as the site (wix, squarespace etc.) than dealing with a generic solution elsewhere.
> email address
On the receiving end, the advantage of the contact form is to map it to something else that email (Google Sheets etc.). Of course you can set an automated email box that will process the incoming mail into something else, but that's just an additional burden.
I gave eight examples (which themselves are an incomplete list). Nitpicking at two of them while ignoring the rest, and projecting fault onto people who experience them, doesn't refute the overall point.
For instance it means leaving the browser and have the default email client handling it. For some people it becomes a distraction, for other they didn't even setup the default client so it's a setup screen and hey have to copy/paste the email to their gmail tab.
Other people actually don't want to give their email but will give a phone number, or their Twitter handle, a chat ID, or their address, or anything else really.
A form is more maintenance, but can be pretty beneficial to address a general public.
People who contact your business by e-mail or contact form are immensely much better customers than people who contact through a chat message or such. As a business you want to deal with e-mail customers and not WhatsApp/Messenger people, because 9 times out of 10, the chat people want an answer to a question and won't even say thanks after getting the answer and of course will never become actual customers.
This may blow your mind but you can have static pages AND a dynamic endpoint for form submission. You could even put such endpoints under a common directory, /cgi-bin/ perhaps.
So Hacker News and "real programmers" continually underestimate the foundational concept of a CMS. They consider it to be unsexy tech and therefore all problems around it must be solved and boring problems, and therefore they aren't actually aware of what any of those problems are.
The WordPress ecosystem is of course the polar opposite of this, it's populated by billions of dollars worth of businesses that understand intimately what the people operating CMSes and websites in their little niche of that market need, the size of this market is 500 million websites or so.
I'm sure the guy who wrote this article is a smart guy. But he is obviously not smart about the practical uses of a CMS if his worldview is "static HTML sites are better but aren't popular because of evil corporations." You really only need to get paid to build a website once or twice to realize that a static HTML site generator is almost never going to do everything that your customer wants it to do. WordPress realized how vast and varied this market is many years ago and that's why they implemented support for plugins.
You're 100% right comments is like the original use case for having something more like a CMS on the web instead of a static site generator. But there are also a million others.
You just don't get that far with static HTML documents. As soon as you move beyond some minimalist developer's blog you need programmatic logic, and lots of it, to do everything the actual users and customers want you to do. So you use a CMS, whatever CMS fits your needs. And you cache aggressively if you want that site to stand up under a lot of traffic, that's part of the job.
For the life of me, I will never understand why all these devs who think they're so shit-hot want to reinvent the wheel instead of just learn a bit about how caching works, and employ it! Is it another one of those solved problems that's too boring for them?
100% of small businesses who currently use WordPress are better served by an embedded iframe when they need something more advanced than static.
Have a restaurant and want to offer take-away online? That's going to be an embedded iframe.
Have a small hotel and want to let guests book their rooms online? That's going to be an iframe from Sirvoy, or a horribly bad Wordpress plugin.
Have a dentist office, or you're some kind of freelance consultant and want to let people book and pay times? That's going to be an iframe.
Have an actual blog that is popular and want to make a paywall so that only paying subscribers can read? This is where WordPress will shine right? Go and buy such a plugin for $200-$300 and later tell me how your experience was. Even for this basic blog functionality WordPress is a horrible mess.
369 comments
[ 3.8 ms ] story [ 249 ms ] threadTechnically static, but absolutely of the worst kind in my opinion.
> 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.
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".
Why not? If it doesn't, where do you draw the line, apart from "absolutely no javascript at all"?
Static = no scripting (either server-side or client-side)
A static website is a website that has no server side generation. That's how simple it is.
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.
And then there's also SGML which has everything HTML, as a last-mile markup language for delivery to browsers, assumed to have available for authors, such as text macros and shared fragments for eg. menus, auto-generating document outlines for page navigation, processing markdown into HTML, filtering into RSS or SERPs, etc., and even moderately complex dynamic site features such as integrating external/syndicated content and screening/validating user comments for malicious or other undesired input such as script, broken comments, external/spam links, and the like.
> A pure static website in which each page has to be manually edited would be a headache.
There are static site generators for a reason.
No server side scripting. OK to have client side scripting (e.g. JS). Basically, how things ran back in the 90's for most people who couldn't afford ASP or a paid web host.
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.
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).
The difference is that the console is scary to the average user, big buttons are not.
I could guide Mom how to connect to a Wordpress host. I could not say the same for Hugo.
This is not even remotely true. There are more hosts than I can count offering one click wordpress installs that dump you straight into a point where you can begin publishing.
> (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).
For the average non-engineering background user, this is a huge difference.
I've spent most of my IT career in hosting. You are vasltly overestimating the capabilities or care factor of a significant chunk of the user market.
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.
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.
> 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.
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.
It doesn’t feel heavyweight like similar/older SSGs doc and it lets you write TSX-like syntax for reusable components (which I really like).
Probably because this is something most IDEs have been doing for years, before Microsoft came up with LSP.
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 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]..?
> 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.
> ... 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.
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.
For more advanced tasks I write in django, because it so easy for me to add features.
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.
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.
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.
<form action="mailto:someone@example.com" enctype="text/plain">
It's a terrible user experience.
Jekyll is the most well known in Ruby space, but it's tailored to a specific niche - authoring a blog with Markdown or another lightweight markup language. You can certainly massage it into doing other things, but it's not that ergonomic as a general purpose static site generator.
If you want something that's easy to copy/paste into rails, a rack based static site generator like middleman is great because you can start writing with erb/haml and ActiveSupport from the very beginning.
If you're looking for the simplicity of handwriting HTML and CSS but you want some niceties like includes, partial templates, link helpers, nanoc is a good static site generator that's progressive. Start with plain HTML/CSS, only add additional features as you need them.
> 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.
Hard to discuss without examples. I started using Pelican over a decade ago, and am still happy with it. Every once in a while I write code to customize the behavior, but it's once every few years. It's simple and just works.
There are things I miss from dynamic sites, but I don't see how a simple folder of HTML files is in any way superior to Pelican...
If it's getting more complicated, I'll abort and upgrade to rails to use layouts etc.
The middle ground of static site generators are a trap in my personal opinion.
If I need to add a feature, I've found it's easier for me to implement it directly rather than try mess around configuring a static site generator with plugins etc.
I have a simple web component that lets me do `<include-file remote-src='...'>`.
That's basically 90% of what a more complex solution will give you.
> Nowadays, if I want a static site I just start with a folder of html files.
? With that argument, we can also calculate 10 million digits of pi in HTMl by renaming our C files to .html. If someone tells me they’re using a collection of html files, I’m assuming they mean static html pages without server side scripting.
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?
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.
Netlify event has a built in workflow where they will record the action so you do not have to setup any infrastructure.
And many still have. I think most wordpress.com and blogger blogs have comments on
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
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.
The web is turning increasingly monolithic entirely thanks to the modern social network conglomerate. That has nothing to do with the choice of technology.
Maybe click the link so you don't have to guess (wrong)?
Edit: just made the connection between the domain of this post and your username. So really just wondering what you meant specifically.
A case of irony?
The Hacker News pages are "static" -- correct?
For my startup's Web site, I wrote the code in ASP.NET and made the site "static" before I heard about "static": So, "static" is okay with me for what I did write. When I finally (whew!!) go live, I hope the candidate users will not mind, or even notice, that the site is "static" and not single page. Today, do nearly all users expect a "single page" site and not like "static"?
Last time I checked, my pages send for ~44KB per page, and I'd guess that that is comparatively small?
If only as a user, a single page site can be amazing, subtle, surpising, not really intuitive or obvious, but by now there may be millions of such sites with significant differences between any two, thus, requiring users, by try it and find out, to learn how to use the site. In contrast, a static site seems to stand on a history of computer interaction, e.g., with the standard controls -- text boxes, check boxes, radio buttons, links -- that go back to some IBM work for the airline industry and the 3270 terminals and that by now maybe 3 billion people understand immediately, and if so then that can be an advantage.
No. They are inherently dynamic. They are generated by user-submitted content at real time.
On the article's categorization, it would make HN a complex site. But the categorization does not apply here.
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."
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.
WordPress folks are working to enable static generation using WordPress Playground. It will work pretty much like Publii does today.
https://github.com/WordPress/wordpress-playground/issues/707
I think the better word for this is "straightforward"; see the Mythical Man Month:
> For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice.
> Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.
It's still easier to make a static site. I think the authoring tools to generate HTML just currently suck, or if they don't suck they have some process that needs to run on the server to serve the site.
In a parallel universe, web browsers are called webitors, and they can edit websites as well as view them. People can suggest changes. People can publish annotations. Web hosting is like email--pick (or build) any service you like and pick (or build) any client you like. The protocols will sort it out.
Though making the web this big publicly editable pile of documents would create a lot of spam. You already have to filter a lot if you have a form on a website, imagine if instead of filtering structured data, you had to filter diffs.
I think maybe a good half measure is just bringing web authoring tools BACK to web browsers! Netscape Navigator had one if I remember correctly. This would just allow you to write HTML files to disk though.
Bonus point for some standard protocol where you login with HTTP Basic Auth, and POST/PUT/PATCH/DELETE HTML directly to a page. You'd need some special server that understands that, but ideally it would be open for anyone to implement. You point your browser to https://yoursite.com/my/page.html and assuming you've logged in with HTTP Basic Auth, your browser suggests creating the page, rather than rendering the responded error page.
Edit: Protocol is the wrong word, someone correct me what this is really called. HTTP based... editing? A standard API? It's now something I want to make so I'll need to figure that out haha.
Edit 2: CamperBob2 in a sibling comment mentioned wikis. Just realized I'm describing a wiki lol
There was an effort many years ago to provide browser extensions that allowed users to mark up, edit, and annotate existing web pages in a way that would be visible to the community of users. It never went anywhere, unfortunately, probably because it would have gored way too many sacred oxen. (And/or it would have been co-opted by spammers, turning it into a social networking/reputation management project.)
And of course any such project that became popular would either ruin the creators as they try to keep up with moderation, or devolve into an unusable mess if they don't moderate.
https://en.wikipedia.org/wiki/User_agent
What you describe came and went, subsumed under the homogenizing effect of silos like Facebook. Mashups were the big new thing. There have been various attempts to bring it back, but the inertia of silos makes it hard to find anyone interested.
Nowadays it's more important than ever to curate content well.
The job of the browser is to _render_. That's agnostic on whether you're creating content or just reading it.
Doesn't produce particularly modern HTML, but if you want to author HTML like it's 1999, it's out there.
My job isn't to ridicule them because it could be better, but make their solution better and ensure my solution for them works as well as theirs, if not better, without hampering the success they already had with what they were doing already.
A lot of developers don't want to admit this—in my experience at least—but tons of these ad-hoc web solutions actually work better than a ton of strategies experienced web developers would implement on their own.
So much of what counts is what the business offers and how they relate and interact with customers. Sometimes all that takes is a word doc exported to HTML. We can use our skills to improve it, but the real magic is in the humans running the business. I love it.
I find something fun is that finding ways to improve these solutions can actually be genuinely challenging. Sure, you can make a better website, you can deploy it with sophisticated infrastructure, etc. but at the end of the day, do their customers prefer it? Does it improve their business? Sometimes that part isn't trivial at all.
It's actually even more charming than any solution we ended up providing because this particular restaurant (sadly closed now) was run by a 60-70ish year old man, who's cropped portrait photo was their logo, `float:left` in the header of their index.html exported from Word. I don't think you can buy authenticity like that.
I of course thought that was hilarious because I was 19, an idiot, with my first tech job thinking I'm such a professional cranking out CodeIgniter-based contact forms and static About Us pages.
Looking back, I'm pretty sure we did them dirty. Whatever solution we sold them on (IIRC, they got a wordpress site with a custom theme) was probably less useful. Which sucks.
It seems weird to say it since so many people rely on it, but wordpress is overkill for so many things. It frustrates so many clients to no end, requires ongoing maintenance that's quite expensive in some cases, and well, it requires an active server handling server-rendering and form submissions and such. The vast majority of clients simply don't need it. They don't even need themes.
This party I'm helping has something like 7 wordpress sites strewn about, all on hosts that cost way too much, some not even updated or maintained at all, sitting on servers that peak at like 40% utilization and otherwise hum along at near-zero utilization beyond what the wordpress isntance requires.
This is a lot of the internet. My experience with these folks has inspired me to build something that would meet their needs, but it's one of these things where... I don't know, if I build it, I doubt anyone would come. But yeah. Most people's needs for the internet are remarkably simple. Even Wix or similar are way, way too much. Yet those basic blogging engines totally miss the mark too. Most of these business users aren't interesting in blogging. They just want a simple home base where they can dump various types of information and let it hang out forever.
I can think of a few products which aim to fix this, but they aren't quite simple enough for the types of people we're describing. The people who know they need stuff online, but don't want to know much about it and don't want to learn much either.
I see people bifurcated into "people good at time estimates" and "people who think time estimates are always wrong." The former have been keeping track, improved continuously, and have become good. The latter have no clue.
Setting up a website from scratch is not hard, but it is time consuming, especially when you throw in maintenance.
I still try to "engineer" to the best of my ability—separating raw input from derived data from configuration, data normalization, etc. With Lambda functions in Excel now, I kinda just pretend I'm writing Lisp in an FRP editor / runtime environment. The ETL tools with PowerQuery are quite good for the scale that these restaurants operate at.
Hard for me to turn off my brain in my full-time job when I am tasked with poorly recreating a feature that Excel nailed years ago.
Gesundheit? It’s still in Office 365 (subscription) and Office 2024 Pro (standalone).
I have been looking for a good alternative that can create more correct HTML and which gives you more options than Words HTML exporter for a couple years now.
I have tons of little single HTML file sites I make from this [Vue template](https://vue-template.spaghet.me/). I also have sites just published as public Notion docs, inline photo libraries from iCloud, etc. Its amazing how easy and available it is to just connect stuff, and how often I want to over complicate things and build something from scratch when I can just link stuff together.
On an aside I also love things like [mmm.page](https://mmm.page/) for quickly stitching together little micro sites or single use sites if I don't have time to do something else. Its fun exploring all these tools
But some of the pages have "documentation" which is basically a bunch of tables with dates and text, which they handle themselves. And the solution we landed on was very similar - they just have a Word doc with this table, they give it to us, we export it to html/css, and dump it into the appropriate place.
It's not elegant and not a scalable solution, but for the use cases where it's relevant, it's the easiest way, hands down.
https://news.ycombinator.com/item?id=25240939
https://rakhim.org/honestly-undefined/19/
Big up this author. Here’s a recent podcast about the recent conference this quote came from (Squiggle Conf), https://changelog.com/jsparty/339
1. Run a local installation of WordPress on your PC. For one option, see localwp.com (no affiliation).
2. Use WordPress to design whatever website you want, using almost any WordPress plugins you want. Just don't make any calls for time-varying external resources!
3. Use one of the WordPress plugins for exporting a WordPress site as a static site, i.e. as a folder of files that you can upload to GitHub Pages, Netlify, Neocities, or wherever. For one option, see simplystatic.com (no affiliation).
I use several SSGs and wrote one myself. I still can't recommend any SSG to people willing to pay.
For the majority of the world, Wordpress indeed does provide more utility than an SSG. Wordpress is famous for their 5 minute installs, and then everything just works.
Also, the article is about fully managed Wordpress vs self-hosted (or PaaS hosted) SSG. If the choice is between self-hosted Wordpress vs self-hosted SSG, I bet the outcome will be very different.
Now, you may wonder why the OP was not make an apple to apple comparison, like fully managed Wordpress vs fully managed SSG. Well, fully managed SSG does not exists, because it won't sell!
If you want something like Hugo to really take off in the blogging sphere, all you need to do is create some good looking themes with comments. Figure that out at scale - maybe by using per-blog sharded SQLite, which you can host as a third party for pennies on the dollar - and you have a tiny golden goose on your hands.
Comments and discussion of a post are to be found on third-party communities like Reddit, HN, or even Facebook. How many of us scan the list of comments under, say, a Substack post vs. will scroll through a page or two of HN comments for the same post?
IMO it's a foregone conclusion that a discussion on HN will be higher quality for a tech-related post than a comment chain on a specific post, since HN has already attracted a wider set of readers than 99.9% of all blogs.
The main advantage of commenting directly on a blog post is that the author is far more likely to see it vs. the ephemeral state of the post being on the HN front-page.
This is already happening to HN as tech people flee Reddit.
Most of the new comments on any given post are people that didn't read the linked content and complain about stuff addressed in the second paragraph.
This is an evolutionary process where the commenters that get the most engagement are those that are first to respond or react. First-mover advantage entrenches itself as those posts are boosted higher due to the engagement they receive.
Those that think deeply before responding are discouraged when a well-thought out comment is buried beneath a sea of first impressions.
This reward cycle is amplified by more people, because engagement is very unequal on platforms that share a top comment or front page for everyone. You either make it to the first few comments or get nothing at all.
Sites like Discord or Facebook try to counteract the monopolization of engagement by an impulsive few by splitting users into smaller groups. Less competition for social interaction creates more diversity in winning strategies. Evolutionary pressures still exist, but you don't need to perfect a "winning strategy" solely to interact with other people on the platform.
Contrast Reddit or YouTube videos. The concentration of attention means it has monetary value due to SEO, product reviews, or advertising. The value of a large audience makes a platform more competitive. Competitiveness means many YouTubers and Redditors professionalize attention-seeking behaviour. This comes at the cost of quality.
https://en.wikipedia.org/wiki/Eternal_September
Almost everyone does that since I’m here and that is at least for 10 years. We even have a thread about it from time to time. HN is absolutely fine and didn’t change that much cause it disincentivizes attention seeking, at least cheap one. They may slip in from time to time but mostly get a cold shower from users and mods. Also this forum is much more tricky than it seems, from a technical standpoint.
Did my homework though and checked top ten threads and their first comments where all these karma people should be. All top comments are pretty HN spirited. One of these may be called nostalgic but has a specific request in it and doesn’t look like a bait.
Part of that may be my perception problem.
A specific capability oh HN, that I take advantage of often, is being able to skip thread branches. It’s not uncommon for me to go a few messages, think “Nah”, tap “root”, then “next”, and, boom, a 100 first impressions vanish in a click of disinterest.
It’s a really great feature and can act as a crude filter for first impressions.
This is an ongoing theme since I first checked out this website, which was in 2008 or so.
Are you sure comments are still desirable? Isn't step 1 of the internet anymore "Never read the comments"?
That said, I did actually work out a solution for "static site with dynamic comments" on my blog that could easily be done for a lot of people if they're willing to use a hosted service. Discourse (the modern forum software that a lot of places moved to after PHPBB) has a way to integrate with pages for comments, and so I've been using that for at least three years now with no real trouble. I host my own Discourse install (I'm weird, I still have a server racked up in a datacenter), but there's no reason you couldn't pay someone else to do that and provide comments.
Interestingly, the amount of spam I've gotten with my Discourse comments is a tiny fraction the amount I got even with Blogger back when I was hosting there. It's just not a big problem anymore for me, and it was a constant annoyance with PHPBB forums and Blogger.
The rest of the site is just Jekyll, based around a template I bought (because I can't make a decent looking website). I've then hacked on it a lot over the years to make it do things I want (responsive images, mostly - I'm still sensitive to people on low bandwidth connections), but it's not bad at all in terms of maintenance. Just launch a render job and some scripts upload the new files.
It very much depends on who you ask. As a reader, I always check the comments on an article. It's easily 75% of the fun of the Internet to me, more so if it's a shitshow. I can understand not everyone feels the same. I've been hearing for years from many different people how Twitter is a garbage dump, but to me it's no worse or better than any other place where people can respond to each other.
https://hn.algolia.com/?q=%22disqus%22
Facebook offered a commenting system a lot of sites used, but it also lost trust and reach with its scandals.
I use Hugo myself, but the user experience is much friendlier in Wordpress even if the footprint is unnecessary from an engineering perspective.
Not every business site wants comments, but they'll probably want a contact form. Putting an email address out is an alternative, but handling the input pipeline is better.
On a static site that requires finding a service they trust to handle the submission and correctly plug it in their site. It becomes another moving part, potentially another bill that needs to be paid separately, another bit to deal with when the industry consolidates etc.
Please enable JavaScript. Please allow scripts from these off-site domains to execute on your computer. Please enter a return address hosted by an approved email provider. Please read through all the categories in this drop-down list and select the one that best fits your message. Please fill in these required fields and re-submit the form. Please unblock challenges.cloudflare.com. Please waste your time repeatedly solving annoying puzzles, until our CAPTCHA provider can sufficiently fingerprint you and your browser. Please re-type the text you already entered, because we reset some or all of the form fields due to one of the above complaints.
No thanks. If I'm at a contact page, it is most likely because I have something of value to the site owner, such as potential business or knowledge of something broken on their site. If they expect me to jump through hoops, I won't bother.
In principle, contact forms could be nice enough, just as many web sites could be clear, simple, quick-loading, static pages. In practice, they're generally a burden.
Given that they don't offer much to the visitor even in the best case, I would rather just see an email address.
Most Saas in that area can't see the difference between a freelance portfolio site where you can send work offers and the support form of your local telecom where people will send death threats.
At the end of the day, for the lambda user it's just better to have the forms handled on the same platform as the site (wix, squarespace etc.) than dealing with a generic solution elsewhere.
> email address
On the receiving end, the advantage of the contact form is to map it to something else that email (Google Sheets etc.). Of course you can set an automated email box that will process the incoming mail into something else, but that's just an additional burden.
This is worth a read:
https://news.ycombinator.com/newsguidelines.html
Anything else is overengineering.
For instance it means leaving the browser and have the default email client handling it. For some people it becomes a distraction, for other they didn't even setup the default client so it's a setup screen and hey have to copy/paste the email to their gmail tab.
Other people actually don't want to give their email but will give a phone number, or their Twitter handle, a chat ID, or their address, or anything else really.
A form is more maintenance, but can be pretty beneficial to address a general public.
For everyone else it’s the gmail app.
The WordPress ecosystem is of course the polar opposite of this, it's populated by billions of dollars worth of businesses that understand intimately what the people operating CMSes and websites in their little niche of that market need, the size of this market is 500 million websites or so.
I'm sure the guy who wrote this article is a smart guy. But he is obviously not smart about the practical uses of a CMS if his worldview is "static HTML sites are better but aren't popular because of evil corporations." You really only need to get paid to build a website once or twice to realize that a static HTML site generator is almost never going to do everything that your customer wants it to do. WordPress realized how vast and varied this market is many years ago and that's why they implemented support for plugins.
You're 100% right comments is like the original use case for having something more like a CMS on the web instead of a static site generator. But there are also a million others.
You just don't get that far with static HTML documents. As soon as you move beyond some minimalist developer's blog you need programmatic logic, and lots of it, to do everything the actual users and customers want you to do. So you use a CMS, whatever CMS fits your needs. And you cache aggressively if you want that site to stand up under a lot of traffic, that's part of the job.
For the life of me, I will never understand why all these devs who think they're so shit-hot want to reinvent the wheel instead of just learn a bit about how caching works, and employ it! Is it another one of those solved problems that's too boring for them?
Liferay, Sitecore, Dynamics, SharePoint, AEM, SAP, SharePoint, Optimizely, Contentful, Sanity,....
Have a restaurant and want to offer take-away online? That's going to be an embedded iframe.
Have a small hotel and want to let guests book their rooms online? That's going to be an iframe from Sirvoy, or a horribly bad Wordpress plugin.
Have a dentist office, or you're some kind of freelance consultant and want to let people book and pay times? That's going to be an iframe.
Have an actual blog that is popular and want to make a paywall so that only paying subscribers can read? This is where WordPress will shine right? Go and buy such a plugin for $200-$300 and later tell me how your experience was. Even for this basic blog functionality WordPress is a horrible mess.