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

91–100 of 221 posts

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

#91

Post by csense »

modernerd wrote: post #22
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…

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…

> Would be great to make the tech more accessible to those without the skills to recompile and deploy

Originally, hand-writing HTML was a supposed-to-be-accessible-to-non-technical-users way to make a website.

Until the late 1990's, HTML was used sort of like Markdown is used today.

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

#92

Post by thomashabets2 »

I used m4 some time in the 90s to generate my site, before I'd heard the term "static site generator".

Then I switched to PHP, and then Python, and now back to static using Jekyll.

It's just so much better, when possible to use. Aside from SSL certs everything can be fixed on your timeline. Compare PHP breaking something on upgrade, where you need to fix it immediately, and the site is down until you're done.

Static site, even if the generator breaks, fails... well... static. If you don't need to post anything new, then you don't have a problem.

And if the server explodes, you can just ask a friend to host some files. Not "hey, you run PHP version X with settings Y, right? And postgres?".

(Some friends maybe even say "no, I don't want PHP on my machine")

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

#93

Post by toddmorey »

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…

I love your Berlin site! It’s so clean, useful, and informative.

May I ask how the revenue works? I just like that it’s not polluted with ads.

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

#94

Post by AndrewKemendo »

The vast majority of the internet is files of text and images that don’t need to be updated that often.

Further, rendering of text and images is handled by client configured applications that change - with the content fitting into client specified configurations

Given that, if you want your content to be fast to access and simple to maintain over the longest period then:

1. Provide the smallest possible amount of bytes to the client that completes the communication task

2. Format the data in a way that will remain supported by the most clients over the longest term

It’s fun to play with different setups for a variety of use cases and server side rendering, but history shows that the most reliable design pattern prioritizes clients being able to consume and render data as quickly and clearly as possible.

I’ve never found a simpler way to do that than a file server hosting static .html files with text, svgs and pngs.

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

#95

Post by brillout »

I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can.

I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic.

I've wrote more about it over here[2] (SSG = static, SSR = dynamic).

[1] https://vite-plugin-ssr.com

[2] https://vite-plugin-ssr.com/pre-rendering

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

#96

Post by jameshart »

The biggest difference between a static site versus a dynamic one is security surface area.

A static site web server can only ever, worst case, be induced to serve the wrong files. And you can mitigate that by making sure the only files you put on the server in the first place are ones you want to serve.

A dynamic site can be induced to run code. It can be induced to return the wrong data from the database it has access to (passwords for example). It can be induced to modify data.

Wordpress breaches happen all the time. Nginx breaches don’t.

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

#97

Post by simonw »

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 an asset bundled into your application.

This only works for sites that don't constantly have updates, since you need to re-deploy the entire site when anything changes (just like a fully static site).

Benefits are you can deploy to inexpensive dynamic scale-to-zero hosting (like Vercel), you can handle any amount of traffic by running multiple copies of your app and if the app crashes your host can just restart the application automatically.

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

#98

Post by PhilipRoman »

thomashabets2 wrote: post #92

I used m4 some time in the 90s to generate my site, before I'd heard the term "static site generator". Then I switched to PHP, and then Python, and now back to static using Jekyll. It's just so much better, when possible to use. Aside from SSL certs everything can be fixed on your timeline. Compare PHP breaking something on upgrade, where you need to fix it immediately, and the site is down until you're done. Static…

I still use m4 for such tasks. I feel like it's only 1 step up from having a sed "s/VERSION/1.2.3/g" in terms of complexity and as long as everything can be done with external shell commands, you can avoid installing python, etc.

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

#99

Post by smashed »

csense wrote: post #91
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…

> Would be great to make the tech more accessible to those without the skills to recompile and deploy Originally, hand-writing HTML was a supposed-to-be-accessible-to-non-technical-users way to make a website. Until the late 1990's, HTML was used sort of like Markdown is used today.

And people could not resist the urge to add styling and heterogeneous layouts all over. Weird typography, layouts, alignments and extra padding here and there.

A secret reason why I like to push markdown workflows is that you can't deviate from the site's overall look and feel. Focus on your content, hit publish and it will look good. Even if we change the site's look down the road, the content is still going to be fine.

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

#100

Post by berkle4455 »

jameshart wrote: post #96

The biggest difference between a static site versus a dynamic one is security surface area. A static site web server can only ever, worst case, be induced to serve the wrong files. And you can mitigate that by making sure the only files you put on the server in the first place are ones you want to serve. A dynamic site can be induced to run code. It can be induced to return the wrong data from the database it has acc…

> Nginx breaches don’t

Except when someone forgets to append a trailing slash on a location block with an alias directive.

Post reply on HN