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.
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
That’s not their job. Their job is to sell stuff (or make it more likely to be bought anyway). How they sell stuff is something they can determine themselves.
You’d think that at some level the ‘faster websites sell more’ speech gets through to them, but the important distinction there is that many do not care about what their job is (just like many recent engineers), they just care that it’s easy to do and they don’t get fired. So… Wordpress.
But if you use Hugo, Ghost, or whatever, you get to the point of "for this you need this other platform", where platform is shopify, or an accounting system, or a social network/membership plugin, a job board, etc. Wordpress became this thing that can be turned into anything else.
So someone calls a consultant and says I want this, and they go, I'll set it up for you in Wordpress. Then, because everyone was using wordpress, it was easy to get people to help you when you had issues, or to tweak your plugins slightly, add a hook to send an email, etc. So the age of PHP consultants gave Wordpress it's dominance.
Problem is, most of these solutions, even paid ones, are not full solutions. When you start using them you quickly realize Wordpress imposes non sensical limitations. You can't architect your online store outside Wordpress's performance disaster of a entity/metadata system where any reasonably sized query takes 5 seconds and generates 50 other secondary, non optimized queries. Some plugins even try to work around this by going around wordpress and creating their own db tables out of wordpress's control.
Wordpress is horrible, not architected for anything other than a blog, but used as a tool for everything. Other CMSs don't do that, so people don't use them.
Wordpress apparently provides a content management system your users like. How you serve that content is easily decoupled and can still be from static files generated and distributed via a CDN.
Static sites don’t require markdown and git.
I spent a lot of time looking and still hasn't found toolchain, that would allow interns with zero technical experience deliver edits, without getting involved in tech details.
Closest one would be some headless CMS with Static site generator bolted on top, but honestly they all suck.
So yeah, it's not down to technical experience required for the edit process.
For the average user though, you are 100% correct. You need a UI that they will understand. Explaining git to them is not a good idea.
Making everything convenient for the user has been a thorn in my industry for a long, long time, resulting in massive, complex machinery that is controlled by an HMI which amounts to "user push, machine go" and copious amounts of magic happen between those two steps.
I see the same issue as I enter software development. We treat the users like ridiculous idiots, shackling them the ignorance that come with convenience. The auto industry excels at this, selling $30,000USD products to people who can't change an oil filter or explain in basic terms how an ICE works.
I'm ranting, sorry, but what I am getting at is all this drive to make everything as convenient as possible without teaching the user anything does many bad things;
1. Denies users any enrichment, leaving them stuck making the same decisions over and over without expanding a skill.
2. Creates a Culture of Dependency, where users don't understand anything about the product they are using aside from the most basic operations, leaving them unable to pivot as things change, or troubleshoot when things inevitably break.
3. Adding to 2, when all the power is shifted to the folks who make the magic work in the product, they start doing user-hostile things with it like the copious amounts of data harvesting and privacy violations of the modern Internet, not to mention extracting their piece of the value pie to an egregious level.
As someone who is constantly learning new things to try and stay current, fights for the right to repair and uses FOSS whenever possible, I just can't get behind the thinking that brings is to the conclusion that marketers should be making these kinds of decisions based on convenience.
I bid you goodluck and farewell as I die on that downvote hill.
Is it really confusing?
They are the ones that are supposed to maintain it (from a content perspective) ... unless you want to be called every time they want to fix a spelling mistake, write a blog post, add a section, adjust the color scheme, add/remove a section - because that's what would happen if force them to use git and raw css/html.
This required you to add a bit of RDFa markup to identify the editable parts (including collections, so you could add a news item or whatever), and then had a Backbone.js plugin setup for implementing saving to your chosen CMS.
This all could likely be done easier today. But trick is of course figuring out how to save from browser to git. GitHub has a REST API you can use, but authentication needs a server-side component.
There is no reason at all for WordPress, it just became popular because people online were recommending it to each other without a thought as to why. I myself was one of these small time web devs, thinking that user editable pages would require such complicated NASA back-ends that WordPress was the only solution. In the end WordPress has been a huge net-negative on the economy as a whole, for all time wasted.
>This all could likely be done easier today. But trick is of course figuring out how to save from browser to git.
SurrealCMS connects by FTP instead to solve this.
[1] https://www.surrealcms.com
* "What you see is what you get"
Costs nothing to host, but then you need to train every user, which demands time, will make productivity go down every time there's a new user. VS wordpress, which any copywriter or marketer already knows how to write on, or will learn in just a few minutes because creating a post there and clicking 'publish' is easy
It's more than that - imagine that marketers want a contact form on such static site, well nice, you can add that easily. But now there is a lot of spam coming through, okay that can be dealt with. Now they want to have multiple, editable forms. And Hubspot integration, and analytics integration, and now one of forms needs to be 2-step, another needs to have dynamic part shown/hidden based on conditions. etc etc All of that is already solved issue in the Wordpress world - one can pick proven and tested solutions from multiple vendors and deliver results.
And that is ONE component, form - sure it can be replaced with some 3rd party embedded widget but that never comes without hidden costs/annoyances. There are multiple components similar to used "form" example
Oh, https://sumar.io is a form handler for static websites available under the AGPL.
Marketing and copywriting people don't know any of those licenses. And I guess not ironically, first search result for me for AGPL was "Understanding the AGPL: The Most Misunderstood License". So this already makes it kind of a no-go. If I'm in a rush to add a form, I need a simple answer: can I use for business purposes and do I have to pay for it?
Why does it require those things? There's nothing inherent to static sites that demands either. There's also nothing inherent to either static sites or WordPress that keeps you from providing a user-facing post-writing and -editing UI that looks the same as WordPress's.
The idea that they should accept a sub-par solution not of their choosing just for the developer's convenience is absurd.
Each blog post is going to get written once, but read (hopefully) thousands of times. Why are we optimising the writing experience and not the reading experience?
And even when we do give WP-like ease of editing with background static generation, editors still want WP, because this or that plugin.
So you are saying that you are still missing functionality
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.
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.
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.
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 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.
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
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.
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.)
The job of the browser is to _render_. That's agnostic on whether you're creating content or just reading it.
Nowadays it's more important than ever to curate content well.
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).
(Why would I report an outage when the power wasn’t out? Our lights blipped and my whole-home battery backup system kicked into action and showed a “grid outage” message. I checked it a few minutes later and it still showed the same status, so wanting to be a helpful neighbor, I reported it. I found out later that the battery backup system stays off-grid for five minutes following an outage of any length, even just a blip, I think as a debounce protection. When the utility trucks showed up, I told them what had happened and that their system wouldn’t let me cancel the report, but they were just glad to have a break from running around dealing with outages nearby, so they stayed and talked for a few minutes, curious about the battery system. Nice guys.)
Most voice menus have hidden, 1-indexed touchtone mappings.
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.
In an emergency you are allowed to transmit without a license. There were plenty of unlicensed calls going to the Mt. Mitchell repeater.
All that being said, I am definitely getting my license once this is over.
A thing of beauty, compared to their normal home page with 90+ files of 12MB.
I forgot to save the links to the others.
is also a nice one
If I could sum up much of the miserableness of this disaster event it would be communication breakdowns in all kinds of ways.
I get that these counties don’t have the budget or the technical staff for this but it’s really unfortunate.
In any case, in places like eg India 4G is more common than 3G. 3G is being phased out. 5G is rolling out.
(I realise that India isn't the poorest of the poor anymore. But not sure that's necessary for your argument?)
Big up this author. Here’s a recent podcast about the recent conference this quote came from (Squiggle Conf), https://changelog.com/jsparty/339
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.
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...
The fundamental rule I've set myself against feature-bloating in my website is defining what I want it to be: an archive of things I've done. As an archive, I want it to be very durable in time. Thus, static file that are dead-easy to copy around, mirror and make it work in any hosting platform.
It did take me a while to nail having a bilingual site, though :) but at least it's a price I paid once.
For 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.
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.
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.
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.)
I think the tide is turning, as people are starting to realise the fragility of complexity.
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.
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.
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.
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.
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.
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.
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.
The code for a single page looks like this:
<?php
$this->title = "Blog Article Title";
$this->shortTitle = "Title";
$this->date = mktime(0,0,0,1,27,2024);
if ($this->mode == PageMode::Meta) return;
?>
<p>Raw HTML content here<p>
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/
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.
Isn't this what companies like Netlify, Squarespace and Github Pages does? I know with Netlify, you can transfer a parked domain, pick a template and it does a majority of the config for you and you're up and running in a few mins and then it takes about 24 hours for the domain to go through.
I get what you're saying though, even with those companies who are close to what you're talking about, taking care of those minor middlemen steps would be a boon to someone who could figure it out.
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.
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.
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!
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.
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.
<!DOCTYPE html>
<html>
<!-- content goes here -->
</html>> An html element's start tag can be omitted if the first thing inside the html element is not a comment.
> An html element's end tag can be omitted if the html element is not immediately followed by a comment.
The only explicit tag that is required for every HTML document is <title>, which you supposed boilerplate misses.
> The start tag may be omitted if the first thing inside the <html> element is not a comment.
> The end tag may be omitted if the <html> element is not immediately followed by a comment.
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ht...
I've tried omitting those tags, but I decided that in the end things are easier to read when you do include them, so nowadays I always include them when I write HTML.
> This language server is stricter than the HTML spec whenever it would prevent potential human errors from being reported.
If your goal is to output minimal HTML, let a tool automate that. Forgetting to open <html> is more likely a mistake than shorthand, and as shorthand it's not valuable.
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 :-)
A normal human being is going to see something like a checkbox to enable comments as being amazingly simple.
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
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).
And many still have. I think most wordpress.com and blogger blogs have comments on
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.
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.
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
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.
I'm not complaining, but after a certain threshold, unbundling is much more expensive.
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).
You can't beat "free hosting" on GitHub Pages CDNs and the reduced maintenance burden of not needing to monitor uptime of static sites, infrastructure dependencies, OS updates, etc. They can also be maintained by editing .md files from GitHub's UI
We use them everywhere we can and maintain a number for Free SSG project templates which include GitHub Actions to publish them to your GitHub Repo's CDN for free hosting.
All templates use the same markdown format and structure to edit content making them easily to move content across different SSG templates built with different tech stacks.
[1] https://razor-ssg.web-templates.io - C# Razor SSG for Marketing Websites/Blogs/Podcasts
[2] https://razor-press.web-templates.io - C# Razor SSG for docs
[3] https://press-vue.servicestack.net - Vue SSG for Marketing Websites/Blogs/Videos
[4] https://press-react.servicestack.net - React SSG for Marketing Websites/Blogs/Videos
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)?
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."
Imho, the big lie regarding static sites is that it's showcasing only part of the solution it fixes. In the end it does not reduce complexity, it pushes it away from your immediate attention span(it's serverless), either to building tools, browser and configuration files.
You still need to build it, pick a layout, maybe some plugins. That requires not only the time to do it but also infrastructure behind, to push changes. If you consider that, from the start till the end, there is the same amount of complexity around it. You still need to persist data, md files look more appealing, but in the end is a disk data store, and if you need to collaborate, edit, etc, you end up realizing why why databases were invented.
To conclude, I really like static sites for the reasons I didn't include here.
Various startups built solutions that snapshotted WordPress installs and put the snapshots on static hosting. Best of both worlds. The one I know best got acquired: https://elementor.com/blog/elementor-acquires-strattic/
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?
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
> only few professional software engineers can "afford" to have the second option as their personal website
In the quote "second option" refers to SSGs. But likely most of us here, and surely most engineers I interact with, would use the word "affordable" to describe why the first option (complex CMS like WordPress) is generally AVOIDED. The post quotes "professional engineers" or "professional software engineers". And points at SSGs as an "unaffordable" solution over WordPress.
The basis for this blog posts are however, that setting up SSG is time consuming while WP comes with less strings. Scroll to the end of this blabber to see the strings.
WordPress is not really an option for "professional software engineers". Most of us would be ashamed of having our personal websites defaced or allowing an attacked to read our databases and change entries. The "pros" own their swolutions and are careful around what that ownership entails. YOLO-approach CMS foer the personal website is simply not an option...
It's due to man-hours required to secure all the underlying dependencies (PHP, database), problems related to managing multiple system services to make a personal website work (outside of caddy, nginx etc) and how compute-heavy using WP is. And how much more knowledge (and - again - time) one needs, to harden a WP website for heavy load. You know - the "hug" thing which is not a thing with SSG-generated stupid static HTML, CSS and JS files.
Or, maybe I'll just quote the nonsense... According do the author WP is better than SSG because it doesn't require one to:
Buy a domain
Find a hosting platform
Configure DNS
Find an SSG (or handcraft everything yourself)
Learn how to setup a deployment pipeline
I didn't even use a framework and chose to just use libraries and implement the features only if I need them. Probably it took more than just using a framework but it's pretty minimal and I know all the parts of my toolchain. And I learned much more than I could learn if I used a framework.
On the other hand, normal users don't have an understanding of static/dynamic site and which one to choose. It is entirely up to the non-greedy/greedy clowns to go for a complex CMS written in some programming language initially by themselves or a WordPress or HTML static site initially.
I think the author should have told whether this personal website is a static site or dynamic.
It’s mostly list of markdowns and images in folders. Everything else generates during deployment on GitHub:actions
It was simpler to show GitHub desktop rather than installing something like Wordpress machinery monster and spent hours to teach how to use it. Now the process is simple:
1. Create a folder
2. Put there markdown and images
3. Commit
I know other people like jekyll or hugo or whatever, but I've never seen anything comparable to the simplicity of mkdocs. It has built in search for the entire site, nice looking nav, everything is markdown.
The best part though? Here's my "build pipeline".
$ mkdocs build
$ scp -r ./build <user>@dangerlibrary.com:/site
I love it.
> 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.
> 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.
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.
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 static website is a website that has no server side generation. That's how simple it is.
Static website can be served by `cat index.html`
Simple, has text-focused CMS, lightweight and content generated is static. Plus, dev is a nice guy.
Also, a pro would know that it's Mbps (megabits per second) and not mpbps (millibits per second).
Surely this is the "best of both worlds" answer?
Which is kind of funny as the main advantage of static sites is fewer things to worry about.
A case of irony?
> 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.
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).
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.
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.
Consider what's needed for someone non-programmer-y to use an SSG:
* Download a copy of the repository and install the SSG tooling, then fire up the SSG in listening mode so they can see their changes. * Write out the Markdown for their page. Oh, hope you have short-codes in place for things like images-next-to-paragraphs, info callouts, common page structures (cards, hero blocks, buttons), and so forth. If not, either they'll have to pause and get you to work with them to have them implemented, or they'll have to figure out writing the templates required. Regardless, once the bits are implemented in the site the writer has to work in the arcane short-code format markup required to include them. * Now they've got their changes, they need to figure out how to stage them — either they need to zip up the whole working directory and send it to you to sort out, or they get to learn how to commit a pull-request to a Git repository.
I don't mind doing all of that — it's quite enjoyable to figure out, and I get the chance to structure things exactly as I like them. But trying to teach a theatre director accustomed to writing in Google Docs how to do all of that? Nope. Which then turns into, "here, I wrote this out in G-Docs — hope you can figure out how to turn that into a site page!".
I really do wish there were a better competitor to WordPress, something that offered the ability to lift the hood and customize more easily. There are some CMS front-ends to SSGs, but the last I checked they either were more "CMS" in the sense of "put stuff in database and this will render it" or they still weren't particularly user-friendly (or were abandoned).
Guess that idea is long gone...
Now when a new post added happens what?
#1. You log-in to admin panel and write a post. A row is added to the database, a worker subscribed to the table sends the row via websocket to every active visitor on the site. They download few hundred bytes of data and see the post immediately without needing to refresh their browser. If they refresh, they will get cached version of the app and data instantly, then fill in the missing post from the API.
#2. You either use SSG or you generate a new static HTML page by hand, specifically on a device which has a private key for uploading to the server. If you don't choose an SSG, then since Javascript is complex, scary and prohibited, you also change the main feed HTML to include a new post, you timestamp all the new stuff by hand, etc. You upload it to the server via ftp. Great, now new visitors of the main blog feed will see it. Active visitors will see it only if they reload the whole page (hopefully they don't load the cached version).
Being professional is not to choose an extreme. Being professional is to solve a problem, and to make the best tradeoffs possible when solving it. There are many different configurations which are somewhat in the middle of extremes provided in the post, and using any of them professionally is about using them right and fitting them to solve an issue.
You would expect all normal users, including professionals to distribute normally between your neo-web-luddite static NGINX+HTML+FTP solution and javascriptpunk2033 complex CMS.
Huh? <confused-dog.jpg> Either the page gets rendered server-side and (possibly) hydrated client-side, or it gets rendered client-side (i.e. a classic SPA) but then there is no hydration.
Oh come on! You don't really expect that to last, do you?
Learned back in 2004 that it's better to pay than to rely on free services. I pay for source code repositories, email, web hosting, etc.
"normal users are stuck with a bunch of greedy clowns that make them pay "
Here we go again, software needs to be free as in beer and anyone that charges for software is the devil
"software engineers enjoy free hosting & custom domain support with GitHub Pages / Cloudflare Pages "
You get what you pay for buddy.
And there it is, beautifully distilled into one sentence.
I'm surprised I haven't come across more examples of people using GitHub Actions with static site generators like this. Ideally someone would share a GitHub repository template that comes pre-configured with a good static site generator which people could then use as a one-click starting point for their own sites.
I've considered building one of those myself but I tend not to use static site generators (I like Baked Data instead: https://simonwillison.net/2021/Jul/28/baked-data/) so I'm not a great person to take on that project.
- Not knowing what GitHub is or how it works (let alone Git itself)
- Not knowing how to clone a repo
- Not knowing what program you need to modify the files in a repo, or how to use it
- Not knowing how to make/push commits
- Not knowing how to build local previews to see your changes before they take effect
https://github.com/AshwinSundar/ashwinsundar/commit/6887c201...