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

111–120 of 221 posts

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

#111

Post by marcosdumay »

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…

> we need to think deeply why is that

That's because the nginx inputs have a much more homogeneous type than your random django-based system.

I'm not sure there's anything you can learn from that. Some use-cases just lead to more secure software than others, and this is a completely non-actionable piece of information.

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

#112

Post by evandale »

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?

> how do you find a "__bold__ in a phrase" or "bold in a __phrase__" reliably?

Can't you use regex?

_[^_\n\r]+_

edit: I think double underscores are easier, you should be able to use __.+__ and there's no reason to have to avoid matching single_underscore words.

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

#113

Post by whoknowsidont »

littlecranky67 wrote: post #42
eric-burel wrote: post #37

Earlier quoted context omitted.

This is a actually the contrary they started caring more though all scenarios might not be covered yet. See this example from Dan Abramov: https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343... It's not related to Vercel business model but to the fact that this use case is less common (in proportion) when using Next.js. I am not sure what you mean by static rewrites, isn't that covered by middlewares?

The link you posted from Gaeron uses the (now deprecated) pages router, directly supporting my argument. I did a migration from pages router to app router for my static-export project. Btw both are still present in v13, you can pick whichever you want, but long-term the pages router will be gone. With static redirect/rewrites I mean the feature in pages router where you put in the "redirect"/"rewrite" statement in yo…

>(now deprecated) pages router

The pages router is not deprecated. It will be supported for quite some time still, and is even receiving new features.

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

#114

Post by Dalewyn »

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.

tag is awesome and noone can tell me otherwise.

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

#115

Post by js2 »

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 found my way to this page on your site:

https://allaboutberlin.com/guides/movies-set-in-berlin

There's a typo in the TOC. … is being rendered literally I'm guessing because the ampersand is escaped accidentally.

Also a few you might add to the list: Berlin Alexanderplatz (1980), Possession (1981), Gotcha! (1985), Suspiria (2018), Undine (2020)

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

#116

Post by mlhpdx »

Before CloudFront I had a setup that used custom HTTP server code to capture requests directly as S3 objects, then wait on an SQS queue for the response which would indicate the location of an S3 object containing the entire response verbatim. (Yes, each server could handle exactly one request at a time, call it a learning experience.) This was the closest I ever felt I got to a “static” website.

The goal was to eliminate redundant computation, and it did that, but there are much better approaches these days. What I ended up with was just bespoke, persistent caching.

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

#117

Post by evandale »

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.

Thanks for the warning, I won't try to tell you otherwise hahaha! Besides, if you like marquees who am I to say you're wrong!? I have exactly 0 design or taste bones in my body and think lime green text on a blue background is the pinnacle of human beauty.

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

#118

Post by trollied »

tjoff wrote: post #82
flohofwoe wrote: post #5

As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.

Dynamic pages do have some overhead, as discussed in the article. But it is still vastly superior to running the site in the browser. Because the generation is done once, and it is darn quick. After that all of the numerous advantages of a static page still applies from a users perspective. The resource use is many orders of magnitude less and the page is much more responsive. The user experience is vastly superior,…

Yup. Less DOM manipulation the better.

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

#120

Post by kodah »

Daril wrote: post #19
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…

This is very interesting. Impressive how much efficiency and performance is gained. This also means that fewer resources (electricity) are consumed, that less bulky hardware is used and, most importantly, that security is improved. A static website is more difficult to attack and the only possible flaw is in the web server and not in the code of the website. I usually use Hugo. It is very complete and rich in feature…

> This also means that fewer resources (electricity) are consumed

Most servers in the world use a constant amount of electricity, regardless of load. Generally the way to make DCs more green is to build them around a renewable plan with batteries (that they already need). Save for the fact that the whole thing is made of rare earth metals and lead, and you've got yourself something pretty green.

Post reply on HN