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

181–190 of 221 posts

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

#181

Post by nicbou »

glogla wrote: post #10
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…

Wow, that website loads so fast.

It's very small, the CSS is inlined before the content, everything loads in a single request, and I use fonts and images sparsely. CloudFlare makes it fast everywhere.

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

#182

Post by nicbou »

eviks wrote: post #62
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…

but then formatting is awful in markdown, especially with all the template and tag syntax you add there which sometimes take more space than the actual words they mark up, and also due to all the tags you can't search/find/replace across the entire content, how do you find a "__bold__ in a phrase" or "bold in a __phrase__" reliably?

I spend most of my time editing markdown, and this was never an issue.

On the other hand, now I can use any search and editing utility I want, not just whatever my CMS provides. A good example is adding a space after the § character, which I use a lot. It would take five seconds to fix it across the website.

A good text editor theme makes a big difference. I fine-tuned an existing Markdown theme for Sublime Text to better highlight the markup, especially headings.

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

#183

Post by nicbou »

defrost wrote: post #13
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…

All About Berlin is a great little site - good work. https://allaboutberlin.com/ Fast, complete in what it does, to the point. [ IMHO it could use a section on TV Series and Movies set in Berlin past and present with a quick rating on how realisticly they portray actual Berlin ... but that's just me :-) ]

I have something about movies set in Berlin, but I dread updating it. It's out of scope for me.

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

#184

Post by 8n4vidtmkvmk »

koromak wrote: post #174

I think the worst part of dynamic (JS) websites is the air gap between client and server. Its so painfully obvious compared to a static site. The Data flow feels like client->transform->api->transform->server->db->server->transform->api->transform->client, the song and dance just gets old after a while. I stupidly started my API interface as just a million unstructured JSON endpoints, each one with its own requiremen…

There have been lots of attempts to blur client and server. The latest Next is one, Meteor is several years old now and does something similar iirc, and a few other less popular ones. I don't think a drop in lib is possible by its nature tho, client and server have to cooperate.

I've found random endpoints works reasonably well tho. You can change the server response and it only affects one client page. Easy to maintain.

If you want more structure, you can also try GraphQL.

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

#185

Post by suprjami »

flohofwoe wrote: post #39
suprjami wrote: post #27

Earlier quoted context omitted.

I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown. It was great. Until the webhost took away PHP anyway.

GH Actions (or any othe CI service) can do the same workflow though. Commit and push markdown, GH Action starts server-side, converts the markdown to html with a static site generator of choice, and uploads to webhoster. If you use Jekyll as static site generator and GH Pages for hosting, it even works out of the box (eg no GH Action tinkering needed, just flip a switch in the GH project settings) But arguably, a loc…

I have since moved to GitHub Pages for my main site, but mine was even simpler than that: https://github.com/superjamie/emdee

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

#186

Post by eviks »

nicbou wrote: post #182
eviks wrote: post #62

Earlier quoted context omitted.

but then formatting is awful in markdown, especially with all the template and tag syntax you add there which sometimes take more space than the actual words they mark up, and also due to all the tags you can't search/find/replace across the entire content, how do you find a "__bold__ in a phrase" or "bold in a __phrase__" reliably?

I spend most of my time editing markdown, and this was never an issue. On the other hand, now I can use any search and editing utility I want, not just whatever my CMS provides. A good example is adding a space after the § character, which I use a lot. It would take five seconds to fix it across the website. A good text editor theme makes a big difference. I fine-tuned an existing Markdown theme for Sublime Text to b…

> and this was never an issue

weird that broken search basics are not an issue, you extol the virtues of site search in your blog, that engine is capable of matching "shcfua" to "Schufa". Markdown, on the other hand, fails in search long before getting to fuzziness

> § character, which I use a lot. It would take five seconds to fix it across the website

True, and then forever to hunt down those few instances where § was used in a quote or something and should not have been fixed

> I fine-tuned an existing Markdown theme for Sublime Text to better highlight the markup, especially headings.

I "highlighted" most of text markup to make it invisible, a bold text is already visualy bold even in Sublime, why woud I need an extra __indicator__? And heading size is also the best highlighter, which plain text editors don't do

But yeah, I wish there were Sublime-level tool for rich text so you wouldn't have to compromize like that...

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

#187

Post by dasil003 »

I agree with the author, and I think it mostly comes down to the original article author being young and not really having much perspective on the reliability, stability and backwards-compatibility of HTML/CSS/HTTP and traditional file servers over time. The fact that you can pick up an HTML file from 1993, trivially drop it on any type of web host, and have it be accessible on any browser on any platform more or less exactly as it looked then is not to be underestimated. Compiling and running any source code from 1993 that hasn't seen maintenance since then is going to range from slightly annoying to a monumental effort requiring essentially a full rewrite. This is exemplified by this comment:

> There have now been a significant number of attempts to "platformitize" dynamic computation — "serverless" programming like AWS Lambda, WASM runtimes like those provided by CloudFlare and Fastly, full container deployment via Fly.io and cloud providers. None of these have an API nearly as stable as the filesystem API used to host static files, but it's a matter of time before APIs end up well-established.

Containers and WASM are certainly interesting vectors of standardization, but even if everything goes fully to plan by the most bullish proponents, you still have a much more complex environment where incentives to break backwards compatibility make it exceedingly unlikely that you'll be able to just grab a container and WASM binary and drop them into any commodity host 30 years from now. Of course HTML/CSS rendering could break too, but incentives are skewed more in favor backwards compatibility. Also, because it's just a simple, human-readable file format, slight breakage doesn't render the archive useless. Heck, even the destruction of the internet and all servers doesn't render the file useless—you just need to be able to decode ASCII/UTF-8 to extract value.

I think a better thesis for the original author would have been that static site generators are not necessarily simpler than dynamic sites generated at request time. I agree with that wholeheartedly, but the beauty of the SSG is that if at any time I want to stop maintaining the code, I have a ready-made servable version of the site that is trivially archivable in perpetuity. Standardized data formats expressed in simple files will always be more durable than code.

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

#188

Post by [deleted] »

rpdillon wrote: post #74
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 haven't used it, but Publii[0] might be along the lines of what you're thinking of. I ran across it in a previous HN discussion, and it seems to be static site generator with a pretty user-friendly graphical interface. [0]: https://getpublii.com/

[deleted]

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

#189

Post by Andrex »

derefr wrote: post #167
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…

I went from hacking up the source HTML files I designed on Geocities and uploading them to Freewebs (so I could remove the linkback/ads) and it worked really well for a while. Then I wanted dynamic stuff and PHP was perfect. Eventually I accepted the stigma it had even while I never really bumped into the ugly parts, or even treated it as a normal programming language.

I think after bouncing around with Node and the flavor-of-the-week static site generators, I might be going back to PHP for my personal sites.

Which is insane. If you told me I'd be heading in this direction anywhere between 2 and 15 years ago, I'd think you were lying.

All I really need are template files. I could use iframes but that stinky technology actually deserves its stink.

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

#190

Post by simonw »

mattlondon wrote: post #164
simonw wrote: post #162

Earlier quoted context omitted.

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…

I talk about the benefits of the approach in quite some detail here: https://simonwillison.net/2021/Jul/28/baked-data/#benefits-o... - does that help clarify?
Post reply on HN