Live data from Hacker News

The theory versus the practice of “static websites”

utcc.utoronto.ca

61–70 of 221 posts

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

#61

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…

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://cms-demo.netlify.com/#/collections/posts

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

#62
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?

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

#63
post #58
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 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…

Lektor CMS is sort of a prototype-ish thing doing this: https://www.getlektor.com/

It has (used to have? Can't find them on the site now) pre-packaged binaries that you would drop into a folder structure generated by the technically-minded person, and the content editor can simply click on that binary, which opens the backend of the CMS in the web browser, make changes and click deploy.

I suppose you could build this on top of Django as well, with django-distill, putting the distill-deploy step into the Django admin and then compiling that to a binary.

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

#64
post #32

Earlier quoted context omitted.

Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of…

Exposing your home devices to the internet is a really bad idea , because it exposes you to doxxing, DDoSing, whatever security issues your 5-year-old smartphone may have, and a plethora of other risks. People used to do this in the 90s and early 2000s, but it turned out to be a hilariously bad idea security-wise. Even the enthusiasts these days use a dedicated server somewhere in a datacenter. Services like Github P…

Other than DDoS, all other issues you mentioned apply equally to all internet facing apps like Whatsapp etc. A static file server can be hardened to the point where only DDoS remains a significant threat and that hardly applies to an average Joe. IF my little site of a few boring pages & pics gets DDoS'ed, then I can move to Wordpress, Cloudflare or whatever.

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

#65

Earlier quoted context omitted.

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…

Indeed it uses pages router, my point was more the timing because it has been posted recently while Lee Rob was tweeting about next export being reenabled (in 13.4 I think). For shalllow routing you are probably right (I don't use them much so I can't tell much, but I do have a few critics regarding app router too) but regarding rewrites, an URL rewrite has to happen in a server so I still don't get your point. What…

Rewrites and redirects do not need to be executed server-side ever since the html5 URL API. Of course you can redirect client-side, as in NextJS: router.push(). And given that redirects/rewrites work for the pages router also contradicts that point.

But yes, you will need to add support within the webserver like nginx. A simple modification to `try_files` will do, and is probably present in most deployments anyway (because you will want URL routes like example.com/news instead of example.com/news.html). I think they just not considered that feature in the design of the app router. And I also don't think it is technically impossible to apply client-side redirects/rewrites within app router.

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

#66

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.

So taking a fairly simple forum that I run as an example, on every page load you'd pull down 100MB or so of database, and then query that down to just the one chunk of a few hundred bytes to display a post, in the browser?

Why is that supposed to be better?

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

#67
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 did the same thing for my site. Custom generator in a few lines of ruby. It’s so much easier and it loads so much faster.

https://www.networksfromscratch.com/

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

#68
post #47
post #2

I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.

You should try one of the free CDNs like Cloudflare or Netlify. Usually they're free for small sites. Integrates with static generators and git and makes the whole thing very simple.

I am using Cloudflare pages and it's super easy to use. In the easiest version, there isn't even git just plain old file uploads.

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

#69
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 did the same with my blog. It was custom written in PHP and was fairly stable, no reddit/hn hug ever killed it but I wrote a wrapper to make it static and now I can host it on a Raspberry Pi with nginx. Even thought about making it solar powered because of the low energy needed.

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

#70

For convenience I prefer wordpress. I am more likely to remember how to use a site in 5 years if maintaining for someone else if it is wordpress than some static site generating script. That is just me though. For a personal blog the idea of going real old school and editing the files (maybe a simple bash script to bulk update menus etc.) is appealing though. Since my metric is “can I come back in a few years and fig…

I love WordPress but wish it had pods built-in and a visual bilder more like Elementor where you can design everything including templates and content types.
Post reply on HN