Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The theory versus the practice of “static websites”

utcc.utoronto.ca

Post reply on HN
Print view View original

161–170 of 221 posts

Re: The theory versus the practice of “static websites”

#161

Post by eyelidlessness »

floren wrote: post #148

My personal website is an odd mix of static and dynamic; that is, it's mostly static, but the blog portion is dynamic. When you hit a blog URL, it fetches a Markdown file from the disk, converts to HTML, and then jams that HTML into a template which provides the rest of the page, brings in CSS, etc. It's still fast and efficient; when one of my blog posts was #1 on HN last week, my friend texted me "good luck, hope y…

That is an odd mix (without additional detail at least). I’m curious about the rationale for dynamically rendering the Markdown. I can think of a few reasons (dynamic content templated in, reduced build time/complexity come to mind), but maybe it’s something(s) I haven’t considered.

Re: The theory versus the practice of “static websites”

#162

Post by simonw »

mattlondon wrote: post #155
simonw wrote: post #97

I've been exploring an architectural pattern for a few years now which I think gives you the best of both worlds: it lets you run dynamic server-side code, but in a way that's both extremely inexpensive to scale up and that is self-healing if anything breaks. I call it the Baked Data pattern: https://simonwillison.net/2021/Jul/28/baked-data/ The key idea is that you deploy a full read-only copy of your site's data as…

I am not sure how this differs from a static site generator that also has some backend functionality? E.g. I've seen static sites with server-side search etc, comments systems etc which submit each post/comment as a separate flat file and then regenerate static pages automatically from those etc. Is it more that your approach stores stuff in sqlite and builds from that, rather than markdown files? That seems to be th…

It's a variant on that pattern.

The key idea here is that your server-side stuff is completely read-only - so comment systems aren't supported - because the server-side data is treated as a deployment asset.

Have you used platforms like Vercel? Their one big limitation is that you can't use persistent storage with them - if you want to talk to a database of some sort you need to add an extra database vendor.

The baked data pattern works around that by bundling read-only data (usually a SQLite file) with your deployment.

Re: The theory versus the practice of “static websites”

#163

Post by floren »

eyelidlessness wrote: post #161
floren wrote: post #148

My personal website is an odd mix of static and dynamic; that is, it's mostly static, but the blog portion is dynamic. When you hit a blog URL, it fetches a Markdown file from the disk, converts to HTML, and then jams that HTML into a template which provides the rest of the page, brings in CSS, etc. It's still fast and efficient; when one of my blog posts was #1 on HN last week, my friend texted me "good luck, hope y…

That is an odd mix (without additional detail at least). I’m curious about the rationale for dynamically rendering the Markdown. I can think of a few reasons (dynamic content templated in, reduced build time/complexity come to mind), but maybe it’s something(s) I haven’t considered.

It was basically a pragmatic choice. I figured the following:

- For most of the site, hand-jamming HTML works fine, because I have a small number of pages outside the blog.

- For the blog, I wanted easy authoring, thus Markdown. I figured if I rendered it on each request, I wouldn't need to make a separate tool to regen stuff, I could just build it all into the server; any changes I made to the markdown would be instantly reflected on the site.

I wrote this in Go at a conference in 2011. Hugo didn't exist yet or I probably would have just used that.

edit: I initially wrote this on Plan 9, and it's so old that there's still a mkfile invoking go/8g and go/8l individually to build it. It's 265 lines of code, which does the static content, generates the blog stuff (including creating the blog "archive" page on-demand), and manages multiple domains so I don't have to invoke e.g. apache to use the same host for multiple sites.

Re: The theory versus the practice of “static websites”

#164

Post by mattlondon »

simonw wrote: post #162
mattlondon wrote: post #155

Earlier quoted context omitted.

I am not sure how this differs from a static site generator that also has some backend functionality? E.g. I've seen static sites with server-side search etc, comments systems etc which submit each post/comment as a separate flat file and then regenerate static pages automatically from those etc. Is it more that your approach stores stuff in sqlite and builds from that, rather than markdown files? That seems to be th…

It's a variant on that pattern. The key idea here is that your server-side stuff is completely read-only - so comment systems aren't supported - because the server-side data is treated as a deployment asset. Have you used platforms like Vercel? Their one big limitation is that you can't use persistent storage with them - if you want to talk to a database of some sort you need to add an extra database vendor. The bake…

Oh ok so you still have a "dynamic" site that is database driven, but that database is read-only and stored in a pre-generated sqlite file that is deployed with the rest of the site assets?

I don't want to piss on your parade here - perhaps I just don't get this pattern - but isn't this all of the downsides of a dynamic site but without any of the benefits? You are still running slow server side stuff that relies on doing per-request database stuff and all the complexity and security headaches that go along with it (upgrading PHP or Wordpress or whatever), but with none of the benefits of server side functionality and databases (i.e. it is all read-only).

Re: The theory versus the practice of “static websites”

#165

Post by Takennickname »

nicbou wrote: post #3

I run a content website for a living. This year I switched from Craft CMS to my own static site generator. I no longer think about the server or the CMS. I no longer need to keep it updated. I got rid of the heavy database and the elaborate caching setup. Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance. The…

What do you think would benefit other than content systems?

Re: The theory versus the practice of “static websites”

#166

Post by oceanstone »

seanwilson wrote: post #45

I think one big missing part still with static sites is how you host the CMS to edit it. Correct me if I'm wrong but Decap CMS (previously Netlify CMS) runs in the browser and makes reads/edits via GitHub which can then trigger rebuilds and deploys, but it still needs a small server/proxy I think because CORS stops your browser communicating directly with the GitHub API. Netlify hosts a GitHub backend that proxies re…

This local backend feature seems pretty powerful for free/offline editing: https://decapcms.org/docs/beta-features/#working-with-a-loca...

Re: The theory versus the practice of “static websites”

#167

Post by derefr »

floren wrote: post #148

My personal website is an odd mix of static and dynamic; that is, it's mostly static, but the blog portion is dynamic. When you hit a blog URL, it fetches a Markdown file from the disk, converts to HTML, and then jams that HTML into a template which provides the rest of the page, brings in CSS, etc. It's still fast and efficient; when one of my blog posts was #1 on HN last week, my friend texted me "good luck, hope y…

Odd today, but you're essentially describing the idiomatic, pre-framework use-case that drove the design of PHP. "It's mostly HTML, but when you get to this line in this one file, run it as code [to e.g. parse some other file from some other format] and embed the result in the output."

Made perfect sense in 2001 for building a static website where you happened to want to have e.g. a comments section on each blog post. And this kind of PHP was cheap enough that even your ISP was usually willing to let you slap some of it up on your /~userdir/ and point the public Internet at it.

Re: The theory versus the practice of “static websites”

#168

Post by mjevans »

immibis wrote: post #144
mjevans wrote: post #49

Earlier quoted context omitted.

An edited site could also (mostly) be static if edits pushed / queued a job to publish the updated static content. Ideally a casual visitor would never see non-static content, other than possibly dynamic addins that mix the data client side if they have an active account.

CMV: if you're running code on the server anyway, there's no advantage to having all the precomputed header+content+footer combinations. You may as well run a script that combines the generic header + specific content + generic footer at request time. The advantage of static sites is that you don't have to worry about any server scripting at all.

You might be reading too much into the infrastructure. I was speaking generally.

E.G. The workflow might be updating a database on the local system and a set of affected pages published. Or it could be modifying comments within source code files and a Makefile like regeneration of document files that are then rsynced to a host elsewhere.

If there are user specific portions for some reason those would act more as a real application in sideband to the data, rather than a synchronous (and render blocking / load slowing) detraction from the experience.

Re: The theory versus the practice of “static websites”

#169

Post by earthboundkid »

stn8188 wrote: post #151
modernerd wrote: post #22

Earlier quoted context omitted.

Static makes so much sense for sole-author sites with technical owners. Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach. (Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your m…

I agree completely with this thought. So many people jump right to a wordpress because it can be "easy" (and as an EE, even figuring out the details of Hugo was pretty confusing for what basically amounts to an evening hobby). When I first started putting together my website [0] I considered the tradeoff between static and "dynamic", but constrained myself to the former because I didn't want to pay extra for hosting…

Hugo’s documentation site is poor. WordPress installation is a beast and involves getting PHP, Apache, and MySQL installed, which are each nontrivial. Hugo only seems more intimidating than WordPress because of the size of the documentation gap.

Re: The theory versus the practice of “static websites”

#170

Post by earthboundkid »

pembrook wrote: post #73
modernerd wrote: post #22

Earlier quoted context omitted.

Static makes so much sense for sole-author sites with technical owners. Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach. (Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your m…

> Static makes so much sense for sole-author sites with technical owners. Totally agree for this narrow use case. But you're also correct that if you're a startup with a marketing site--going the Gatsby/Hugo/etc. route is a total disaster. Have seen so many technical founders make this mistake. What happens is you realize, crap, my team needs to publish content for SEO and build new landing pages...and they aren't ab…

I’ve been running a news site with Hugo for the last four years. You setup a CMS that lets the non-technical people make content changes without you. For design changes, you always are going to need someone who knows how to code, so it’s not a big deal to use Hugo.

Of all the problems we’ve had running a website, Hugo has not been one of them.

Post reply on HN