hckrnws
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
> 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
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.
Just install any old file based caching plugin like KeyCdn Cache Enabler or Gator Cache and a Wordpress install becomes a static site for every single request until content is updated. Takes all of 5 minutes, win win for all involved.
A bit off topic since the thread here was related to performance, but caching in WP doesn't solve the other big problem of security.
A caching layer can indeed make WP act much like a static site, though the cache still lives on your server rather than a global CDN layer. Behind that cache, though, you still have the live WP server with all the potential security risks that come with it.
Caching is a nice perf gain, but if you want a static site anyway there are still major gains to be made with a proper static site distributed globally.
Aside from some once-in-a-blue-moon security breach events, how does better security help a salesperson sell more stuff?
If gross sales is literally the only important metric in software engineering we've already failed.
Though on the cost side security breaches can be expensive, as can the endless task of updates and maintenance required for a live server. Live servers can also be a scaling bottleneck, often that isn't too important but it would be for anything that is highly seasonal or has large spikes of use during Black Friday events or similar.
> If gross sales is literally the only important metric in software engineering we've already failed.
It literally is the only important metric is commercial software development. Not sure how you could delude yourself into thinking otherwise.
Context matters, you've boiled it down way too far. Gross sales is a primary metric for the business, that isn't necessarily and shouldn't be a primary goal for the engineers building the software.
Context does matter, and you're missing the forest for the trees. It's native to think there's any other metric that matters.
Again you aren't saying matters for whom.
For the engineer writing code, I would absolutely expect they have different priorities and metrics than the business or accounting department.
I personally wouldn't even consider hiring a dev who makes clear that the only metric they care about is gross sales.
> For the engineer writing code, I would absolutely expect they have different priorities and metrics than the business or accounting department.
And yet the business has that expectation.
> I personally wouldn't even consider hiring a dev who makes clear that the only metric they care about is gross sales.
Yes, you would, as you are instructed to. The only difference is that you have deluded yourself that there are interim metrics that actually matter, when they are all lossy abstractions of revenue or profit.
> Yes, you would, as you are instructed to. The only difference is that you have deluded yourself that there are interim metrics that actually matter, when they are all lossy abstractions of revenue or profit.
It sounds like we have lived very different lives. I have hired engineers and never once asked, or cared, how highly they value gross sales. I have also never been instructed to do so.
In engineering orgs I have hired for, the metrics prioritized are always related to estimating and delivering features on time, code quality (often through test coverage or bug count), etc. When hiring, the focus is on skills and experience that would likely lead to those outcomes.
Let's try a different industry. A politician will care most about how quickly and cost effectively a new bridge can be built. Do you think those should also be the only factors that matter to those actually building the bridge?
> In engineering orgs I have hired for, the metrics prioritized are always related to estimating and delivering features on time, code quality (often through test coverage or bug count), etc. When hiring, the focus is on skills and experience that would likely lead to those outcomes
Those are lossy abstractions for profit in the private sector. Again, you're missing the forest for the trees.
What's really happening here is that you are unable to see your commercial role, and instead are focused on the vanity metrics you think are important.
Every one of those metrics would be sacrificed in an instant by the business if it increased sales. They're only even marginally important as long as they align with that goal.
> A politician will care most about how quickly and cost effectively a new bridge can be built. Do you think those should also be the only factors that matter to those actually building the bridge?
The public sector is a different beast, but again your understanding is completely divorced from reality.
Public infrastructure projects in democracies are built to secure votes. That's the only criteria outside of the engineering requirements which are written in law in blood.
>from some once-in-a-blue-moon security breach events
So once every 2 years? Blue moons are not that uncommon.
>That’s not their job. Their job is to sell stuff (or make it more likely to be bought anyway).
Huh? What are you talking about? Marketing is the job of Marketers, which in most companies (certainly small to mid companies) includes the content on the marketing web-page.
>You’d think that at some level the ‘faster websites sell more’ speech gets through to them
The technical aspect of how a web-site works, or how it is deployed or how quickly it is rendered, is NOT their job. Optimizing render speed of a given web-page is not part of their skillset - nor should it be. There are folks who specialize in that, typically software engineers. It is also not reasonable to expect marketing folks to create html/css/javascript and deploy via git. You really do want those folks to be independent and create the necessary content without needing an engineer anytime they want to add a new sub-section or fix a spelling mistake.
One "problem" is that most small/mid size businesses are not willing to hire technical folks or use engineering resources to do the technical part of this work. Another problem is that there should not be a tension between ease-of-use by editor and page rendering speed. Maybe WP is a bad product, and if so, what is the alternative that covers both use cases?
use WP to generate the site and then serve it statically as much as you can
Sure - and in principle 'someone' should go and setup this pipeline. I can guarantee you that if this process is reasonably transparent to the marketing folks, they will not care.
Or do you expect the marketing folks to go and setup this static page caching?
WP has plugins to publish as a static site already. They just don't seem to be very commonly used. You get the 'ease' of the WP admin UI and the 'safety/speed' of a static site.
We are suffering from some kind of crisis of measurable competency across the board. The appearance of contributing to achieving something is more important than actually achieving it. It may be related to the preceding extremely long ZIRP period.
[dead]
You said it yourself. The tech you're suggesting didn't meet their requirements. Once it does, they will use it. A marketing site SHOULD be optimized for the editor. This is a failure of the dev, not the marketing person.
my confusion is why it's their requirements that need to get met, not say, the readers' requirements.
Because part of their job, if they are good at it, is to present some data, measure how customers are responding to it, and then tweaking said data to get a better response. If you make it too hard for them to “tweak” it, then they will be more reluctant to tweak it. Thereby doing a poorer job.
Them being able to easily change the website is critical for them to be able to do their job. As in most things in life, it is a balance that needs to be achieved and not one thing that trumps everything else.
As others have said, WP gives them a way to easily change the data that they are responsible for. It should be the devs/systems engineers responsibility to make that data present as a static web page using plugins or caching layers and that should be transparent to the marketers.
The marketers care quite a lot about the readers. After all, their goal is to reach them with glorious content so they do something.
This leads them to aim for “reasonably performant for the users” as part of optimizing the package of reader + marketer experience.
In that view, IT requirements such as security rank between “should be standard” to “don’t really care” (at least until the first compromise).
How would you go about collecting the user requirements of the readers? Do they pay for the development?
The mass of readers don't have the same requirements as HackerNews commenters. Proof is that content on wordpress still gets viewed and apparently, leads to sales.
Better editor performance, more agility, the faster they can test stuff, the faster they can check what works -> better marketing.
Imagine if you were told that you had to do all of your software development work in notepad, because for whatever reason that lead to better optimized code… would you be ok with that?
The embedded dev world would like to have a word with you.
It's marketing, alright? Users are cattle to be milked, their requirements matter only to the degree it keeps them on the farm, which means not much.
Apparently co-workers of devs don't even get that much respect.
This is the issue. I'm an engineer, and I moved away from WP years ago, now I use ghost. But wordpress gives you that feeling of control, that you just need to search for "online store", and you get 100 plugins, including woocommerce, that are full blown ecommerce platforms. It's less the blogging, and more the customizable application that laymen can hammer into their desired function by clicking and dragging, no coding necessary, at least until it gets hacked or they need a real engineer to build that bespoke functinality.
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.
Trying to explain to someone how static sites work vs how WP works, and that the server has to literally recreate the entire page from a bunch of database entries (having first compiled all the PHP files into something the server understands) for every single page request. It's crazy that we ended up with this powering most of the web.
A simple file based caching plugin like KeyCdn Cache Enabler saves every page as static html and uses Apache rewrite rules to serve those files until invalidated, bypassing php entirely. It is trivially easy to install and configure.
Free tier cloudflare caching basically does the same, host your dns on cloudflare, turn CDN on for a record, and whatever users request from that IP gets cached statically, distributed across and served by Cloudflare’s global cdn.
For more interactive database heavy applications like ecommerce you can go deeper with opcode and object caching, but none of it is that complicated. There are plenty of managed solutions that do all of this for you.
> It's crazy that we ended up with this powering most of the web.
What's crazy is your wilful ignorance of _why_ WP is so popular. One important reason is that it allows writers to avoid people like you, who hold them in disdain without even the slightest attempt to understand their needs.
Please stop with the insulting ad-hominems, it contributes nothing to the discussion and just promotes anger.
I think I understand why WP is so popular; it optimises for the editing experience and for the vast majority of situations this is fine; building the website is cheaper and quicker, and the audience doesn't really care about a 200ms lag on rendering.
My confusion (and I never described this as anything but confusion, so I don't understand your reference to me hating users) is that in a process where we can do better, and use tech that is more appropriate, faster, etc, there is still a preference for WP. Even when the people involved don't have to deal with it. Is it just familiarity, or control, or what? If we have the chance of optimising for the reader's experience, I would think that that would be a huge plus, but apparently not. This is confusing, and a little annoying.
> Please stop with the insulting ad-hominems, it contributes nothing to the discussion and just promotes anger.
If you believe that this was an attack against you rather than the position that you yourself have laid out in these comments, it's time for some self-reflection.
Your commentary drips with disdain for the people you're ostensibly serving and it's as obvious to them as it is here.
Even in this comment, you don't care to examine why some people have a preference for WordPress, because you believe there's a better option. Truly the behaviour of the stereotypical arrogant developer.
You’re conflating two separate functionalities.
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.
They make choice, because they're the ones working with this daily. Their goal is to put content on display fast. Content varies a lot - often containing for eg. tables, which simply don't work well in markdown or images you need to host somewhere.
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.
Have a look at React Bricks. You can create content blocks in React and then the editors are autonomous with a visual editing interface.
Thanks, looks interesting. Something like this, but self-hosted would be pretty great.
In one case I offered to (and actually did) convert the Word docs they sent me to the appropriate Hugo markdown with front matter and push it for them (not a huge effort, maybe 10 mins per post, I was happy to do it). It worked for a bit but they still ended up pushing for a Wordpress site.
So yeah, it's not down to technical experience required for the edit process.
>It worked for a bit but they still ended up pushing for a Wordpress site.
Because they don't want to call you every time the need to fix a spelling mistake, or adjust fonts or colors or layout, or add/remove a section. What if you're busy or on vacation?
It may also be your personality - do you think you may come off as inflexible and arrogant to your colleagues?
Imagine you need to email code to someone to be committed :-)
I switched to a SSG for the ease of editing! Offline, version-controlled editing with regular expressions, linters and other text-based magic. When you maintain a few hundred pages for a living, this is a game changer.
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.
Except it is 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.
It always boils down to how many users you want to engage with your product.
The reality is that you can create a great product that engages with users, using transparent processes that can be tinkered by and with a ton of free customization features, you will lose a huge amount of market share to a competitor with a more simple interface (and probably a less efficient and more complex machinery behind it).
> 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.
You and marketers have very different priorities and targets, of course they don't reach your same conclusion
Most of the time annd energy spent on active marketing sites is content management. If marketing are the people with the budget and they are the ones who manage the content, that will be the priority. It makes sense. What doesn’t make sense is that there’s not(?) a better alternative that solves both sides of the problem.
>I'm always confused as to why these particular people get to be the ones who make the choice.
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.
Back in 2011 I built a JS-based thing for making essentially any website editable: https://bergie.iki.fi/blog/introducing_the_midgard_create_us...
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 a similar solution in SurrealCMS[1], where the user will edit their website pages in complete WYSIWYG. It works perfectly for clients who are not programmers, and should replace WordPress for about 99% of websites (except for blogs of course).
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"
> and costs literally nothing to host
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
> Costs nothing to host, but then you need to train every user, which demands time
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
I was surprised at how hard it was to find a designer who could make a simple html and css only website. Just having to dip my toe in this world for a good-looking but mostly non-functional website gave me all kinds of ick.
Oh, https://sumar.io is a form handler for static websites available under the AGPL.
> a form handler for static websites available under the AGP
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?
> but requires markdown files and a bit of Git to deploy
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.
Your comment is the height of arrogance and user-hostility.
The idea that they should accept a sub-par solution not of their choosing just for the developer's convenience is absurd.
I think you missed the point. It's not the developer's convenience. It's the readers.
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?
> It's not the developer's convenience. It's the readers.
The marketing folks and copywriters are being paid to post, and they have a manager and boss to report to - which can fire them.
I guess it's very much about convenience and ease of use to people writing the posts
Readers don't care at all whether they're served WP or a static site.
The GP doesn't have a point to miss.
Sure they do. They don't know about WP or static site, but they do know about "how long does the page take to load" and does the page work properly. It's certainly possible to build a WP set up that is super fast (and basically a SSG), but the vast, vast majority of them will not be done like that. They'll be loaded with a bunch of marketing plugins that kill performance and routinely throw errors that manifest to the user as some broken button or form that won't submit properly.
It's possible, but much harder, to build a static site that performs as poorly.
The golden rule. He who has the gold makes the rules.
My experience as well !
And even when we do give WP-like ease of editing with background static generation, editors still want WP, because this or that plugin.
> editors still want WP, because this or that plugin
So you are saying that you are still missing functionality
Nope, I'm saying they don't need this functionality.
But the editors want. So... I guess you are out of touch with your own clients. Either you actually don't know their needs, or you didn't take the time to sit with them to explain why they shouldn't have that
We don't have enough time to convince them against a whole ecosystem built around false assumptions. But we don't have to either, since we're in position to force them to change their methods. And the reason why we're in this position is because they've fucked up their WP install in the first place.
Elementor bought strattic, which offered static wordpress hosting. I believe they use this technology in their hosting offering.
Wordpress has plugins to generate static sites. You can have your rich editing and fast loading times as well.
Just use a polished CMS like Sanity and get the best of both worlds
The polished CMS nobody heard about :)
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.
Totally! The magic of using your print menu word doc as the website is its so little work to keep the site updated. No one really cares that a family restaurant in a Toronto suburb has a visually stunning website. You just want to see the menu, hours, address and phone number. It's always going to be updated, exactly the same content as the print menu that you actually pay from, and they already knew how to make things look legible in word.
It's actually even more charming than any solution we ended up providing because this particular restaurant (sadly closed now) was run by a 60-70ish year old man, who's cropped portrait photo was their logo, `float:left` in the header of their index.html exported from Word. I don't think you can buy authenticity like that.
I of course thought that was hilarious because I was 19, an idiot, with my first tech job thinking I'm such a professional cranking out CodeIgniter-based contact forms and static About Us pages.
Looking back, I'm pretty sure we did them dirty. Whatever solution we sold them on (IIRC, they got a wordpress site with a custom theme) was probably less useful. Which sucks.
I've been volunteering with a local political party to help them with their technology decisions, primarily on the web, and... based on this and prior experiences, I've come to the conclusion that agencies do their clients dirty quite often. In some cases it looks borderline intentional, in others I think it's a disconnect between client needs, agency capabilities, communication, and what's ultimately delivered.
It seems weird to say it since so many people rely on it, but wordpress is overkill for so many things. It frustrates so many clients to no end, requires ongoing maintenance that's quite expensive in some cases, and well, it requires an active server handling server-rendering and form submissions and such. The vast majority of clients simply don't need it. They don't even need themes.
This party I'm helping has something like 7 wordpress sites strewn about, all on hosts that cost way too much, some not even updated or maintained at all, sitting on servers that peak at like 40% utilization and otherwise hum along at near-zero utilization beyond what the wordpress isntance requires.
This is a lot of the internet. My experience with these folks has inspired me to build something that would meet their needs, but it's one of these things where... I don't know, if I build it, I doubt anyone would come. But yeah. Most people's needs for the internet are remarkably simple. Even Wix or similar are way, way too much. Yet those basic blogging engines totally miss the mark too. Most of these business users aren't interesting in blogging. They just want a simple home base where they can dump various types of information and let it hang out forever.
I can think of a few products which aim to fix this, but they aren't quite simple enough for the types of people we're describing. The people who know they need stuff online, but don't want to know much about it and don't want to learn much either.
I do consulting for a few restaurants, and despite my experience building full-stack web applications, I find myself reaching for Excel for most of my deliverables. These are "applications" that "non-technical" restaurant operators need to be comfortable in. Having a sheet where they paste in some data and get their needed output has required the least amount of continued maintenance and training. They can drag the file around in Dropbox / Google Drive and that works for them.
I still try to "engineer" to the best of my ability—separating raw input from derived data from configuration, data normalization, etc. With Lambda functions in Excel now, I kinda just pretend I'm writing Lisp in an FRP editor / runtime environment. The ETL tools with PowerQuery are quite good for the scale that these restaurants operate at.
Hard for me to turn off my brain in my full-time job when I am tasked with poorly recreating a feature that Excel nailed years ago.
It’s a shame that Access died, because that’s what you would have built this in 25 years ago, and it would have been better for your client in every respect.
> It’s a shame that Access died
Gesundheit? It’s still in Office 365 (subscription) and Office 2024 Pro (standalone).
You can create web pages in excel??
These are presumably more along the lines of custom inventory management software
People forget to keep track of how long it takes them to do things.
I see people bifurcated into "people good at time estimates" and "people who think time estimates are always wrong." The former have been keeping track, improved continuously, and have become good. The latter have no clue.
Setting up a website from scratch is not hard, but it is time consuming, especially when you throw in maintenance.
Bingo. This is why google sheets is the best cms. Just have a data pipeline that rips the data out and upload it the webserver
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.
Under the hood, the bones of that system are there! `PATCH` is a HTTP verb for a reason.
Though making the web this big publicly editable pile of documents would create a lot of spam. You already have to filter a lot if you have a form on a website, imagine if instead of filtering structured data, you had to filter diffs.
I think maybe a good half measure is just bringing web authoring tools BACK to web browsers! Netscape Navigator had one if I remember correctly. This would just allow you to write HTML files to disk though.
Bonus point for some standard protocol where you login with HTTP Basic Auth, and POST/PUT/PATCH/DELETE HTML directly to a page. You'd need some special server that understands that, but ideally it would be open for anyone to implement. You point your browser to https://yoursite.com/my/page.html and assuming you've logged in with HTTP Basic Auth, your browser suggests creating the page, rather than rendering the responded error page.
Edit: Protocol is the wrong word, someone correct me what this is really called. HTTP based... editing? A standard API? It's now something I want to make so I'll need to figure that out haha.
Edit 2: CamperBob2 in a sibling comment mentioned wikis. Just realized I'm describing a wiki lol
The term you're looking for exists: user agent.
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.
That's sort of the idea behind a Wiki, isn't it?
There was an effort many years ago to provide browser extensions that allowed users to mark up, edit, and annotate existing web pages in a way that would be visible to the community of users. It never went anywhere, unfortunately, probably because it would have gored way too many sacred oxen. (And/or it would have been co-opted by spammers, turning it into a social networking/reputation management project.)
Every so often someone announces that they've reinvented that idea but it doesn't go anywhere. These days the problem is probably mostly mobile Internet, but also the sheer difficulty bootstrapping enough of a community for it to be worthwhile.
And of course any such project that became popular would either ruin the creators as they try to keep up with moderation, or devolve into an unusable mess if they don't moderate.
I don't think that's true - Figma runs in the browser, so does HN.
The job of the browser is to _render_. That's agnostic on whether you're creating content or just reading it.
Back in the day mozilla (the browser, before the mozilla org made firefox) edited html in a wysiwyg fashion. All my early websites were made with it. I never did work out how to remove a <br>
SeaMonkey (the direct successor to Netscape Communicator and the pre-Firefox Mozilla Suite) still does.
Doesn't produce particularly modern HTML, but if you want to author HTML like it's 1999, it's out there.
I recommend reading the short book Weaving the Web by Tim Berners-Lee.
Yeah, that was a good idea 30 years ago, now the web will fill to the brim with spam and AI-generated drivel, all in approximately 14 minutes.
Nowadays it's more important than ever to curate content well.
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).
The electric utility in my area is this bad and worse. I once reported a power outage when the power wasn’t actually out (explanation follows) and they had no way for me to cancel the report when I realized everything was fine. I tried calling but couldn’t get past an automated “we received your report and are working on it” message.
(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.)
Heh, similar issue once, only no battery backup and the main breaker would trip instantly. So, we had power, but it wasn't coming back up. After an expensive discovery that the issue wasn't on our side, the power company had to get into the junction box and discover that the wire had melted to the metal. We were 'this close' to losing everything due to a fire. Especially because once the metal cooled down enough, the power could come back on for a few hours.
> they chose voice navigation (instead of keypad tones) for their menu
Most voice menus have hidden, 1-indexed touchtone mappings.
The only time I've had an issue with using the keypad is during the prompt that goes something like, "In a few words, tell me what you're calling about."
Hitting zero repeatedly at that point is usually the only way through.
I was at the T-Mobile internet trucks in Asheville and the woman next to me was obviously stuck in some automated voice menu hell — you know when some one is sitting on the phone quietly listening to whatever the question “What can I help you with?” and then answering with one clear word. I saw her sitting there like that waiting, then respond clearly, “Disaster!” I’m going to guess the system didn’t have a way of handling that answer.
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.
You can listen without a license. I was able to hear everything on a $15 handheld and it was immensely helpful.
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.
> You can listen without a license
You can also talk without a license, who's going to stop you? Especially in an emergency situation.
I don’t know anything about this topic, so forgive me if I’m wrong.
Would there be any risks associated with increased “free for all” amounts of radio traffic going around during a natural disaster like this? Couldn’t specific channels become cluttered to the point where signal is too disrupted to read, or is that not quite how it works?
I think there are thousands of frequencies. Traffic can split up into those.
What I want is for every smartphone to have an FM radio built in. There are FM radio IC chips available, and apparently some Android phones have them. It seems like a reasonable thing to require smartphones to have them for emergencies. I had to run my car in the beginning, burning precious gas just to hear on the radio what the hell was actually happening.
It might be selection bias, but my impression was that it is very hard to find a phone without this feature (going back to the Windows Phone and semi-smart feature phone era as well). The usual downside is that they do not spring to life unless a wired headphone is connected, because the cable is used as the antenna.
> unless a wired headphone is connected
aren't wired headphones increasingly unsupported in newer phones?
Yes, that is becoming a huge issue for me.
Indeed, most phones have the hardware already, but the radio isn't surfaced in the software.
Ah, yeah. I was wondering how it could work without an antenna. I guess an FM antenna needs to be larger than the 5G antenna built into phones too.
I owned a series of Moto Gs that could, but with the removal of headphone jacks I am not sure how much reception you could expect. I did manage to pick up FM stations without anything plugged in but only pretty close to a transmitter.
Some phones even used to have TV tuners in them, though I don't think any of them were sold in the US.
Back in Venezuela there we're at least 2 models of the Telepatria, A phone with TV Capabilities, if I recall correctly, both models being basically modified ZTE designs
The original model did come with an external anthena, and the latest model is from 2015, no anthena needed
Plain old AM/FM radios are cheap and super efficient. Everyone should have one! I have a portable radio that I use regularly and its AA batteries often last a few years!
CB is roughly 11m wavelength and doesn’t require a ton of power, and doesn’t require any licensing.
Do you have links to the text only news sites?
CNN is on https://lite.cnn.com/. The home page is a single 30KB HTML file (my browser also insists on downloading their 6KB favicon).
A thing of beauty, compared to their normal home page with 90+ files of 12MB.
Wow - that is the fastest loading site I've seen!
It's almost as if we all have supercomputers in our pockets which could easily handle text and images of only web devs didn't shove 10MB of code in an interpreted language every time time we open a page!
Half of the people on this site are those very same webdevs.
Which means pointing it out has a higher potential for bearing fruit. If we convince just one web dev to start thinking/caring about it, that's a win.
What's up with that?
Why would you rather build SUVs for soccer moms than race cars?
yup. I marveled at a cray y-mp 4 back in the days. now I use one as my daily driver, compute power wise. mind. blown. come to think about it...
No, you don't.
You use something some 200 to 2000 times more powerful.
http://frogfind.com/ Might be useful
Yeah, I should have posted that. This is the one I use the most:
I forgot to save the links to the others.
Wow it's amazing how noticeably faster than is that every other website. We really messed up the internet.
Speed is the most important UX feature.
I've emphasized this, repeatedly, to ~every product owner I've worked with in my 26-year career.
I believe it's morally wrong to make software that makes people wait needlessly. If your software makes me wait, it better have something to do with the speed of light.
Someone on here I think runs Plain Text Sports. I rarely follow games, but I like the idea of such a simple site.
https://text.npr.org/ text onli version of NPR (National Public Radio)
is also a nice one
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.
As a workaround, you can try using Opera Mini and configure the Data Savings option.
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.
Is Asheville in SV?
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?)
Asheville is in Western North Carolina
Thanks. Yes, that's what Google told me, too. I was just confused by andrepd's accusation.
well, people without 4G or a later phone model probably don't have the money for your $5 per month service anyways, so why care about them at all /s
I know you meant this sarcastically. BUT, when traveling, my phone has a free 3g, unlimited data plan. So, you run into these problems even in modern society.
oh, good point. actually had this experience this week. for some reason 4G/5G was unavailable and all i had was H+. NOTHING worked. couldn't buy a train ticket from my phone, websites didn't load etc.
all i was able to do was to send and receive signal/telegram/etc. messages...
> 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.
Maybe you just haven't found the right static site generator for your needs?
Jekyll is the most well known in Ruby space, but it's tailored to a specific niche - authoring a blog with Markdown or another lightweight markup language. You can certainly massage it into doing other things, but it's not that ergonomic as a general purpose static site generator.
If you want something that's easy to copy/paste into rails, a rack based static site generator like middleman is great because you can start writing with erb/haml and ActiveSupport from the very beginning.
If you're looking for the simplicity of handwriting HTML and CSS but you want some niceties like includes, partial templates, link helpers, nanoc is a good static site generator that's progressive. Start with plain HTML/CSS, only add additional features as you need them.
> Even as a programmer, I've fallen into the static site generator trap a few times.
> It's annoying to start a side project with a static site generator and then realise I want to add a small feature and suddenly I wish I'd just started with a simple Rails or PHP app.
Hard to discuss without examples. I started using Pelican over a decade ago, and am still happy with it. Every once in a while I write code to customize the behavior, but it's once every few years. It's simple and just works.
There are things I miss from dynamic sites, but I don't see how a simple folder of HTML files is in any way superior to Pelican...
I've been posting to my personal website for 20+ years and it's been something like: basic HTML -> Drupal (whew) -> Wordpress -> basic HTML (via Jekyll).
The fundamental rule I've set myself against feature-bloating in my website is defining what I want it to be: an archive of things I've done. As an archive, I want it to be very durable in time. Thus, static file that are dead-easy to copy around, mirror and make it work in any hosting platform.
It did take me a while to nail having a bilingual site, though :) but at least it's a price I paid once.
For blogging I use Hugo because it is just easier to focus on content, not on style. That is why I don't like writing pure html files. Changing style can also be a problem, if something is hardcoded into html file.
For more advanced tasks I write in django, because it so easy for me to add features.
> Nowadays, if I want a static site I just start with a folder of html files.
Same here. I've considered adding a .md —> .html step for content, but just haven't found it necessary — yet.
> The other cool thing...
I like being able to—easily—view my site via a local sever. The best case would be one that I can view via file:// too, but I couldn't quite crack the organisation and ended up with a 'make local' step that generates a separate copy for file-based viewing.
I run a blog for an organization. We do one post per business day on average, with typically around 3 posters. I set it up years ago with Django/Wagtail/Puput and it has happily chugged along ever since. I can’t imagine how annoying it would be to manage if people were creating their own new files for every post and writing their own HTML…
But you've had to maintain that Python/Django stack, as well as a server.. Right?! I've done hundreds of Django release upgrades. They're not automatic or time-free.
Most SSGs, especially those geared to blogging accept nicer markup systems like Markdown. Keeping track of things, even in a multi-user system isn't hard.
Getting non-technical people used to a git workflow is the hardest part.
Now I'm wondering what kind of features you end up adding to your website that need server-side code. Comment systems?
How about a contact form?
Here you go:
<form action="mailto:someone@example.com" enctype="text/plain">
In an ideal world yes. But from past experience many users have the association for mailto links misconfigured.
It's a terrible user experience.
Yes, it depends on the target audience. For a personal website which the article was about, it would probably be fine for most hacker news users. If someone can’t manage to send me a mail, they probably wouldn’t see my website anyways. If you do your grandparents personal website, a proper form with a backend is better though.
How are you handling commonality between pages with plain html pages? As long as you don’t use iframes, you have to manually sync everything that’s shared or almost the same on alle pages (header, footer, navigation). That’s pretty annoying.
> How are you handling commonality between pages with plain html pages?
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.
<?php include("header.html');?> You only need to allow PHP to run in .html files (if you insist your files being named .html(
That’s what you would call
> Nowadays, if I want a static site I just start with a folder of html files.
? With that argument, we can also calculate 10 million digits of pi in HTMl by renaming our C files to .html. If someone tells me they’re using a collection of html files, I’m assuming they mean static html pages without server side scripting.
Pretty sure parent didn't actually mean plain html files for everything but if they did then perhaps they're using server side includes.
Yeah nah, for me it's exactly that: plain html/js/css files. For simple things, I copy/paste.. not a big deal.
If it's getting more complicated, I'll abort and upgrade to rails to use layouts etc.
The middle ground of static site generators are a trap in my personal opinion.
If I need to add a feature, I've found it's easier for me to implement it directly rather than try mess around configuring a static site generator with plugins etc.
Amusing how underneath this comment, there are several comments saying "ah, you just haven't found the right SSG, this one is good". Well-intentioned, but completely missing the point.
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.)
But doing it the ridiculously complex way is something that professionals can't afford not to do.
I think the tide is turning, as people are starting to realise the fragility of complexity.
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.
> But doing it the ridiculously complex way is something that professionals can't afford not to do.
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.
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.
Nice stack, but are you really using it to make complicated enough sites that TypeScript is much benefit? Drop that build step baby.
I run with `tsx [-w] src/main.ts` and `vite [build]`, so it's not that much of a step.
But in general, yes, ts is much benefit. I use shared typings for cross-end calls/returns, mithril supports full component typing which is useful, the whole devtime becomes more lively.
I'd agree at webpack 4 "zero" "conf" times, but rejecting ts now returns nothing.
The killer app of WordPress is comments. No SSG, almost by definition, allows comments; WordPress blogs almost always come with them built in.
If you want something like Hugo to really take off in the blogging sphere, all you need to do is create some good looking themes with comments. Figure that out at scale - maybe by using per-blog sharded SQLite, which you can host as a third party for pennies on the dollar - and you have a tiny golden goose on your hands.
I think that was true during the age of the blog, but far less so now.
Comments and discussion of a post are to be found on third-party communities like Reddit, HN, or even Facebook. How many of us scan the list of comments under, say, a Substack post vs. will scroll through a page or two of HN comments for the same post?
IMO it's a foregone conclusion that a discussion on HN will be higher quality for a tech-related post than a comment chain on a specific post, since HN has already attracted a wider set of readers than 99.9% of all blogs.
The main advantage of commenting directly on a blog post is that the author is far more likely to see it vs. the ephemeral state of the post being on the HN front-page.
The more people join a social media site the worse the conversation gets.
This is already happening to HN as tech people flee Reddit.
Most of the new comments on any given post are people that didn't read the linked content and complain about stuff addressed in the second paragraph.
This is an evolutionary process where the commenters that get the most engagement are those that are first to respond or react. First-mover advantage entrenches itself as those posts are boosted higher due to the engagement they receive.
Those that think deeply before responding are discouraged when a well-thought out comment is buried beneath a sea of first impressions.
This reward cycle is amplified by more people, because engagement is very unequal on platforms that share a top comment or front page for everyone. You either make it to the first few comments or get nothing at all.
Sites like Discord or Facebook try to counteract the monopolization of engagement by an impulsive few by splitting users into smaller groups. Less competition for social interaction creates more diversity in winning strategies. Evolutionary pressures still exist, but you don't need to perfect a "winning strategy" solely to interact with other people on the platform.
Contrast Reddit or YouTube videos. The concentration of attention means it has monetary value due to SEO, product reviews, or advertising. The value of a large audience makes a platform more competitive. Competitiveness means many YouTubers and Redditors professionalize attention-seeking behaviour. This comes at the cost of quality.
Most of the new comments on any given post are people that didn't read the linked content and complain about stuff addressed in the second paragraph.
Almost everyone does that since I’m here and that is at least for 10 years. We even have a thread about it from time to time. HN is absolutely fine and didn’t change that much cause it disincentivizes attention seeking, at least cheap one. They may slip in from time to time but mostly get a cold shower from users and mods. Also this forum is much more tricky than it seems, from a technical standpoint.
Yes but that's okay at a smaller scale where all the users are more aligned and there's less karma to get. HN now is big enough that gaming the karma system by commenting quickly with rage or nostalgia bait is a winning strategy and for most general appeal topics on the site these days that's exactly what happens.
Part of that may be you learned to detect these behaviors and not always correctly. Another part may be old commenters getting nostalgic and/or angry (a thing in life).
Did my homework though and checked top ten threads and their first comments where all these karma people should be. All top comments are pretty HN spirited. One of these may be called nostalgic but has a specific request in it and doesn’t look like a bait.
Part of that may be my perception problem.
Yeah these things are all pretty relative of the reader's perspective. FWIW I mean this specifically for the less technical threads. Technical threads still seem to rank contributions appropriately. But the moment you touch on something more cultural, like the long term computer thread, or the Mr Beast thread from the other day, you get a lot of pretty low signal comments that get a lot of karma. I do find that the very top of the comments page stays okay but the moment you get past the very top you get lots of low effort comments.
> Those that think deeply before responding are discouraged when a well-thought out comment is buried beneath a sea of first impressions.
A specific capability oh HN, that I take advantage of often, is being able to skip thread branches. It’s not uncommon for me to go a few messages, think “Nah”, tap “root”, then “next”, and, boom, a 100 first impressions vanish in a click of disinterest.
It’s a really great feature and can act as a crude filter for first impressions.
Exactly. Sometimes you see that a subthread goes sideways and just parent/root [-] it, and you’re back in the thread without parsing through non-interesting parts.
That feature hasn't been around for very long though (12 months ? two years ?)
Like our ancestors before us.
> This is already happening to HN
This is an ongoing theme since I first checked out this website, which was in 2008 or so.
[flagged]
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?
At work, all the Web sites that we have placed in production are CMS based, although not cheap ones, so some folks in HN do get it. :)
Liferay, Sitecore, Dynamics, SharePoint, AEM, SAP, SharePoint, Optimizely, Contentful, Sanity,....
100% of small businesses who currently use WordPress are better served by an embedded iframe when they need something more advanced than static.
Have a restaurant and want to offer take-away online? That's going to be an embedded iframe.
Have a small hotel and want to let guests book their rooms online? That's going to be an iframe from Sirvoy, or a horribly bad Wordpress plugin.
Have a dentist office, or you're some kind of freelance consultant and want to let people book and pay times? That's going to be an iframe.
Have an actual blog that is popular and want to make a paywall so that only paying subscribers can read? This is where WordPress will shine right? Go and buy such a plugin for $200-$300 and later tell me how your experience was. Even for this basic blog functionality WordPress is a horrible mess.
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.
Another "interactive" part: contact forms.
Not every business site wants comments, but they'll probably want a contact form. Putting an email address out is an alternative, but handling the input pipeline is better.
On a static site that requires finding a service they trust to handle the submission and correctly plug it in their site. It becomes another moving part, potentially another bill that needs to be paid separately, another bit to deal with when the industry consolidates etc.
More often than not, the contact forms that I encounter impose one or more hassles on the visitor:
Please enable JavaScript. Please allow scripts from these off-site domains to execute on your computer. Please enter a return address hosted by an approved email provider. Please read through all the categories in this drop-down list and select the one that best fits your message. Please fill in these required fields and re-submit the form. Please unblock challenges.cloudflare.com. Please waste your time repeatedly solving annoying puzzles, until our CAPTCHA provider can sufficiently fingerprint you and your browser. Please re-type the text you already entered, because we reset some or all of the form fields due to one of the above complaints.
No thanks. If I'm at a contact page, it is most likely because I have something of value to the site owner, such as potential business or knowledge of something broken on their site. If they expect me to jump through hoops, I won't bother.
In principle, contact forms could be nice enough, just as many web sites could be clear, simple, quick-loading, static pages. In practice, they're generally a burden.
Given that they don't offer much to the visitor even in the best case, I would rather just see an email address.
Yes! It's a plague that's hurting most generic content submissions services.
Most Saas in that area can't see the difference between a freelance portfolio site where you can send work offers and the support form of your local telecom where people will send death threats.
At the end of the day, for the lambda user it's just better to have the forms handled on the same platform as the site (wix, squarespace etc.) than dealing with a generic solution elsewhere.
> email address
On the receiving end, the advantage of the contact form is to map it to something else that email (Google Sheets etc.). Of course you can set an automated email box that will process the incoming mail into something else, but that's just an additional burden.
These hurdles only exist for the 0.0001% of people who deliberately hampered their own web experience in an attempt to reduce ads or tracking.
I gave eight examples (which themselves are an incomplete list). Nitpicking at two of them while ignoring the rest, and projecting fault onto people who experience them, doesn't refute the overall point.
This is worth a read:
An email address is the best contact form.
Anything else is overengineering.
Email has surprising hurdles IMHO.
For instance it means leaving the browser and have the default email client handling it. For some people it becomes a distraction, for other they didn't even setup the default client so it's a setup screen and hey have to copy/paste the email to their gmail tab.
Other people actually don't want to give their email but will give a phone number, or their Twitter handle, a chat ID, or their address, or anything else really.
A form is more maintenance, but can be pretty beneficial to address a general public.
People who contact your business by e-mail or contact form are immensely much better customers than people who contact through a chat message or such. As a business you want to deal with e-mail customers and not WhatsApp/Messenger people, because 9 times out of 10, the chat people want an answer to a question and won't even say thanks after getting the answer and of course will never become actual customers.
The browser is the email client for most everyone.
For everyone else it’s the gmail app.
This may blow your mind but you can have static pages AND a dynamic endpoint for form submission. You could even put such endpoints under a common directory, /cgi-bin/ perhaps.
Just let me put a blinking "under construction" gif on my form page while I'm trying to figure how this cgi thing works.
Disqus solved this for a while, but they did various things over the years to push people away: https://en.wikipedia.org/wiki/Disqus#Criticism,_privacy,_and...
https://hn.algolia.com/?q=%22disqus%22
Facebook offered a commenting system a lot of sites used, but it also lost trust and reach with its scandals.
I'm also seeing a moderate number use javascript to pull activitypub replies, as those APIs are (generally) public and GET-friendly. And don't have the various spam-rolls that other free options add.
There are similar-ish tools such as Isso. Self-hosted, no snooping, stored on SQLite. https://isso-comments.de/
You can use GitHub issues for each blog post and then use it for comments. See here: https://www.richyhbm.co.uk/posts/using-github-issues-as-comm...
Grate post! Hey, check my websight about "WordPress blogs" at https://www.sevarg.net/ I think youll like it! ;)
Are you sure comments are still desirable? Isn't step 1 of the internet anymore "Never read the comments"?
That said, I did actually work out a solution for "static site with dynamic comments" on my blog that could easily be done for a lot of people if they're willing to use a hosted service. Discourse (the modern forum software that a lot of places moved to after PHPBB) has a way to integrate with pages for comments, and so I've been using that for at least three years now with no real trouble. I host my own Discourse install (I'm weird, I still have a server racked up in a datacenter), but there's no reason you couldn't pay someone else to do that and provide comments.
Interestingly, the amount of spam I've gotten with my Discourse comments is a tiny fraction the amount I got even with Blogger back when I was hosting there. It's just not a big problem anymore for me, and it was a constant annoyance with PHPBB forums and Blogger.
The rest of the site is just Jekyll, based around a template I bought (because I can't make a decent looking website). I've then hacked on it a lot over the years to make it do things I want (responsive images, mostly - I'm still sensitive to people on low bandwidth connections), but it's not bad at all in terms of maintenance. Just launch a render job and some scripts upload the new files.
>Are you sure comments are still desirable? Isn't step 1 of the internet anymore "Never read the comments"?
It very much depends on who you ask. As a reader, I always check the comments on an article. It's easily 75% of the fun of the Internet to me, more so if it's a shitshow. I can understand not everyone feels the same. I've been hearing for years from many different people how Twitter is a garbage dump, but to me it's no worse or better than any other place where people can respond to each other.
Of course if you ask this question 3 levels deep in a comment thread this is the kind of answers you are going to get; survivor bias.
I don't think so. Comments used to be a big deal, but these days you sign up to handle a lot of spam and moderation issues.
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?
There's several solutions for comments, as documented here: https://darekkay.com/blog/static-site-comments/
Perhaps Disqus? I believe it's opaque to the site owner - users auth to Disqus, you don't need a db.
Can't you just spin up an imageboard instance and put a button at the bottom of an article?
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.
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/
I've just started doing the same for one of my websites, 90% html but php for headers and include() for a few odd global bits.
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.
>>> 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.
You just described Micro.blog[1], don't you?
> When I published SuperHTML, I discovered that it was the first ever language server for HTML that reported diagnostics to the user. I wrote a blog post about it, it got on the frontpage of Hacker News and nobody corrected me, so you know it's true.
Probably because this is something most IDEs have been doing for years, before Microsoft came up with LSP.
Of all the most popular editors, I think none of them had a way of offering diagnostics for vanilla HTML. The only exception that I know of is Webstorm.
Vim, Neovim, Helix, Zed, VSCode all shared the same basic implementation that has no diagnostics support.
Helix will have SuperHTML enabled by default starting from the next release: https://github.com/helix-editor/helix/pull/11609
I wrote IDEs not editors, and I am quite sure that the years doing ASP.NET and Java EE/Spring development I had enough HTML diagnostics to fix since 2001.
> If you didn't know any better, you would expect almost all normal users to have [2] and professional engineers to have something like [1], but it's actually the inverse: only few professional software engineers can "afford" to have the second option as their personal website, and almost all normal users are stuck with overcomplicated solutions.
I am confused, the inverse would be that professional engineers have [2] and normal users have [1]. But then they write that almost no professional engineer can "afford" [2], so everybody seems to have [1]..?
If you continue reading, the reasoning is given in the next sentence:
> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps.
Comment was deleted :(
I suppose they meant that only a few people, who are professional software engineers, can afford the second option.
It is indeed written as you say; I suspect - but cannot confirm - that the author meant:
> ... only a few people - professional software engineers - can "afford" ...
which would be the inverse.
However, there is a case for reading as it is written even if it subverts reading expectations, as many (most?) professional software engineers do use COTS systems to publish and only a few have their own sites generated from scratch.
Somewhere down the line the ease of publishing changes is the differentiating factor which should have been accounted in the comparison
i read it as: "can't afford the overhead of complexity of running such a complicated stack for my personal x"
Yes. That is confusingly phrased. Took me a sec too.
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.
> The author thinks that value come from realized utility.
For the majority of the world, Wordpress indeed does provide more utility than an SSG. Wordpress is famous for their 5 minute installs, and then everything just works.
_realized_ utility.
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!
It seems that people pay for Ghost, https://github.com/TryGhost/Ghost
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.
`<!DOCTYPE html>` is not an html opening tag. It is a preamble.
`<!DOCTYPE html>` is not paired with `</html>`. This is what the basic HTML5 boilerplate looks like:
<!DOCTYPE html>
<html>
<!-- content goes here -->
</html>If it complains about an unmatched </html>, that's fine. But you can omit <html> as it is an implied tag: https://html.spec.whatwg.org/multipage/semantics.html#the-ht...
> 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.
According to the specs the <html> tag can be fully omitted. From MDN [1]:
> 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 knew that that the <html> tag can be fully omitted (and some others, like <body> and <title> IIRC), but if I read that it can also be partially omitted. So you're allowed to open it but not close it, or close it but don't open it. That's new to me.
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.
SuperHTML README says:
> 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.
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 an engineer's view of simplicity.
A normal human being is going to see something like a checkbox to enable comments as being amazingly simple.
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).
I did that for a while, but I kept running into annoying edge cases with those plugins (or other wget-based solutions).
Static sites are great until you need to have a contact form or want to add basic comments. Yes, you can deploy javascript that uses external services to add such functionality to static sites- but with a basic WordPress site, you get everything right out of the box.
A contact form is a terrible alternative to an email address. Many sites have dropped comments altogether. Yes, these things might be nice-to-haves, but they shouldn't be the factor that determines whether you have a static site or a scripted one.
I have to politely disagree. If you ever run a website for business/portfolio etc. the number of people more likely to contact you using a contact form is far greater than just telling them to email you. Contact forms also scale well if you need to categorize and channel the queries to different people or need more specific info.
Fair enough. I would argue that we're probably talking about different use cases. If you're at the stage of categorising and channelling queries to different people, your site is probably already "heavyweight" enough to justify a backend anyway.
Yes, and almost all clients will ask you to put a contact form on the site.
Nothing stops you from embedding a contact form on a page.
Netlify event has a built in workflow where they will record the action so you do not have to setup any infrastructure.
> Many sites have dropped comments altogether
And many still have. I think most wordpress.com and blogger blogs have comments on
I came here to write this exact comment. The article is wrong in assuming that WP is wasteful. It gives huge optionality to the users: engineers probably can afford going with a static page and then changing the entire architecture of their webpage once they need some interactivity, but non-engineers want to go with a scalable solution: where they start with a contact info and slowly end up with a personal shop or whatnot without reinventing the setup at each phase transition.
Speaking of optionality and opportunity costs: many engineers are trained to see the unseen opportunity costs in technology ("YAGNI" and "tech debt" are often used terms), but often fail to see the economic opportunity costs: those that would waste time and cognitive effort of human beings, not the machines. Example: many engineers like to fantasize about micropayments architectures "because efficiency", but people cannot calculate those. They are better off with a nice round monthly subscription just to minimize number of microdecisions they have to go through daily.
> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself? Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.
I think the better word for this is "straightforward"; see the Mythical Man Month:
> For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice.
> Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.
> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps
Or you could just use publii, an office suite of your choice, or type bad html and css by hand, then pass raw files on very cheap hosting providers, enjoying a clunky, and sometimes ugly, "website".
The industry for this use-case works on looks and discoverability: the dichotomy of the WP big bloated piece of crap vs static clown generators stands upon having a pretty website which is also functional for Google. Any other alternative (like the builders or the directories) works the same but they also forfeit property of the site from client. It's just because these solutions are pretty for cheap, it's fast fashion.
> Or you could just use publii, an office suite of your choice, or type bad html and css by hand, then pass raw files on very cheap hosting providers, enjoying a clunky, and sometimes ugly, "website".
WordPress folks are working to enable static generation using WordPress Playground. It will work pretty much like Publii does today.
https://github.com/WordPress/wordpress-playground/issues/707
It's a good starting point. Quite late at the game after strattic, cache plugins and offloading queries on sqlite, let's see when and how will they play out with unavoidable interaction parts like contact forms.
The reason SSGs are primarily interesting to software developers is that the software architecture of the site is primarily interesting to software developers. Other people (both authors and readers) don't care how the pages are produced, they only care that the pages are there.
> Other people (both authors and readers) don't care how the pages are produced, they only care that the pages are there.
Readers, sure. Authors? Absolutely not true. Some authors might not be tech savvy enough to know better, but they are immensely influenced by the process of getting the content online. That's the whole reason why there's a huge industry around publishing content on the internet.
The author mentions that WordPress charges for everything, but after migrating off WordPress to a static site, I've found most of the features WordPress bundles together are, in total, more expensive when paid for separately. WordPress.com is $300/yr for a business account, which includes domain, newsletters, unlimited bandwidth, etc. The cheapest provider of blog->email newsletter for > 1k subscribers is already as expensive, not to mention the domain, netlify plan (or overages on the free plan!), a hosted comments service.
I'm not complaining, but after a certain threshold, unbundling is much more expensive.
You don't need netlify, Github pages or Cloudflare pages would do just fine. Email is a problem though and I'd wish you could easily integrate with your own email provider (ie: Fastmail, Gmail, etc..) to send newsletter to your 100s of subscribers.
I use ConvertKit for the newsletter. Its pricing is far more reasonable than MailChimp and the like. But in general, mail is more complicated than it seems, and I ended up giving up on self-hosting it.
> Find an SSG (or handcraft everything yourself)
I think this came a bit too late? Astro solves this well, there are other solutions too. From startups building webflow-like SSG platforms to frameworks like astro that requires basic markdown and html.
Yeah, I’ve found Astro to be the perfect solution without compromise. You can have a 100% static site without JS, and you can add in JS only as needed.
It doesn’t feel heavyweight like similar/older SSGs doc and it lets you write TSX-like syntax for reusable components (which I really like).
Plus it is easy to plug in a CMS if you need to upgrade for a team solution involving non technical people
There are a number of sites I wouldn't consider using anything but a static site generator for, including marketing websites, blogs, docs, etc.
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
Maybe I misunderstand, but this feels misdirected. As someone who's employed by "greedy clowns" (web development agencies I guess?), I continuously observe that people pay for what saves them time. Our entire profession is built on this premise. If you have a person doing interesting things, does it really matter if they write their own HTML or pay someone else to write it?
The web is turning increasingly monolithic entirely thanks to the modern social network conglomerate. That has nothing to do with the choice of technology.
> As someone who's employed by "greedy clowns" (web development agencies I guess?)
Maybe click the link so you don't have to guess (wrong)?
Am I wrong? I did click the link. I'm just assuming that the author of this post is not explicitly referring to two particular greedy clowns, but more generally to the WordPress ecosystem. Because it's actually very easy for normal people to avoid being locked into Automattic and WP Engine in particular.
Edit: just made the connection between the domain of this post and your username. So really just wondering what you meant specifically.
> Whenever we fail to make simple things easy in software engineering
Mandatory Rich Hickey "Simple Made Easy" link => https://youtu.be/SxdOUGdseq4?si=IY8mWzR3C-ru5Das
"This keynote was given at Strange Loop 2011, and is perhaps the best known and most highly regarded of Rich's many excellent talks, ushering in a new way to think about the problems of software design and the constant fight against complexity."
Absolutely true, I tried to build a static blog, tried quite a few static blog generators, for each of them there was something I didn't like, ended up building my own on expressjs. Practically reinventing the wheel, by creating a website and a simple crawler with a few addons, that puts everything on Cloudflare. I assume the average Joe would go for the Wordpress solution, for very good reasons.
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.
I find the WordPress / static duality in this thread amusing.
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/
> Weird as it might be, it's not a great mystery why that is: it's easier to spin up a Wordpress blog than it is to figure out by yourself all the intermediate steps:
This doesn't explain the difference, why would you have to figure it out yourself is some other company could just as well sell all those services, just with an SSG?
Strongly agree. Wordpress brags as powering whatever % of the internet... but if youve ever taken a look at some of that PHP source code... yikes
Mind boggling to me such an overly complex system has such a large market share.
I'll take my Gatsby TypeScript React components / <<insert your favorite static site generator here>> any day
If they calculated the % in terms of CPU time used, they could have made the claim even more impressive.
Depends if you only include server CPU time or also browser CPU time. With the latter, more "modern" frameworks will "win" by orders of magnitude.
Technical purity does not win business. Solutions do. WP has delivered a rich ecosystem that lets normal people put content on the web. Even if it annoys programmers at its technical debt.
This opening statement is confusing due to being stated as an axiom. From my experience, the majority of IT engineers considers the opposite true:
> 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
GH/CF Pages are only "free" if you have no/minimal traffic. Also, even that free tier will go away if you start popularizing it as a Wordpress alternative or make the barriers to entry lower. Let's keep it free, please
I chose the second option and I am really happy for it. I already had a server for my Nextcloud instance and adding one more Nginx reverse proxy to it was essentially free.
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.
A professional software engineer would never think of a static site as a personal website.
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.
Why would a professional developer never think of a static site as a personal website?
Because when you have the tools/technologies to do things dynamically, you forget to do things statically with your bare hands.
For a friend I made this: https://en.hayovasweets.com/
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
There is no such thing as perfect software. Everything comes with tradeoffs. Except, of course, for mkdocs.
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.
Yes, static websites are great! I'm using Jekyll with GitHub - it's 100% free. I agree, though, there is a learning curve.
I've been doing this too, but as a Python expert who always meant to learn Ruby but never really got around to it, I hate having to wrap my head around the suite of Ruby development tools (Bundler and the Gem system etc.) to do local builds, and it's currently taking up a seemingly absurd amount of disk space when this is the only reason I have any of it installed. Considering switching over to Nikola soon so that I can just use Python in the ways I'm familiar with.
I'm using hugo. It's great.
I agree: I've tempted the all-from-scratch way in pure html for my small web corner and well, I give up, it's simply too long to craft a modern website on basic html. I've tried an RSS-only corner but obviously it's not visible, ending up in Hugo/org-mode simply because it's ready made even if needlessly complicated.
This person seems to be suffering from the Curse of Knowledge. It’s unsurprising to me that non-technical users will gravitate towards the tools that look like what they know (packaged software with forms and buttons) instead of something that they’ve never once looked at (except perhaps in anguish).
Time for Joel Spolsky to bring back CityDesk: https://www.joelonsoftware.com/2016/12/09/rip-citydesk/
There is still not a censuses as to the definition of a static website. Is a website without a MYSQL database still static if it has JavaScript or php template include files? A pure static website in which each page has to be manually edited would be a headache.
There definitely is a consensus on what static website means. Have you tried doing a basic Web search of the term?
> 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.
Here's me waffling about this question for about four paragraphs, copied below for your reading pleasure :p :) (source: https://www.evalapply.org/posts/shite-the-static-sites-from-... )
> What is a static website?
> Static simply means as-is. Its inverse is "dynamic", meaning in-transit. The "static" part of "static website" corresponds to stored information. The "website" part corresponds to where from and how, the information gets to one's computer. A web-site is literally a place (site) on the World Wide Web, whence our computer has to fetch the information we want.
> Fetching information, such as a web page, over the Internet is "dynamic" by definition. Even just opening a file on your own computer's disk is "dynamic". The very act of reading a digital file, and/or transmitting it, means copying its bits from one place and showing them in another place 3.
> The Ultimate Static Site, is a file that once written never changes. Thus, once-received we never have to fetch it again (unless we lose it). Reality is of course not so simple. But we will work with the "static means never changing" mental model, because we can go pretty far with just that.
IME, the closest definition is simply a site containing flat files only. No server-side scripting, but client-side JavaScript very much allowed. That doesn't necessarily mean 'manually editing' each page, although some writing probably has to be done at some point, unless you're outsourcing that to an LLM...
What about fully client-rendered templates/sites that require JS for visualization? (ie, no graceful degradation at all).
Technically static, but absolutely of the worst kind in my opinion.
I totally agree — technically static, but an abomination that should be avoided at all costs!
An abominable default, sadly.
This is the first time I've ever heard of somebody being confused about this. If the server is serving dynamically generated documents, then it isn't static. A static website can be perfectly represented as a directory of files being served by python -m http.server. No PHP templates, that should be obvious.
I agree with you; not even SSI.
> There is still not a censuses as to the definition of a static website.
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.
Static website serves you everything you need as a one HTML file. You can save the source code and open it offline and there will be no difference.
As such any templating is out of the question if that is done via request from the client.
How I manage my static website is with a build script. I write my content in markdown with a option for custom header and then I have a python script that churns out pure HTML with everything embedded into it which I can then host on github pages.
This, but without the "one HTML file" restriction. Unless I misunderstood you—did you just mean "one HTML file per URL"?
IMO, the pages can be compiled statically on a static website, so the HTML doesn't need to be manually edited for each page. But yeah, I guess there are degrees of staticness. My (brand new) personal website is literally all written from scratch right now, but soon it will probably be pregenerated from Markdown sources. I would still call that static, but to a lesser degree.
Good question, with answers ranging from "a bunch of hand-edited HTML files" to "a set of HTML files generated from a non-HTML syntax such as a markdown derivative or a programming language's object-literal syntax", with the latter (static site generators) being quite different from the former.
And then there's also SGML which has everything HTML, as a last-mile markup language for delivery to browsers, assumed to have available for authors, such as text macros and shared fragments for eg. menus, auto-generating document outlines for page navigation, processing markdown into HTML, filtering into RSS or SERPs, etc., and even moderately complex dynamic site features such as integrating external/syndicated content and screening/validating user comments for malicious or other undesired input such as script, broken comments, external/spam links, and the like.
Surely a static web site is one that could be downloaded with something like wget or curl and would still work by browsing the files directly from the file system without needing an actual web server?
Thats what I expect a static site to be too. Along with preferably as little js as reasonable.
What?
A static website is a website that has no server side generation. That's how simple it is.
I would say a static website is just one that doesn't do any extra work on the client to generate the content. Either SSR or just plain HTML files
A dynamic website is generated by the server in response to client queries. Static websites—pre-existing flat html files served as-is to viewers—came first, then PHP and CGI made dynamic websites possible & popular. SSR is the very definition of a dynamic website. Client-side scripting came after dynamic websites, but it is not technically, in and of itself, "dynamic."
The trouble is defining what "the content" means. Are you saying "no JS" — if so, just say so! Otherwise, how are you distinguishing between "content" and ... "other stuff"?
> There is still not a censuses as to the definition of a static website
Static website can be served by `cat index.html`
> Static website can be served by `cat index.html`
For sure, but that's not a sufficient definition. You need to add some constraints to the contents of the html. Otherwise, you can put a huge javascript program in there that hallucinates a new page each time you render it. This shouldn't count as "static".
It generally does count as static though. In this context static has a technical meaning, not the dictionary definition. It's static from the server side, meaning that you don't need any special logic to serve it.
> This shouldn't count as "static".
Why not? If it doesn't, where do you draw the line, apart from "absolutely no javascript at all"?
That's a good line to draw!
Static = no scripting (either server-side or client-side)
I'd like to reserve the term "no scripting" for that :) I guess if we popularise the term "no backend", the two could co-exist. I want to talk about sites that are just a collection of flat files, with no server-side processing; for me, "static" does that job perfectly.
That is static though. It may not conform to a particular notion of aesthetic purity, but a website is static if and only if you can serve it from a static file server. Client-side scripting is orthogonal to that.
Or people could find a middle ground and join
Simple, has text-focused CMS, lightweight and content generated is static. Plus, dev is a nice guy.
The same (pros use less, consumers pay for more) goes for internet connectivity. A techie knows he will never need or saturate more than, say, 200mbps. While a consumer will see the "200/500/1G" offer and opt for the middle.
Lol no. Faster speeds are quite useful when you need to download something in a pinch and a single 4K video stream alone can easily eat up more than a quarter of your 200 Mbps. Consumer internet prices also do not scale linearly with bandwith because the provider knows that the average usage does not scale linearly.
Also, a pro would know that it's Mbps (megabits per second) and not mpbps (millibits per second).
Before there was WordPress, the most popular blog CMS was Moveable Type. It had a "generate static files" option. (I believe this is how Daring Fireball is still published today.)
Surely this is the "best of both worlds" answer?
If you cache the rendered content then almost all of the advantages of a static site go away, particularly if you are a platform and can amortize the infrastructure cost over all your users.
You say all of the advantages go away, but I read, “if you put in extra work you can achieve some of what static sites get for free”.
Which is kind of funny as the main advantage of static sites is fewer things to worry about.
The article is about how static sites are too complicated for normal people to set up, so people aren't getting those benefits for free because it's too hard for them to do.
Edit: The other thing is that non-technical users want a WYSIWYG editor. They don't want to edit markdown or html text files. So once you have all the infrastructure in place to support that it's not really any more complicated to make your customers' webpages dynamic as well.
You and I seem to have interpreted the article differently.
I read it as static sites are simpler, but paradoxically less popular because the additional parts of hosting a website are hard (getting a domain, hosting, deploying).
> So once you have all the infrastructure in place to support that it's not really any more complicated to make your customers' webpages dynamic as well.
To me, this is the exact problem the article is pointing out, lol.
99% of website could be a simple static page, but instead waste resources with complex CMS, database, caching, heavy front end layer, etc.
The Hacker News site is (a) "static" or (b) "complex"?
A case of irony?
Hacker News is a social network application, not a blog.
Wouldn't a blog be generally simpler and, thus, generally comparatively a better candidate for a "static" site than "a social network application"?
The Hacker News pages are "static" -- correct?
For my startup's Web site, I wrote the code in ASP.NET and made the site "static" before I heard about "static": So, "static" is okay with me for what I did write. When I finally (whew!!) go live, I hope the candidate users will not mind, or even notice, that the site is "static" and not single page. Today, do nearly all users expect a "single page" site and not like "static"?
Last time I checked, my pages send for ~44KB per page, and I'd guess that that is comparatively small?
If only as a user, a single page site can be amazing, subtle, surpising, not really intuitive or obvious, but by now there may be millions of such sites with significant differences between any two, thus, requiring users, by try it and find out, to learn how to use the site. In contrast, a static site seems to stand on a history of computer interaction, e.g., with the standard controls -- text boxes, check boxes, radio buttons, links -- that go back to some IBM work for the airline industry and the 3270 terminals and that by now maybe 3 billion people understand immediately, and if so then that can be an advantage.
> The Hacker News pages are "static" -- correct?
No. They are inherently dynamic. They are generated by user-submitted content at real time.
On the article's categorization, it would make HN a complex site. But the categorization does not apply here.
Great article.
> Don't you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself?
> Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.
Exactly right.
CMSes like Bludit are a good option for users who want a simpler structure and a small footprint. Themes are still very limited though.
> normal users are stuck with a bunch of greedy clowns that make them pay for every little thing
Huh? You're not confined to Automattic or WP-Engine, there are tons and tons of regular web hosting providers with Wordpress and a bunch of other stuff included in a standard hosting package, you can use the free Wordpress, and you can self-host. That's the whole point of Wordpress being open source, and it's working as intended.
There's absolutely nothing wrong with the status quo around blogging.
Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called. Which is fine too, good for you if that's what you like to do with your time! For "normies" (or SME's who just want to publish their web content and move on), there are more than enough options around.
> Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called
No? Downloading Hugo, getting a random theme and writing a few articles is pretty simple and requires no more tinkering than doing the same with a Wordpress (okay, one's actions are big buttons in a UI, the other is copy pasting commands, but in terms of effort, there's barely any difference).
I use Hugo because it's light and allows me to have a blog running for free and scale to infinity (I have at least two articles that sat high up on the front page of HN, and there was neither a hug of death nor a bill associated), with zero maintenance, while also having flexibility if I need it. I haven't even checked my score on Google's whatever and I don't care about it.
As for WordPress, none of what you described can be had for free, and it requires ongoing maintenance (updates to keep up with the crappy ecosystem).
> No? Downloading Hugo, getting a random theme and writing a few articles is pretty simple and requires no more tinkering than doing the same with a Wordpress
This is not even remotely true. There are more hosts than I can count offering one click wordpress installs that dump you straight into a point where you can begin publishing.
> (okay, one's actions are big buttons in a UI, the other is copy pasting commands, but in terms of effort, there's barely any difference).
For the average non-engineering background user, this is a huge difference.
I've spent most of my IT career in hosting. You are vasltly overestimating the capabilities or care factor of a significant chunk of the user market.
> okay, one's actions are big buttons in a UI, the other is copy pasting commands,
The difference is that the console is scary to the average user, big buttons are not.
I think you should reexamine the Hugo getting started workflow. I think it is pretty scary for a non tech literate person. Even as a programmer, I thought the initial bootstrap to getting a theme in place is clunky. Should come with an out of the box template that lets someone immediately bang out content.
I could guide Mom how to connect to a Wordpress host. I could not say the same for Hugo.
> Static site generators are used by technologists who want to tinker and check all the boxes in whatever Chrome's latest devtool benchmark tool is called
It's relatively easy to reach a PageSpeed test result of 100 with WordPress by disabling one or two features and setting up a cache extension. For logged out users, WordPress with SuperCache set up is almost like a static website (except for the occasional cache eviction) because the HTML is almost directly served from the cache.
If you are don't know anything about cars but suddenly would need a one, would you go to the nearest car dealer you heard about from somewhere or immediately go to the specific resources where you can find a specific model and make you need at a better price?
You can then move it out of the dealer’s parking spot if you find a place cheaper.
people who know how to "self-host" can do it for free or very cheap.
Otherwise WP Engine is $30 per site.
OP says it's not only lame to exploit the knowledge asymmetry in this way but also makes web lame long term because normies don't have tools to contribute effectively.
Yep, definitely agree. I've started a couple sites recently and quickly found that while I was happy just generating them with an SSG and slapping them up online, as soon as I wanted to collaborate with others the SSG had to go right out the window in favor of WordPress. It's not that SSGs can't be collaborative, mind you, it's that it's far easier to give someone a limited-access login to a WP site and let them contribute articles than it is to try to teach someone who isn't a programmer how to navigate adding things to an SSG.
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).
I thought early web browsers were designed to not only view, but edit websites.
Guess that idea is long gone...
What are good WYSIWYG editors for static sites? Any recommendations?
Yet another attempt to rip up the web into extremes. In the option number 2, author is clearly trying to hide an elephant behind a curtain. Complex CMS written in PHP requires a web server, but for a collection of static HTML files this requirement is cleverly skipped?
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.
Fixing the editor experience of static sites seem to be most important to me, maybe followed by having comparably good themes. Whenever I setup a new site or fix a broken site for friends, I always try to convince them to go to a static site. Nobody really knows what that is and how it’s different, ie. nobody cares - until they realize that they now need to write in markdown. Managing images is most painful. I also learned to not bother anyone with git and just let them copy to production.
> a big frontend component that loads as a Single Page Application and then performs navigation by requesting the content in JSON form, which then gets "rehydrated" client-side.
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.
the "hydrated" means that external objects (JSON) are added to the running SPA.
Is this a common definition of "hydration" and I've missed it all these years? For me that "adding to the running SPA" part is called rendering.
I agree with you. I think that's why he used " (and probably not knowing/thinking about a better term).
Related: Blogging vs. Blog Setups
> And so, while we software engineers enjoy free hosting & custom domain support with GitHub Pages / Cloudflare Pages / etc
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.
What’s the worst that can happen when using free hosting? As soon as they start charging money, you just leave for somewhere else. And I say that as someone who is paying for a VPS for hosting (and some other stuff).
That's true for all free stuff. It's a pain to constantly monitor if the service is still free, and a pain to keep migrating.
Web hosting is very cheap - especially for static sites. Much easier to pay and forget about it. I've used my provider for 20 years.
I’m pretty sure the provider will tell the users once they start charging money, they want to convert them to paid customers after all. And migrating a static site every couple of years wouldn’t bother me too much either. If you value the time with your hourly income, it’s probably not worth it, but if it’s fun, it’s fine.
I'm curious, which provider have you been using for 20 years?
Dreamhost.
Phenomenon acknowledged but
"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.
> ...the web used to be more interesting when more of it was made by people different from us
And there it is, beautifully distilled into one sentence.
The fix for this is GitHub Actions and GitHub Pages. That way you don't have to run any software yourself at all - the build process runs entirely on GitHub for you, and it's free as well.
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.
The GitHub Pages splash page (https://pages.github.com/) has a nice little interactive tutorial for just that, and I've seen plenty of repo templates for various SSGs/themes, but I think a lot of users still run into the following hurdles:
- 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
A previous version of my personal website was scaffolded entirely in HTML and a handful of CSS. I used pandoc as a markdown to HTML converter for blog posts, and wrote a short bash script to package everything up into a bundle of HTML files. GitHub Actions and GH pages were also used like you describe, and then finally I just pointed my domain to the hosted page on GitHub Actions. It worked flawlessly
https://github.com/AshwinSundar/ashwinsundar/commit/6887c201...
Crafted by Rajat
Source Code