Live data from Hacker News

How to Build a Low-Tech Website

solar.lowtechmagazine.com

171–180 of 188 posts

Re: How to Build a Low-Tech Website

#171

Earlier quoted context omitted.

> First, get rid of the `etag`, `expires`, and `last-modified` headers and go with expiration caching only. Increase the `max-age` from one day (86400) to one year (31536000). Since it's a statically generated website, I'd favor never expiring the cache, and using cache-busting hashes instead. That way the cache is only emptied when the file actually changes.

Isn't the etag just a hash of the content?

It can be, but doesn't need to be as long as it is some sort of indication of the uniqueness of the content. A last modified date should work in the same way.

Re: How to Build a Low-Tech Website

#172
post #117

Earlier quoted context omitted.

Honestly, I'm not even sure what modern website are doing when they generate pages. I've had highly dynamic PHP/MySQL websites running on crap hardware, and it was trivial to attain .03 second page generation time. Didn't even need fancy caching, just some common-sense SQL optimizations.

At my last job we had an ad bidding API that would reach out to every advertiser we worked with, got the highest bid, then presented an advertisement to them. The page was also framework after framework piled on top of each other, so they’d be using React and jQuery at the same time, stuff like that. And so marketing could change whatever they wanted whenever they wanted without breaking the entire site, everything w…

LOL - oh man... I can relate!

At a previous gig we had a similar situation. It was so bad my coworkers and I would joke that we needed one of those "break in case of emergency" boxes with the glass front and a hammer hanging adjacent. Inside the box: a can of lighter fluid and a match. The purpose: when the crazy got to be too much you just light own hair on fire and then go run around in traffic.

What you just described would definitely be a break the glass kinda situation :-)

Re: How to Build a Low-Tech Website

#173
post #102
post #81

I am going to guess they are getting a massive surge of traffic about now and yet the site still renders in a fraction of the time it takes most "modern" web apps or even just static content sites - this is how it should be.

A trillion npm packages will for sure add a couple seconds of delay to your website loading speed.

`npm install the-entire-universe`

Re: How to Build a Low-Tech Website

#174

And then, at the end, there's one line of useless info - a weather forecast for their server location. Forecast: today Partly cloudy in the morning and breezy until afternoon. / tomorrow Partly cloudy until afternoon. / day after tomorrow Clear throughout the day. For that, they pulled in JQuery and made a XMLHTTP request.

The weather content is relevant in that their server would go offline with too many cloudy days. If their intent is to lower energy consumption of their server alone, offloading this weather check is the correct choice. But surely requesting+caching that info on their end (by perhaps rebuilding the static site every hour with an updated forecast) would be overall more efficient than having X number of clients request…

All it amounts to is one additional request, and the json file itself is probably generated by a cron job, not dynamically on demand.

Surely rebuilding the website every hour (and invalidating the cache for X number of clients) would result in more requests.

Re: How to Build a Low-Tech Website

#175
post #103

Could save an easy 80kB by cutting out Jquery. All it does is the little weather widget, and could be easily written in standard js.

In a similar vein, the weather icons are 800x800px images displayed at no larger than 20x20px

Those large icons are rather compression friendly compared to the dithered images. It would still be a relatively huge save at 20x20 (after resize to 20x20 with imagemagick and pngcrush -brute, the 5.5k clear-day.png goes down to 559 bytes).

Re: How to Build a Low-Tech Website

#176

Dithered images do not compress well. I'd be interested to see side-by-side comparisons of optimised pngs, optimised jpeg, reduced-pallete optimised pngs, and some more cutting-edge formats like BPG[0] and FLIF[1] [0] https://bellard.org/bpg/ [1] https://flif.info/

> Dithered images do not compress well.

That does somewhat depend on whether we are talking about positioned or Floyd-Steinberg dithering. Positioned dithering is a lot more regular and predictable, and hence easier to compress.

Re: How to Build a Low-Tech Website

#178
post #72

Earlier quoted context omitted.

The CSS @media attribute has been widely available since IE6. It's not exactly high tech.

Are we discussing about high tech or low tech?

You're in a thread about low tech websites bragging that your website is so low tech that it doesn't work with mobile devices.

I'm just saying the low tech and mobile compatibility aren't mutually exclusive.

Re: How to Build a Low-Tech Website

#179
post #140

I love the aesthetic! Great work. Here's my unsolicited design riff on the "battery indicator." I'm a fan of the concept, but the 100vw element width of the yellow fill was distracting me from the rest of the content. I used DevTools to mock up a narrow version which fits within the right content gutter, right next to the scroll bar. I had to tweak the percentage metric display a bit by stacking the sun above the val…

I strongly agree that design element makes it look broken. I checked my uMatrix to make sure it wasn't blocking any styles before realizing that it was part of the design. I had a similar thought about a vertical bar that doesn't take up 100cw. Nice mockup!

Re: How to Build a Low-Tech Website

#180
This is one of the coolest web projects I've seen lately. Great job!

> Increasingly, activities that could perfectly happen off-line – such as writing a document, filling in a spreadsheet, or storing data – are now requiring continuous network access. This does not combine well with renewable energy sources such as wind and solar power, which are not always available.

I'm surprised no one has mentioned progressive web apps. This seems like a perfect use-case for them.

On a related note, I just found this research showing that Service Workers (on which PWAs are built) "do not have a significant impact over the energy consumption of [mobile] devices, regardless of the network conditions." [0]

[0]: http://www.ivanomalavolta.com/files/papers/Mobilesoft_2017.p...

Post reply on HN