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

191–200 of 221 posts

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

#191

Post by chrisldgk »

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…

Webflow has some huge constraints when you’re trying to actually build a good marketing page. Try framer instead, the fact that you can rely on React for anything that’s not possible to do in the visual editor is a life saver and actually enables you to build sites that are on-par with traditional headless CMS plus meta framework stacks while still being just as easy (if not easier) to maintain by non-technical users. The only problem is the price-tag which means you’ll be outpriced for small personal projects but it’s still a good deal for startups and bigger companies.

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

#192

Post by ytjohn »

victorbjorklund wrote: post #137
zzzeek wrote: post #90

the very important thing about static sites are that you can much more easily "fire and forget" a static site - put it up on an S3 bucket site or whatever and you are pretty much in the clear about worrying about it. put up a "fire and forget" site using any kind of PHP or (perish the thought) wordpress (assuming self hosting), and if you dont check that site a few times a year, it will be all Russian porn ads before…

And if you dont get hacked you risk that your site is just offline due to something breaking down (maybe the db needs to be restarted, maybe the webhost changed php version etc). I got a couple of static sites and it so nice to know they are always up and never need to be fixed. My dynamic sites on the other hand needs to have alerts to check if they go down.

Outdated PHP is a big thing. So many times I've pulled a php file from an old server and it fails to run on the new because some methods were deprecated twenty-dickety-two. Which isn't a criticism of the language, just how things go. You either have to rewrite it to modern or run an unsupported version of PHP.

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

#193

Post by atahanacar »

carlosjobim wrote: post #142
seanwilson wrote: post #138

Earlier quoted context omitted.

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]

>I don't understand why people complain about the lack of tooling, when practically perfect tooling exists.

A tooling can't be called perfect if you have no control over it. Having your workflow depend on software that you don't own and can't control is anything but perfect.

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

#194

Post by bjornasm »

nicbou wrote: post #177
Daril wrote: post #19

Earlier quoted context omitted.

This is very interesting. Impressive how much efficiency and performance is gained. This also means that fewer resources (electricity) are consumed, that less bulky hardware is used and, most importantly, that security is improved. A static website is more difficult to attack and the only possible flaw is in the web server and not in the code of the website. I usually use Hugo. It is very complete and rich in feature…

I have a robot vacuum cleaner that runs linux, and it CAN run a Caddy server. I managed to get a website running on it last time. Now that my websites are static I'm tempted to host my personal blog on it. I try to keep things simple. Simple websites are fast and reliable. Turbo seems to be a departure from that. Since the heaviest part of my pages is the text, it would not help much.

Please do this and write a blogpost about it!

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

#195

Post by toast0 »

kodah wrote: post #120
Daril wrote: post #19

Earlier quoted context omitted.

This is very interesting. Impressive how much efficiency and performance is gained. This also means that fewer resources (electricity) are consumed, that less bulky hardware is used and, most importantly, that security is improved. A static website is more difficult to attack and the only possible flaw is in the web server and not in the code of the website. I usually use Hugo. It is very complete and rich in feature…

> This also means that fewer resources (electricity) are consumed Most servers in the world use a constant amount of electricity, regardless of load. Generally the way to make DCs more green is to build them around a renewable plan with batteries (that they already need). Save for the fact that the whole thing is made of rare earth metals and lead, and you've got yourself something pretty green.

> Most servers in the world use a constant amount of electricity, regardless of load.

That seems unlikely. Even if you disable frequency scaling, hlt uses less energy than a full pipeline of avx. Disks use more energy when reading or writing than idle (although for spinning disks, if they're not idle enough to spin down, the difference isn't that much)

Datacenters do tend to have a lot of batteries, but the runtime expectation is pretty small, 5ish minutes takes a lot of batteries and is enough for the onsite backup generator to start amd warm up. It's been a while; maybe those aren't lead acid anymore, but they used to be. Stationary, weight doesn't matter, volume isn't super important, cost is important, leads towards lead acid, IMHO.

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

#196

Post by andersa »

immibis wrote: post #143
andersa wrote: post #71

Earlier quoted context omitted.

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

They claim that but it's not true. It will deliver significantly less than that in 4k random read.

I don't have the link to benchmarks at hand right now, but there was a review running CrystalDiskMark on these drives and the 4k random performance of the Optane drive was more than 10x the 980 pro. For servers delivering tons of small-ish files, that's exactly the use case.

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

#197

Post by carlosjobim »

atahanacar wrote: post #193
carlosjobim wrote: post #142

Earlier quoted context omitted.

[flagged]

>I don't understand why people complain about the lack of tooling, when practically perfect tooling exists. A tooling can't be called perfect if you have no control over it. Having your workflow depend on software that you don't own and can't control is anything but perfect.

Then you should program it yourself and not ask anybody else for it.

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

#198

Post by pembrook »

chrisldgk wrote: post #191
pembrook wrote: post #73

Earlier quoted context omitted.

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

Webflow has some huge constraints when you’re trying to actually build a good marketing page. Try framer instead, the fact that you can rely on React for anything that’s not possible to do in the visual editor is a life saver and actually enables you to build sites that are on-par with traditional headless CMS plus meta framework stacks while still being just as easy (if not easier) to maintain by non-technical users…

I'm surprised you'd say Webflow has the constraints vs. Framer. Framer definitely seems promising but is way too limited and basic at the moment. They don't even have an API, and the CMS just feels super sandboxed. Good luck doing any of the programmatic SEO stuff you can do with Webflow. I'm confident they'll get there in a few years though.

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

#199

Post by forrestthewoods »

dpritchett wrote: post #86
forrestthewoods wrote: post #46

My blog is static and doesn’t even use a static generator. For the mildly capable programmer I’m fully convinced this is the way. https://www.forrestthewoods.com/blog/

Can you describe your process? Do you just hand type import-free HTML and rsync it up to a web server? I’d make so many syntax errors without at least some sort of lint/build step.

My blog is hosted on Netlify and lives in a GitHub repo. Updating the public blog is as simple as git push.

I write and iterate my blog posts in a raw text file. When I’m happy I make a copy/paste an existing post and then modify the title and body.

There’s no server or build step. I just open the local .html file in my local browser. My build process is change HTML and press F5 in browser.

I have experimented with markdown-to-html converters. They’re ok but not a game changer.

Most of my posts have no JavaScript. But a few with custom visualizations do.

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

#200

Post by ksec »

immibis wrote: post #143
andersa wrote: post #71

Earlier quoted context omitted.

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

Those numbers are quoted with high Queue Depth. So not always applicable depending on circumstances. But even in the worst case scenario of QD1 it is still plenty for 95%+ of sites.
Post reply on HN