I have whole rants about this, based on bitter experience trying to convince marketing people to stop using WP and just use a static site.
It comes down to ease of editing. A WP site optimises for the editor. Not the hosting, not the tech folk, not the accountants, and definitely not the reader. The people who edit the site get to say how it's implemented.
If you give them the choice (as I have) between a site that renders in <100ms, is completely secure, and costs literally nothing to host, but requires markdown files and a bit of Git to deploy, and a Wordpress site that's as slow as hell, costs a fortune, is insecure, needs constant maintenance, but has a nice editing process, then they go for WP every time.
I'm always confused as to why these particular people get to be the ones who make the choice. But I've repeated this experiment multiple times and it has always come back with the same result.
> based on bitter experience trying to convince marketing people to stop using WP and just use a static site.
Sounds pretty user-hostile. You're talking about marketers who have a "Job to be done" which is to make content and get it in front of some target audience. Of course the editing experience trumps security and rendering speed. I'm confused why you're confused they always choose WP over figuring out text editors and git!
The experiment should be giving them a nice editing experience that behind the scenes is creating a static site and some git to deploy vs wordpress. Then maybe the secondary requirements you care mostly about will be relevant
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 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.
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.
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.
We’re dealing with this big time in Asheville now. When cell service came back at all, everyone had shitty intermittent 3G, and none of the websites we needed for basic survival information would load. A bunch of good people created some text only news sites, and today I noticed that the Buncombe county website finally has a low bandwidth site, but even then when I inspected it, it had 130k of bootstrap css and 50k of jQuery blocking rendering. It’s great that people are doing this work, but citizens needed this a week and a half ago. By now, I’ve figured out where to get water, food, non potable water, etc. Seeing tech fail so badly through all this has been eye opening for me, in a depressing way.
Not as catastrophic, but during power outages in my neighborhood, I am usually left with a poor cell signal (no backups on cable internet boxes). Electric utility's outage map is hidden behind a login (!) and is rendered with fancy clustering and other UI features that are already slow even with a decent connection. So it takes quite a while to check the status or even report an outage.
I could call the utlity company, but for some reason, they chose voice navigation (instead of keypad tones) for their menu, and it is not good at recognizing distorted voice (over bad 4G or 2G connection).
that situation has had me thinking about getting an amateur radio license again. In a disaster like what happened to Western NC, which encompasses a much greater area than just Asheville, I wouldn't want to rely on anything based on the Internet. You want something with a long wavelength and low power. But it's so inaccessible, and I'm not sure if it's for good reason or not.
Connectivity was knocked out from Black Mountain all the way to the Tennessee and Georgia borders. I'd be surprised if many people even have shitty 3G back yet. What I know is remaining in touch with people who live there has been hard.
I am used to this, having used all sorts of bad internet connections over the years. Too much of the internet is designed on fast computers with fast internet and excellent monitors. Some of my best work was done on a 12” MacBook with a spotty hotel WiFi. I pay very close attention to page speed.
I live in Sylva which is about 45 minutes from Asheville and yeah, Cell service made getting any useful information on your phone pretty bad. If I hadn't had Starlink I would have been in the dark for at least a week on a whole lot of stuff.
If I could sum up much of the miserableness of this disaster event it would be communication breakdowns in all kinds of ways.
Buncombe honestly did a much better job than the surrounding counties. Up here in Madison County most of the updates were only posted on Facebook. A lot of the updates from here and surrounding counties were posted on Facebook as photos of text or videos with no caption.
I get that these counties don’t have the budget or the technical staff for this but it’s really unfortunate.
Plus, what you call "shitty 3G" is (a) not really that bad objectively speaking (better than dialup 20 so years ago), and (b) actually the norm for hundreds of millions, if not billions, of people. I always think it's very depressing and even hypocritical how little the average SV dev cares about anyone with less than an iphone 15 with 4G in their pocket.
> 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
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.
There is a complicating factor for a Web developer's personal Web site: resumé-driven-development (RDD).
For those professionals who try to use personal side projects for RDD, so that they don't have to sabotage as many employers' projects as they would otherwise.
Which leads me to this morning, for example... For an indie Web site I'm about to launch -- and for which I'm using a popular modern Web framework, mainly for RDD reasons -- I could no longer update my Web site.
Because an NPM package had a Critical security problem, and trying to get the update got NPM stuck with some interdependency conflict that couldn't be resolved automatically. (Which, ironically, prevented pushing the security update to the production site.)
The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting.
Instead, it's 129 NPM packages, frequently needing security updates, and a large tree of cryptic source files (template fragments, TS configurations, handlers), just for the NodeJS part of the site alone.
But doing it the ridiculously complex way is something that professionals can't afford not to do. (For example, having Perl on your resumé would be the kiss of death for employability. The people who didn't throw away your resume for ageism reasons, would still think you must be an idiot for not doing RDD.)
As someone that works across Web and distributed systems, my boring PHP site reading its content out XML and JSON files, hasn't been an hindrance changing jobs, thankfully.
The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting.
Or it could be something in between, because it’s convenient to do so.
In my case, I couldn’t care less of resumes and offers, but still I want something more ergonomic than spitting out htmls from templates in js/python. So my sites are a mix of typescript, mithril, express and a few utility libs. Idk and don’t care how many packages it is, as long as my main imports are mature and don’t give birth to a new feature-vulnerability every few minutes.
You never mentioned your stack, but it’s a safe guess that it’s react and its ecosystem of always-improving-never-done bullshit. My completely unsolicited advice here is to avoid believing in false dichotomies. 1) There’s a big space between raw html and the worst possible mud. 2) This situation with react “world” is specific to react and isn’t indicative of anything outside of itself.
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.
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?
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.
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.
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.
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?
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.
I fit into that Paradox -- I rewrote my own personal website in modern PHP without a framework or database. It's mostly a static site but uses PHP to add headers, deal with lists (for blog posts), etc. I found it slightly more convenient to be not completely static. I can just write up an article, commit, push, and it's online. I found most static site generators to be far too complicated.
There is a router that automatically adds the site header and footer, and I can add a "_layout.php" file to a folder to add another level of layout for child pages. For blog list page, it just scans all the individual article files in the folder to create the index. That where that $this->mode == PageMode::Meta comes in -- it executes the code in each file (to get the meta data) and then exits before rendering the rest. It's not going to scale to a lot of content but I'll adjust if it becomes an issue.
The entire PHP code for my "framework" is only 4 PHP files (init.php, functions.php, Layout.php, and Page.php).
The advantage of being a developer is that you can use code instead of configuration or data. And you can use code to write content more efficiently.
It’s not really a paradox when you consider the UX from the website owner’s perspective. Wordpress makes things stupid simple to do, even if it has way more overhead.
It’s only a paradox if you think the trade off is spending time configuring things. No, the alternative for most people would be to pay someone to set up their website.
If someone set up a WYSIWYG editor for Hugo that goes from domain registration to published site in a few clicks they’d make a fortune.
> 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.
> 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]..?
The current state of web development engineering is largely the result of how startup economics have functioned over the past decade.
A startup's market value is often closely tied to its number of employees. From an investor's perspective, a company with 1,000 employees is typically valued much higher than a small team of 37 programmers — regardless of the revenue generated per employee, or even if the company isn’t generating revenue at all. This is largely because interest rates remained very low for a long time, making it reasonable to borrow investment funds for promising companies with large staffs.
However, those employees need to be kept busy with something that appears useful, at least in theory. I believe this is one of the primary reasons we see such complex solutions for relatively simple tasks, which sometimes might not require a large team of advanced web developers or sophisticated technologies at all.
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.
Even the last few points of their "simple" flow are overly complicated. Before all the CMS stuff, you created the HTML and CSS on files on your desktop using text editors or WYSIWYG editors like Front-page. You can render it just as easily from local files as on a dedicated web server. When you're happy with it, copy the files over SFTP to your server. Frontpage would even take care of that for you. The same flow still works fine today.
Around the dot com boom there were dozens of high quality desktop editors for making websites. All these hosted SaaS systems were just starting to become popular, meant to make it easier for non-programmers to make websites. But did it really? I don't think so. Now those systems are so complex that you need to hire someone to use them. Yet first year students in comp sci who didn't even have any programming background still write HTML and CSS by hand. Templates for WordPress are these complex programs, but a template for HTML and CSS can be as simple as a Hello World example.
I tried the SuperHTML on a hand-coded site of mine and it reported only one problem and that problem is incorrect as far as I can tell. It tells me that the `</html>` tag is never opened on an HTML 5 doc with a `<!DOCTYPE html>` opening tag. The author does say it's not perfect and I probably need to double-check my understanding just to be sure. In any case, it seems like a useful thing and I am also surprised I never thought it was missing.
For those who are like me and don't know the term, "a language server for HTML" is referring to the plugin that evaluates your HTML syntax. That might be a narrow explanation of the tool but that's the basic idea I got from trying it.
It might be useful and fun to setup an open and ongoing competition for the meanest and leanest way of doing web publishing.
Its not trivial to set up because the list of desired features must be agreed and there are legitimate variations per use case. So most likely it must involve several subcategories.
But somewhere between git, markdown, sqlite, python (or maybe go?) a bare bones linux server and the mighty browser lies our optimal set of solutions. With no more that absolutely needed lines of code, no more than absolutely needed user effort and cost, no more than absolutely needed power consumption etc, in other words our true digital publishing future :-)
This is what drove me away from static sites. It's actually more work because you have to be the one to do all the stuff.
Sure, there are a few options for hosting and generating the build, but when I tried, they were not that good, or had some issues, etc... Meanwhile, wordpress.com never disappointed, and has an app for iOS and Android that you can use to update stuff whenever you are - as long as you have internet, of course.
That's why nowadays I use Obsidian Publish. Of course, I could use Quartz or some other alternative for building a site from my obsidian vault but... none will just work out of the box, from your phone
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.
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).
[+] [-] marcus_holmes|1 year ago|reply
It comes down to ease of editing. A WP site optimises for the editor. Not the hosting, not the tech folk, not the accountants, and definitely not the reader. The people who edit the site get to say how it's implemented.
If you give them the choice (as I have) between a site that renders in <100ms, is completely secure, and costs literally nothing to host, but requires markdown files and a bit of Git to deploy, and a Wordpress site that's as slow as hell, costs a fortune, is insecure, needs constant maintenance, but has a nice editing process, then they go for WP every time.
I'm always confused as to why these particular people get to be the ones who make the choice. But I've repeated this experiment multiple times and it has always come back with the same result.
[+] [-] zild3d|1 year ago|reply
Sounds pretty user-hostile. You're talking about marketers who have a "Job to be done" which is to make content and get it in front of some target audience. Of course the editing experience trumps security and rendering speed. I'm confused why you're confused they always choose WP over figuring out text editors and git!
The experiment should be giving them a nice editing experience that behind the scenes is creating a static site and some git to deploy vs wordpress. Then maybe the secondary requirements you care mostly about will be relevant
[+] [-] graypegg|1 year ago|reply
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.
[+] [-] steve_adams_86|1 year ago|reply
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.
[+] [-] tomjen3|1 year ago|reply
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.
[+] [-] TheGoodBarn|1 year ago|reply
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
[+] [-] edanm|1 year ago|reply
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.
[+] [-] nicbou|1 year ago|reply
[+] [-] JellyBeanThief|1 year ago|reply
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.
[+] [-] dimal|1 year ago|reply
[+] [-] yaky|1 year ago|reply
I could call the utlity company, but for some reason, they chose voice navigation (instead of keypad tones) for their menu, and it is not good at recognizing distorted voice (over bad 4G or 2G connection).
[+] [-] dingnuts|1 year ago|reply
Connectivity was knocked out from Black Mountain all the way to the Tennessee and Georgia borders. I'd be surprised if many people even have shitty 3G back yet. What I know is remaining in touch with people who live there has been hard.
[+] [-] montefischer|1 year ago|reply
[+] [-] nicbou|1 year ago|reply
[+] [-] zaphar|1 year ago|reply
If I could sum up much of the miserableness of this disaster event it would be communication breakdowns in all kinds of ways.
[+] [-] shaicoleman|1 year ago|reply
[+] [-] __mattya|1 year ago|reply
I get that these counties don’t have the budget or the technical staff for this but it’s really unfortunate.
[+] [-] andrepd|1 year ago|reply
[+] [-] brianzelip|1 year ago|reply
Big up this author. Here’s a recent podcast about the recent conference this quote came from (Squiggle Conf), https://changelog.com/jsparty/339
[+] [-] dhotson|1 year ago|reply
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.
[+] [-] neilv|1 year ago|reply
For those professionals who try to use personal side projects for RDD, so that they don't have to sabotage as many employers' projects as they would otherwise.
Which leads me to this morning, for example... For an indie Web site I'm about to launch -- and for which I'm using a popular modern Web framework, mainly for RDD reasons -- I could no longer update my Web site.
Because an NPM package had a Critical security problem, and trying to get the update got NPM stuck with some interdependency conflict that couldn't be resolved automatically. (Which, ironically, prevented pushing the security update to the production site.)
The site could be 5 simple handwritten HTML files, one with a sprinkling of JS inline in it, plus 2 small Perl CGI scripts. And it would work perfectly for 25 years and counting.
Instead, it's 129 NPM packages, frequently needing security updates, and a large tree of cryptic source files (template fragments, TS configurations, handlers), just for the NodeJS part of the site alone.
But doing it the ridiculously complex way is something that professionals can't afford not to do. (For example, having Perl on your resumé would be the kiss of death for employability. The people who didn't throw away your resume for ageism reasons, would still think you must be an idiot for not doing RDD.)
[+] [-] userbinator|1 year ago|reply
I think the tide is turning, as people are starting to realise the fragility of complexity.
[+] [-] pjmlp|1 year ago|reply
[+] [-] account42|1 year ago|reply
Have you tried? Also, you don't need to put everything you have ever done on your resume if you don't think it will help.
[+] [-] wruza|1 year ago|reply
Or it could be something in between, because it’s convenient to do so.
In my case, I couldn’t care less of resumes and offers, but still I want something more ergonomic than spitting out htmls from templates in js/python. So my sites are a mix of typescript, mithril, express and a few utility libs. Idk and don’t care how many packages it is, as long as my main imports are mature and don’t give birth to a new feature-vulnerability every few minutes.
You never mentioned your stack, but it’s a safe guess that it’s react and its ecosystem of always-improving-never-done bullshit. My completely unsolicited advice here is to avoid believing in false dichotomies. 1) There’s a big space between raw html and the worst possible mud. 2) This situation with react “world” is specific to react and isn’t indicative of anything outside of itself.
[+] [-] hiAndrewQuinn|1 year ago|reply
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.
[+] [-] corry|1 year ago|reply
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.
[+] [-] safety1st|1 year ago|reply
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?
[+] [-] janalsncm|1 year ago|reply
I use Hugo myself, but the user experience is much friendlier in Wordpress even if the footprint is unnecessary from an engineering perspective.
[+] [-] makeitdouble|1 year ago|reply
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.
[+] [-] Kye|1 year ago|reply
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.
[+] [-] alemanek|1 year ago|reply
[+] [-] Syonyk|1 year ago|reply
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.
[+] [-] tomjen3|1 year ago|reply
[+] [-] davidgerard|1 year ago|reply
[+] [-] fluoridation|1 year ago|reply
[+] [-] smitelli|1 year ago|reply
[+] [-] wvenable|1 year ago|reply
The code for a single page looks like this:
There is a router that automatically adds the site header and footer, and I can add a "_layout.php" file to a folder to add another level of layout for child pages. For blog list page, it just scans all the individual article files in the folder to create the index. That where that $this->mode == PageMode::Meta comes in -- it executes the code in each file (to get the meta data) and then exits before rendering the rest. It's not going to scale to a lot of content but I'll adjust if it becomes an issue.The entire PHP code for my "framework" is only 4 PHP files (init.php, functions.php, Layout.php, and Page.php).
The advantage of being a developer is that you can use code instead of configuration or data. And you can use code to write content more efficiently.
The result (still quite incomplete) is this: https://www.codaris.com/
[+] [-] janalsncm|1 year ago|reply
It’s only a paradox if you think the trade off is spending time configuring things. No, the alternative for most people would be to pay someone to set up their website.
If someone set up a WYSIWYG editor for Hugo that goes from domain registration to published site in a few clicks they’d make a fortune.
[+] [-] pjmlp|1 year ago|reply
Probably because this is something most IDEs have been doing for years, before Microsoft came up with LSP.
[+] [-] lqet|1 year ago|reply
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]..?
[+] [-] Eliah_Lakhin|1 year ago|reply
A startup's market value is often closely tied to its number of employees. From an investor's perspective, a company with 1,000 employees is typically valued much higher than a small team of 37 programmers — regardless of the revenue generated per employee, or even if the company isn’t generating revenue at all. This is largely because interest rates remained very low for a long time, making it reasonable to borrow investment funds for promising companies with large staffs.
However, those employees need to be kept busy with something that appears useful, at least in theory. I believe this is one of the primary reasons we see such complex solutions for relatively simple tasks, which sometimes might not require a large team of advanced web developers or sophisticated technologies at all.
[+] [-] derekzhouzhen|1 year ago|reply
I use several SSGs and wrote one myself. I still can't recommend any SSG to people willing to pay.
[+] [-] RevEng|1 year ago|reply
Around the dot com boom there were dozens of high quality desktop editors for making websites. All these hosted SaaS systems were just starting to become popular, meant to make it easier for non-programmers to make websites. But did it really? I don't think so. Now those systems are so complex that you need to hire someone to use them. Yet first year students in comp sci who didn't even have any programming background still write HTML and CSS by hand. Templates for WordPress are these complex programs, but a template for HTML and CSS can be as simple as a Hello World example.
[+] [-] codazoda|1 year ago|reply
For those who are like me and don't know the term, "a language server for HTML" is referring to the plugin that evaluates your HTML syntax. That might be a narrow explanation of the tool but that's the basic idea I got from trying it.
[+] [-] openrisk|1 year ago|reply
Its not trivial to set up because the list of desired features must be agreed and there are legitimate variations per use case. So most likely it must involve several subcategories.
But somewhere between git, markdown, sqlite, python (or maybe go?) a bare bones linux server and the mighty browser lies our optimal set of solutions. With no more that absolutely needed lines of code, no more than absolutely needed user effort and cost, no more than absolutely needed power consumption etc, in other words our true digital publishing future :-)
[+] [-] nitwit005|1 year ago|reply
A normal human being is going to see something like a checkbox to enable comments as being amazingly simple.
[+] [-] FalconSensei|1 year ago|reply
Sure, there are a few options for hosting and generating the build, but when I tried, they were not that good, or had some issues, etc... Meanwhile, wordpress.com never disappointed, and has an app for iOS and Android that you can use to update stuff whenever you are - as long as you have internet, of course.
That's why nowadays I use Obsidian Publish. Of course, I could use Quartz or some other alternative for building a site from my obsidian vault but... none will just work out of the box, from your phone
[+] [-] superkuh|1 year ago|reply
[+] [-] troymc|1 year ago|reply
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).