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

121–130 of 221 posts

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

#121

Post by kodah »

3cats-in-a-coat wrote: post #101
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…

I just want to straighten the perspective on things a bit. Technically there's no web site that doesn't "run code". There's always code involved. It's code all the way down, from the web server to the file system drivers, the operating system and so on. While it's true that static files reduce attack surface, we need to think deeply why is that, and design intelligent dynamic systems that have the security of static…

Just to build on this, there are RCEs that involve overflowing headers; Go just had one not that long ago. There's plenty of inputs on a GET request. You still need to do proper security on a static site.

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

#122

Post by steve76 »

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…

[dead]

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

#123

Post by steve76 »

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.

[dead]

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

#124

Post by _factor »

Dalewyn wrote: post #114
evandale wrote: post #109

Earlier quoted context omitted.

I miss all that weird styling :( It gave the internet character and flaws. Now it feels like everyone limits themselves to publishing nothing but perfect images of themselves.

tag is awesome and noone can tell me otherwise.

I agree!

Hit Count: 3,404

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

#125

Post by sixdimensional »

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…

Tangentially, I've been exploring something kind of fascinating...

So, in compiled binary executables it was not uncommon to include encoded binary resources, like files or images. Not tons of them, because they would explode the size of the executable.

For example, for C or C++ https://github.com/graphitemaster/incbin

So here's the interesting part - we decided to build executables in a way that data in those executables could not be changed (makes sense since it's compiled and the compiled code runs on the machine, and for security reasons).

That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.

So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change.

Now, in a container, any changes made to data at runtime inside the container won't persist unless the container is given persistent storage.

What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.

Just a musing but tangentially related to your "baked data" - basically, embedded resources in executables just embeds the encoded data right into an executable.

For scripting languages, of course, we can just make a script file that contains a variable with the encoded data as base64 directly.

For the latter 2, it's only good for relatively small static data of course, but it would be interesting to build tech that somehow lifted that constraint of executables.

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

#126

Post by simonw »

sixdimensional wrote: post #125
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…

Tangentially, I've been exploring something kind of fascinating... So, in compiled binary executables it was not uncommon to include encoded binary resources, like files or images. Not tons of them, because they would explode the size of the executable. For example, for C or C++ https://github.com/graphitemaster/incbin So here's the interesting part - we decided to build executables in a way that data in those execut…

Have you seen redbean? It's exploring ideas that are in that kind of space: https://redbean.dev/

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

#127

Post by jameshart »

kodah wrote: post #121
3cats-in-a-coat wrote: post #101

Earlier quoted context omitted.

I just want to straighten the perspective on things a bit. Technically there's no web site that doesn't "run code". There's always code involved. It's code all the way down, from the web server to the file system drivers, the operating system and so on. While it's true that static files reduce attack surface, we need to think deeply why is that, and design intelligent dynamic systems that have the security of static…

Just to build on this, there are RCEs that involve overflowing headers; Go just had one not that long ago. There's plenty of inputs on a GET request. You still need to do proper security on a static site.

Or.. a commodity static hosting provider can do proper security for you.

I don’t tend to worry about the RCE risk of hosting files in an S3 bucket behind a cloudfront distribution. That’s someone else’s problem.

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

#128

Post by bradgessler »

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 down this path enough times that I built https://sitepress.cc/, which lets you embed content in a rails app with features that are present in Jekyll, Middleman, etc. like Frontmatter, site hierarchy traversal, etc. It keeps content as files in the app/content directory, but when it’s time to pull data in from the Rails app for SEO, it’s all right there in the Rails app. There’s no “Headless CMS” crap to jump through.

For me, this is another way of keeping everything in a monolith, and which requires a lot less context switching. If I’m building a feature and I want to create marketing or support content for it, it’s all right there in the same repo. I just create the markdown files I need, commit them to the repo, and I’m don.

The thought of switching between a static content site or something like Webflow just seems silly for a small team or project.

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

#130

Post by modernerd »

evandale wrote: post #109
smashed wrote: post #99

Earlier quoted context omitted.

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 f…

I miss all that weird styling :( It gave the internet character and flaws. Now it feels like everyone limits themselves to publishing nothing but perfect images of themselves.

Site creation tools that encourage freeform styling are great, especially if they make it easier than rolling your own HTML/CSS.

For example:

https://build.mmm.page/

Post reply on HN