[HN Gopher] The Static Site Paradox
       ___________________________________________________________________
        
       The Static Site Paradox
        
       Author : alraj
       Score  : 236 points
       Date   : 2024-10-08 09:08 UTC (13 hours ago)
        
 (HTM) web link (kristoff.it)
 (TXT) w3m dump (kristoff.it)
        
       | paulpauper wrote:
       | 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.
        
         | oneeyedpigeon wrote:
         | 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...
        
           | wakeupcall wrote:
           | 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.
        
             | oneeyedpigeon wrote:
             | I totally agree -- technically static, but an abomination
             | that should be avoided at all costs!
        
               | timw4mail wrote:
               | An abominable default, sadly.
        
         | ninalanyon wrote:
         | 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?
        
           | Akronymus wrote:
           | Thats what I expect a static site to be too. Along with
           | preferably as little js as reasonable.
        
         | adityaathalye wrote:
         | 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.
        
         | WCSTombs wrote:
         | 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.
        
         | justsomehnguy wrote:
         | > There is still not a censuses as to the definition of a
         | static website
         | 
         | Static website can be served by `cat index.html`
        
           | enriquto wrote:
           | > 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".
        
             | oneeyedpigeon wrote:
             | > 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"?
        
               | enriquto wrote:
               | That's a good line to draw!
               | 
               | Static = no scripting (either server-side or client-side)
        
               | oneeyedpigeon wrote:
               | 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.
        
             | Ferret7446 wrote:
             | 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.
        
         | reliablereason wrote:
         | What?
         | 
         | A static website is a website that has no server side
         | generation. That's how simple it is.
        
         | gsck wrote:
         | 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
        
           | oneeyedpigeon wrote:
           | 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"?
        
         | nextlevelwizard wrote:
         | 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.
        
           | oneeyedpigeon wrote:
           | This, but without the "one HTML file" restriction. Unless I
           | misunderstood you--did you just mean "one HTML file per URL"?
        
         | lupusreal wrote:
         | 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.
        
           | oneeyedpigeon wrote:
           | I agree with you; not even SSI.
        
         | tannhaeuser wrote:
         | 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.
        
         | Ferret7446 wrote:
         | 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.
        
         | BeetleB wrote:
         | > 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.
        
       | davedx wrote:
       | > 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.
        
         | justsomehnguy wrote:
         | 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?
        
           | notpushkin wrote:
           | You can then move it out of the dealer's parking spot if you
           | find a place cheaper.
        
         | sofixa wrote:
         | > 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).
        
           | graemep wrote:
           | > 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.
        
           | 0cf8612b2e1e wrote:
           | 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.
        
         | nikolamus wrote:
         | 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.
        
         | jraph wrote:
         | > 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.
        
       | verisimi wrote:
       | 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.
        
       | jeanlucas wrote:
       | > 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.
        
         | shepherdjerred wrote:
         | 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).
        
           | jeanlucas wrote:
           | Plus it is easy to plug in a CMS if you need to upgrade for a
           | team solution involving non technical people
        
       | pjmlp wrote:
       | > 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.
        
         | kristoff_it wrote:
         | 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
        
           | pjmlp wrote:
           | 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.
        
       | lqet wrote:
       | > 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]..?
        
         | jraph wrote:
         | I suppose they meant that only a few people, who are
         | professional software engineers, can afford the second option.
        
         | gryfft wrote:
         | 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.
        
         | Normal_gaussian wrote:
         | 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.
        
         | smankoo wrote:
         | Yes. That is confusingly phrased. Took me a sec too.
        
         | daoistmonk wrote:
         | i read it as: "can't afford the overhead of complexity of
         | running such a complicated stack for my personal x"
        
         | sandeep_random wrote:
         | Somewhere down the line the ease of publishing changes is the
         | differentiating factor which should have been accounted in the
         | comparison
        
       | dhotson wrote:
       | 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.
        
         | renegat0x0 wrote:
         | 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.
        
         | oneeyedpigeon wrote:
         | > 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.
        
         | ciroduran wrote:
         | 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.
        
         | D13Fd wrote:
         | 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...
        
           | oliwarner wrote:
           | 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.
        
         | nephanth wrote:
         | Now I'm wondering what kind of features you end up adding to
         | your website that need server-side code. Comment systems?
        
           | andybak wrote:
           | How about a contact form?
        
             | echoangle wrote:
             | Here you go:
             | 
             | <form action="mailto:someone@example.com"
             | enctype="text/plain">
        
               | andybak wrote:
               | In an ideal world yes. But from past experience many
               | users have the association for mailto links
               | misconfigured.
               | 
               | It's a terrible user experience.
        
               | echoangle wrote:
               | 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.
        
         | Calavar wrote:
         | 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.
        
         | BeetleB wrote:
         | > 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...
        
         | echoangle wrote:
         | 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.
        
           | dizhn wrote:
           | Pretty sure parent didn't actually mean plain html files for
           | everything but if they did then perhaps they're using server
           | side includes.
        
         | Vegenoid wrote:
         | 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.
        
       | KnowtheRopes wrote:
       | Yes, static websites are great! I'm using Jekyll with GitHub -
       | it's 100% free. I agree, though, there is a learning curve.
        
         | smankoo wrote:
         | I'm using hugo. It's great.
        
         | zahlman wrote:
         | 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.
        
       | eviks wrote:
       | > 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?
        
       | rwbt wrote:
       | 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.
        
         | oleganza wrote:
         | 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.
        
         | oneeyedpigeon wrote:
         | 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.
        
           | rwbt wrote:
           | 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.
        
             | oneeyedpigeon wrote:
             | 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.
        
             | slmjkdbtl wrote:
             | Yes, and almost all clients will ask you to put a contact
             | form on the site.
        
               | 0cf8612b2e1e wrote:
               | 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.
        
           | FalconSensei wrote:
           | > Many sites have dropped comments altogether
           | 
           | And many still have. I think most wordpress.com and blogger
           | blogs have comments on
        
       | fullstackchris wrote:
       | 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
        
         | 0cf8612b2e1e wrote:
         | 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.
        
         | caseyy wrote:
         | If they calculated the % in terms of CPU time used, they could
         | have made the claim even more impressive.
        
       | intellectronica wrote:
       | 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.
        
         | kristoff_it wrote:
         | > 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.
        
       | parasti wrote:
       | 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.
        
         | kristoff_it wrote:
         | > 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)?
        
           | parasti wrote:
           | 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.
        
       | graycat wrote:
       | The Hacker News site is (a) "static" or (b) "complex"?
       | 
       | A case of irony?
        
         | marcosdumay wrote:
         | Hacker News is a social network application, not a blog.
        
           | graycat wrote:
           | 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.
        
             | marcosdumay wrote:
             | > 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.
        
       | kkfx wrote:
       | 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.
        
       | smitty1e wrote:
       | > 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."
        
       | foul wrote:
       | > 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.
        
         | marc_io wrote:
         | > 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
        
       | superkuh wrote:
       | 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.
        
       | chambers wrote:
       | > 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.
        
       | graypegg wrote:
       | 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.
        
         | JellyBeanThief wrote:
         | 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.
        
           | graypegg wrote:
           | 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
        
           | CamperBob2 wrote:
           | 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.)
        
           | Kye wrote:
           | 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.
        
           | pdimitar wrote:
           | 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.
        
           | psd1 wrote:
           | 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.
        
         | steve_adams_86 wrote:
         | 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.
        
           | pyrolistical wrote:
           | 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
        
           | graypegg wrote:
           | 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.
        
             | steve_adams_86 wrote:
             | 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.
        
           | treflop wrote:
           | 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.
        
           | Stoids wrote:
           | 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.
        
         | tomjen3 wrote:
         | 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.
        
       | Kye wrote:
       | Related: Blogging vs. Blog Setups
       | 
       | https://news.ycombinator.com/item?id=25240939
       | 
       | https://rakhim.org/honestly-undefined/19/
        
       | brianzelip wrote:
       | > 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
        
       | troymc wrote:
       | 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).
        
         | oddevan wrote:
         | I did that for a while, but I kept running into annoying edge
         | cases with those plugins (or other wget-based solutions).
        
       | derekzhouzhen wrote:
       | 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.
        
         | BeetleB wrote:
         | > 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_.
        
           | derekzhouzhen wrote:
           | _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!
        
             | stared wrote:
             | It seems that people pay for Ghost,
             | https://github.com/TryGhost/Ghost
        
       | hiAndrewQuinn wrote:
       | 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.
        
         | tomjen3 wrote:
         | 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.
        
         | fluoridation wrote:
         | Can't you just spin up an imageboard instance and put a button
         | at the bottom of an article?
        
         | corry wrote:
         | 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.
        
           | jjmarr wrote:
           | 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.
        
             | dangerlibrary wrote:
             | Like our ancestors before us.
             | 
             | https://en.wikipedia.org/wiki/Eternal_September
        
         | Syonyk wrote:
         | 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.
        
           | fluoridation wrote:
           | >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.
        
             | fph wrote:
             | 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.
        
         | davidgerard wrote:
         | 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?
        
           | psd1 wrote:
           | Perhaps Disqus? I believe it's opaque to the site owner -
           | users auth to Disqus, you don't need a db.
        
           | sphars wrote:
           | There's several solutions for comments, as documented here:
           | https://darekkay.com/blog/static-site-comments/
        
         | Kye wrote:
         | 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.
        
           | tlavoie wrote:
           | There are similar-ish tools such as Isso. Self-hosted, no
           | snooping, stored on SQLite. https://isso-comments.de/
        
         | janalsncm wrote:
         | 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.
        
         | alemanek wrote:
         | 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...
        
         | smitelli wrote:
         | 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.
        
         | makeitdouble wrote:
         | 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.
        
       | BeetleB wrote:
       | > 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.
        
         | echoangle wrote:
         | 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).
        
           | BeetleB wrote:
           | 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.
        
             | echoangle wrote:
             | 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.
        
       | wvenable wrote:
       | 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>
       | 
       | There is a router that automatically adds the site header and
       | footer, and I can add a "_layout.php" file to a folder to add
       | another level of layout for child pages. For blog list page, it
       | just scans all the individual article files in the folder to
       | create the index. That where that _$this- >mode ==
       | PageMode::Meta_ comes in -- it executes the code in each file (to
       | get the meta data) and then exits before rendering the rest. It's
       | not going to scale to a lot of content but I'll adjust if it
       | becomes an issue.
       | 
       | The entire PHP code for my "framework" is only 4 PHP files
       | (init.php, functions.php, Layout.php, and Page.php).
       | 
       | The advantage of being a developer is that you can use code
       | instead of configuration or data. And you can use code to write
       | content more efficiently.
       | 
       | The result (still quite incomplete) is this:
       | https://www.codaris.com/
        
         | ohpls wrote:
         | 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.
        
       | jeffreyrogers wrote:
       | 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.
        
         | MeetingsBrowser wrote:
         | 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.
        
           | jeffreyrogers wrote:
           | 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.
        
       | TZubiri wrote:
       | 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.
        
       | castillar76 wrote:
       | 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).
        
       | nitwit005 wrote:
       | 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.
        
       | janalsncm wrote:
       | 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.
        
         | rpgbr wrote:
         | You just described Micro.blog[1], don't you?
         | 
         | [1] https://micro.blog
        
         | burningChrome wrote:
         | >>> 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.
        
       | simonw wrote:
       | 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.
        
         | spondylosaurus wrote:
         | 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
        
       | rodolphoarruda wrote:
       | CMSes like Bludit are a good option for users who want a simpler
       | structure and a small footprint. Themes are still very limited
       | though.
        
       | dimal wrote:
       | 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.
        
         | dingnuts wrote:
         | 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.
        
           | jachee wrote:
           | CB is roughly 11m wavelength and doesn't require a ton of
           | power, and doesn't require any licensing.
        
       | codethief wrote:
       | > 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.
        
         | meiraleal wrote:
         | the "hydrated" means that external objects (JSON) are added to
         | the running SPA.
        
       | FalconSensei wrote:
       | 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
        
       | dangerlibrary wrote:
       | 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.
        
       | dfex wrote:
       | > ...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.
        
       ___________________________________________________________________
       (page generated 2024-10-08 23:00 UTC)