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

141–150 of 221 posts

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

#141

Post by rollcat »

muhammadusman wrote: post #133

Recently, while talking to a friend who hosts her website on Wix, I noticed that she was using it as a portfolio website and I asked what wix-specific features she was using and her answer was "domain management" and this got me thinking...what if the steps were pretty straight-forward, could someone who is not a web dev or technical get a website up on github? So I started putting together a template that looks very…

My partner (who is very non-technical) went through registering a domain, making a Github account, installing VS Code, slapping some HTML together by hand, and putting most of these things together before she even mentioned to me that she wants a website.

Of course it took us a bit more work to polish it, but 90% of the work was hers (I helped with things like setting up Hugo, Netlify, writing some template code, fixing the CSS on mobile, etc).

The biggest pain point of making a static website is just wrangling the generator. We wanted an image gallery with a couple selected works showcased on the front page, and the combination of various Hugo features to achieve that exact effect turned out to be non-obvious. There was probably a way to make it simpler, but we haven't found the time to find it.

I think most non-technical people can easily get the first 90% of the work done by themselves with the currently available tools, it's just the other 90% where you find yourself struggling ;)

(https://alida.gallery/)

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

#142

Post by carlosjobim »

seanwilson wrote: post #138
carlosjobim wrote: post #106

Earlier quoted context omitted.

> 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

It's open source? I'm looking for an open source solution. You never know when they'll change their pricing, like when Forestry was recently deprecated in favour of Tina CMS with more limited free plans.

[flagged]

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

#143

Post by immibis »

andersa wrote: post #71
ksec wrote: post #58

Earlier quoted context omitted.

This really should have been the case once we moved to SSD on server. For 95+% of all website, we likely have enough RAM to store 70% of the Hot Content in Cache and 30% of the content served from SSD at 10,000 IOPS Random Read. Unless you constantly fiddle with the site design, the site and HTML generation should really be on devices and the whole thing should take less than a second to generate. Unfortunately as ot…

It's such a tragedy Intel completely dropped the ball on Optane drives. With them having an order of magnitude higher random IOPS, it would have been incredible for servers!

Samsung claims to deliver half a million IOPS on 980 NVMe drives. Is that not enough for you?

Previous generation 970 claims to deliver 50k IOPS

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

#144

Post by immibis »

mjevans wrote: post #49
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…

An edited site could also (mostly) be static if edits pushed / queued a job to publish the updated static content. Ideally a casual visitor would never see non-static content, other than possibly dynamic addins that mix the data client side if they have an active account.

CMV: if you're running code on the server anyway, there's no advantage to having all the precomputed header+content+footer combinations. You may as well run a script that combines the generic header + specific content + generic footer at request time. The advantage of static sites is that you don't have to worry about any server scripting at all.

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

#145

Post by thrashh »

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…

A static web server can theoretically be induced to execute code because it still has parsers.

While I do agree a static site has a smaller attack surface, I think it’s more that nginx has way more eyes on it and a much slower development rate than your average custom configuration of WordPress plugins.

Because if you were to build your own static web server, your first version would probably more susceptible to attack than a stock WordPress installation.

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

#146

Post by immibis »

marcosdumay wrote: post #111
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…

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

As they said, it's attack surface. The static site does one thing; the Django site does more things. This is the use-case difference you're talking about: the more your code does, the more likely it is to have vulnerabilities. And it's actionable: make your code do as few things as possible.

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

#147

Post by snowwrestler »

jameshart wrote: post #127
kodah wrote: post #121

Earlier quoted context omitted.

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.

Commodity hosting with proper security is also available for dynamic website technologies.

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

#148

Post by floren »

My personal website is an odd mix of static and dynamic; that is, it's mostly static, but the blog portion is dynamic. When you hit a blog URL, it fetches a Markdown file from the disk, converts to HTML, and then jams that HTML into a template which provides the rest of the page, brings in CSS, etc.

It's still fast and efficient; when one of my blog posts was #1 on HN last week, my friend texted me "good luck, hope you have Cloudflare set up". I don't, but the load average on my 2 core, 1GB memory VPS never exceeded 0.15.

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

#149

Post by snowwrestler »

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…

Back in the day, Drupal had a module called “Boost” that sort of did this. Once you activated it, it baked out every page of the site to HTML in a directory, and altered .htaccess to send all traffic there. When you updated content, it rebaked everything.

https://www.drupal.org/project/boost

Post reply on HN