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

151–160 of 221 posts

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

#151

Post by stn8188 »

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…

I agree completely with this thought. So many people jump right to a wordpress because it can be "easy" (and as an EE, even figuring out the details of Hugo was pretty confusing for what basically amounts to an evening hobby). When I first started putting together my website [0] I considered the tradeoff between static and "dynamic", but constrained myself to the former because I didn't want to pay extra for hosting costs. The Fastmail file/website hosting has been absolutely incredible for this purpose.

All-in-all, doing a static site has allowed me to learn so much more about html and other basic web technology than I think I would have ever gotten from a Wordpress or similar site. The biggest downside thus far is that I wanted to start a sort of Wiki-style knowledge base for users to contribute in my particular niche, but of course the static aspect precludes any user editing. I use that area of my site as my own knowledge-base still, putting info there that I reference all the time at my day job. For fun the other night, I got sucked down the rabbit hole of adding Disqus comments too. I don't expect anyone to ever use them, but instead was just learning about how to do it.

[0] The site is at https://ShieldDigitalDesign.com if anyone is curious to see what a dumb EE can do with a Hugo-generated site hosted with Fastmail.

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

#152

Post by interroboink »

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…

Perhaps we could describe a dynamic website as being a static website + extra (i.e. the dynamic stuff).

As mentioned in the article, every dynamic website will also need some static assets (the .js files, images, etc.)

So, it seems like a dynamic website will always have greater attack surface area than a static one, by definition. It will have all of the static site surface area, plus some more.

----

I wonder if there is room for a language that is not as general as JS, but can still be used to add dynamism to a website. So, you don't have to be stuck in the "it's Turing complete, so we can't be sure it's well-behaved before running it" situation.

Perhaps CSS is kinda turning into that, these days.

Though maybe CSS will become Turing complete too, at this rate (:

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

#153

Post by hinkley »

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 keep thinking one of the things we should look for in a nextgen version control system is a useful API.

Many apps need VCS, not a database, and CMS is one of the clearest.

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

#154

Post by hinkley »

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…

HTTP requests are input. Code Red for instance sent broken input.

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

#155

Post by mattlondon »

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…

I am not sure how this differs from a static site generator that also has some backend functionality? E.g. I've seen static sites with server-side search etc, comments systems etc which submit each post/comment as a separate flat file and then regenerate static pages automatically from those etc.

Is it more that your approach stores stuff in sqlite and builds from that, rather than markdown files? That seems to be the only meaningful difference I can see compared to normal static sites with backend/server-side functionality?

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

#157

Post by hinkley »

crote wrote: post #29
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.

Not everything can be done in a browser. You might want to store user-submitted content in a database, for example. Or you might want to do authentication. You might want to provide full-text search in a multi-gigabyte dataset. You might want to provide an interface to something which can't be accessed from a web browser. You might want to validate user-provided input. All of those require custom code running on a se…

Also users haven’t had “a browser” for a decade. Between personal and work I have four, technically five, and then some apps on my Apple TV (YouTube in particular). User accounts let me share state between them. There’s no protocol yet that lets you do that on the client, though Apple might be working that way.

If you haven’t used the device integration features of OS X and iOS you are missing out. Cut and paste is very, very useful.

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

#159

Post by james-bcn »

seanwilson wrote: post #61
james-bcn wrote: post #55

Earlier quoted context omitted.

What I would like is a good way to create structured data admin systems that can include HTML content, and then have my static generator access that to build the pages via a JSON feed or whatever. For example, having records for individual products including a body description which can be in HTML format. This means that other people can update the products, but we still have a static website. I thought Airtable woul…

Not sure if this helps but Decap-CMS lets you define your own records with fields, like a shopping product record with a price field and Markdown/HTML description, where the content is saved to Git in simple JSON/YAML data files. You can then edit the records via the browser web interface, which commits changes to Git and your static site generator would build the site from the data files. Decap-CMS demo here: https:…

Not exactly what I'm looking for but thanks I'll look into that.
Post reply on HN