The theory versus the practice of “static websites” • Hacker News Board

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

#71

Post by andersa » Sat, Jul 15, 2023, 11:59 AM UTC

ksec wrote: post #58

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

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

#72

Post by ziftface » Sat, Jul 15, 2023, 12:03 PM UTC

toastal wrote: post #30

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…

This is incredibly complex for many static site use cases (i.e. blogs, documentation, marketing pages). Most don’t need JavaScript let alone React/JSX/Middleware/SSR/et al. I can’t imagine the long-term maintenance of something with so many moving parts and npm dependencies. Not saying there’s not a use case, but we should KISS before jumping to projects with a 1.8 GiB Git checkout & 828,128 LoC just to make a landin…

Agreed, but I think most people spend most of their time working on things more complicated than a blog. It seems there's a lot of excitement for purely static sites, which is fine, but I would call it hype at this point, and caution someone jumping into a new project against using a static site generator where it doesn't fit.

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

#73

Post by pembrook » Sat, Jul 15, 2023, 12:07 PM UTC

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…

> 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 able to do my esoteric Git + Hand coding + Markdown/Front Matter + build process steps. So then you get sold some convoluted "HEADLESS CMS," which claims to solve your problems, but is actually a total freaking nightmare to setup and maintain (god forbid you ever want to change anything).

Have witnessed this charade more times than I can count. Seriously, just use Webflow. I know HN is highly disgusted by the idea of something being marketed as a "no-code" tool. But Webflow basically is a static site generator + headless CMS, just with a UI layer for non-technical folks. When you click publish on updates to a Webflow site you're basically automating the recompile and deploy steps.

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

#74

Post by rpdillon » Sat, Jul 15, 2023, 12:17 PM UTC

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 haven't used it, but Publii[0] might be along the lines of what you're thinking of. I ran across it in a previous HN discussion, and it seems to be static site generator with a pretty user-friendly graphical interface.

[0]: https://getpublii.com/

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

#75

Post by BryanLegend » Sat, Jul 15, 2023, 12:25 PM UTC

rpdillon wrote: post #74

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…

I haven't used it, but Publii[0] might be along the lines of what you're thinking of. I ran across it in a previous HN discussion, and it seems to be static site generator with a pretty user-friendly graphical interface. [0]: https://getpublii.com/

I've been thrilled with Publii. So happy to be rid of WP. I use it to run https://legendstudio.com/

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

#76

Post by BryanLegend » Sat, Jul 15, 2023, 12:26 PM UTC

Derbasti wrote: post #16

alxmng wrote: 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.

Publii is a nice, easy to use, self-contained GUI for creating static websites. And Open Source, too.

I've been running a site with Publii (at https://legendstudio.com/) for a few years now. Really happy with it.

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

#77

Post by whstl » Sat, Jul 15, 2023, 12:32 PM UTC

Gordonjcp wrote: post #66

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.

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?

You naturally don’t do this, you can have multiple HTML pages, like a static blog. Or like a lot of forums did in the 90s/early 2000s.

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

#78

Post by jrochkind1 » Sat, Jul 15, 2023, 12:33 PM UTC

alxmng wrote: 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.

If after 20 years of CMS/blogs (WordPress is 20), there isn't yet one...

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

#79

Post by chiefalchemist » Sat, Jul 15, 2023, 12:41 PM UTC

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…

There are a couple of companies/hosts - the names escape me, sorry - that do WordPress to static. That's at least fairly accessible to all/most.

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

#80

Post by shortcake27 » Sat, Jul 15, 2023, 12:44 PM UTC

Gordonjcp wrote: post #66

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.

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?

You wouldn’t pull a 100mb database to query in the browser; that’s not how static sites work. Instead, you’d rebuild the relevant pages whenever the content in the DB changes.

Now, for a forum, I’m not sure this is a good idea, unless you have a super fast optimised build process. Even then, the delay in build is not what people expect from a forum. But the OP is not suggesting pulling a 100mb db down into the browser.