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

101–110 of 221 posts

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

#101

Post by 3cats-in-a-coat »

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 ones.

And ultimately it's about input, and how input is treated. It doesn't matter how complex code you run, if you accept no input, you can't attack that system. Of course with no input you can't even figure out which page to show. So there's always input, even for static sites. But I'm trying to point our attention to what's the major distinction here.

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

#102

Post by Karunamon »

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…

To offer the other side of this, at $dayjob we just got done getting out of Webflow and into hand-coded HTML. That stack comes with a number of severe headaches.

* The UI layer is complete and total garbage. It is unbelievably slow and clunky and it makes doing anything with it a chore.

* The UI is complicated enough that it would be easier to teach the non-technical folks to use markdown.

* Uncomfortable amounts of lock-in. You can export your entire site of course but retrieving your "CMS" records is not so straightforward.

* If you need to do anything interesting, the UI benefit is gone, because now you get to write code AND use their awful platform.

* Expensive, with a recent price hike with no increase in the functionality or quality.

The recompile and deploy steps can be automated in ways that don't require hitching yourself to this behemoth.

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

#103

Post by pier25 »

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 agree and made that mistake myself... Framer is another good alternative to consider.

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

#104

Post by isjamesalive »

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…

> if you accept no input, you can't attack that system

But this is a side channel attack, right?

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

#105

Post by pier25 »

littlecranky67 wrote: post #20

Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interfa…

Why not Astro?

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

#106

Post by carlosjobim »

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…

> I think one big missing part still with static sites is how you host the CMS to edit it.

This problem is completely solved by Surreal CMS [1]. Make your website anyway you want, connect surreal by FTP and let the user/client edit what you permit them to edit. The cost $12 per month is dirt cheap for never having to worry about it, and giving non-tech users a total WYSIWYG editor.

[1] https://www.surrealcms.com

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

#107

Post by chefandy »

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…

I think they were merely implying that the website codebase doesn't have anything executable. I can't imagine anyone reading HN thinks that serving websites, generally, doesn't require a giant pile of code at many levels. Sure it doesn't eliminate the server-side security concerns of the entire deployment, but probably would from the entire website codebase; many people run static websites in read-only caches. At that point, the security concerns are more in the system/ops/network realm than the site itself.

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

#108

Post by dclowd9901 »

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…

This was my thinking as well. A website running application code will also require maintenance vis a vis updates to mitigate security holes. And that never stops.

You could theoretically never need to “update” a static site. There’s not even really a concept for it. Unless the target changes HTML versions, I guess.

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

#109

Post by evandale »

smashed wrote: post #99
csense wrote: post #91

Earlier quoted context omitted.

> 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 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.

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

#110

Post by jameshart »

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…

Sure. Heartbleed for example was a data exposure vulnerability that leaked data from the HTTPS stack, which exposed private keys and plaintext from other inflight requests. Any real world system that handles HTTP requests, at minimum, has to do some reading of config data, some reading of data to serve up, and some writing to log files.

The point is that a static web server does that and only that. A dynamic web server is one that does that and more.

Post reply on HN