What you really want is a (mostly) JavaScript-free website. Run NoScript and cut out all the data broker bloat, allowing just a limited number of critical scripts to run. Adding LocalCDN will further reduce wasted transfers of code that you do allow. Then you can decide if you want to show images. The web will be much faster on a fast or slow link.
As a mild lifelong disaster "junky" (grew up in remote areas, dealt with cyclones, floods, droughts, fires, monsoons, coup d'etats, unannounced atomic tests etc during decades of global field work) this description:
As a web developer, I am thinking again about my experience with the mobile web on the day after the storm, and the following week.
I remember trying in vain to find out info about the storm damage and road closures—watching loaders spin and spin on blank pages until they timed out trying to load.
reminds me why we (locally) still rely on AM radio day in day out and will continue to do so for the forseeable future.
"The last couple times I used my dental insurance website, it was completely not mobile responsive, requiring the old-school pinch zoom to even get to anything on the page."
And yet you probably didn't change your dental insurance based on this, because most likely there are more important issues that matter (e.g. you are given a single option by your employer). This is exactly the reason why that company is not likely to fix it, because the lousy website's effect on their bottom line is nearly zero. (Note that I don't like this either)
- AT&T was completely down for us but Verizon and its MVNOs were up
- I had a Verizon MVNO secondary e-sim that came free with a home internet plan, unused until the hurricane hit
- It worked pretty well!
- The day the Verizon disaster internet trucks showed up at the police station in our town my Verizon MVNO internet went down
Non-internet learnings:
- Fill up your vehicle’s fuel or battery before any big storm, we spent a lot of time siphoning and otherwise consolidating fuel to get ourselves and neighbors out of town, particularly because we didn’t know how far we’d have to go to find a gas station with electricity
One thing that I would also suggest folks who are resonating with this piece consider...
Local copies of important information on your mobile device. Generally your laptops are not going to see much use. Mobile apps tend to fake local data and store lots of things to the cloud. We tend to ignore such things like backups and local copies nowadays. Most of the time we can get away without any worry here but consider keeping a copy of things like medications and their non commercial names for situations like this as well.
Reading this on airline wifi right now makes me realise just how unusable some stuff becomes with choppy internet. E.g. I can’t change settings on the LinkedIn app because the request to load the settings page fails :/.
Some things you don't know people need until you're directly affected. For me, it was an injury related light sensitivity that made me realise dark mode isn't just a frivolous addition for looks
Author should look into WinLink. There is WinLink Wednesdays where WinLink is practiced. A lot of reports come out of WinLink and it’s all text. Of course need to be an Amateur Radio Operator
Many years ago, Google had a service I would use pre-Smartphone days to search when I was away from the PC and needed info for like a restaurant’s number. You would text 46645 and it would send you search results. It was useful during hurricanes.
If you decide to add an off-the-shelf wad of CSS, like Pico.css, consider hosting it alongside your HTML (rather than turning it into another third-party dependency and CDN cross-site surveillance tracker). Minified, and single-request.
A related article I read yesterday lamented that 1GB of RAM isn't enough to run a graphical browser anymore (1). Sure JavaScript runs fast now, but at the cost of the code size of the average website being unnecessarily large. This is because speedy js and speedy network connectivity allows for more code, more network requests. Another example of Wirth's law.
This was the case when I got a Rapberry Pi 4 with 1GB of RAM about late 2019. You could run one tab of Chrome, but any more and it would be killed.
Oh for the time when chairs were still for sitting and PDFs were still for printing.
Restaurant websites mentioned — the majority of restaurant web sites I’ve encountered were much more annoying and difficult to read than a PDF, even on a small phone screen. Or should I say, especially on a small phone screen. Some would make a 32 inch monitor feel cramped.
It's stuff like this that makes me want to scurry right back into the SRE/sysadmin space. Currently back in webdev after a few years out. I just feel like I'm being a pain in the arse to comment "could just write the HTML...?".
This very article loaded 2.49MB (uncompressed) over 30 requests. It's served using Next.js (it does actually load fine with JS disabled).
Ironically this is a great opportunity for the author to have made a stronger point. It could have gone beyond the abstract desire of "going back to basics" to perhaps demo reworking itself to be served using plain HTML and CSS without any big server-side frameworks.
The header image in the article is a 2400x1600 PNG that is 500KB large, apparently due to subtle dithering making it hard to compress. Converting it to a visually-identical .avif (quality 90, 12-bit color depth) takes it all the way down to 15KB.
Plain HTML and forms for interactivity can be very effective.
In fact, for a long time web forums were largely entirely usable without JS.
See the degradation of GitHub for a great example. You used to be able to interact with most of it without any JS at all; browsing the code repositories, reading and replying to issues, etc. Now it barely shows anything without JS. Of course, I suspect in that case it's deliberate so they can trick you into running a few more tracking and analytics scripts...
I think many of us in the web space that are old enough were shaped by the "mass outage" that happened on 9/11 when pretty much all news websites went down while we were looking for information. Slashdot was fighting valiantly to say up and was one of the few sites one could find information on the events (if you were in a spot without access to a cable TV, you were very much in the dark). The web and the infrastructure are substantially different than they were 25 years ago, but I still get a bit of "what if" in the back of my head (not that I work on anything of that level of significance).
I have a tab on sublimetext that has been opened since the pandemic and I think it's safe to share my idea since I'm not gonna do it.
*4KB webpage files*
So a website where each page does not exceed 4KB. This includes whatever styling and navigation needed. Surprisingly you can share a lot of information even with such constraints. Bare bone html is surprisingly compact and the browser already does a whole lot of the heavy lifting.
Why 4KB? Because that used to be the default page size in x86 hardware. So you can grab the whole thing in one chunk.
64 comments
[ 2.5 ms ] story [ 57.8 ms ] threadhttps://lite.cnn.com/
https://text.npr.org/
https://wttr.in/
More listed at https://greycoder.com/a-list-of-text-only-new-sites
It’d be great if there was some standard that allowed these to be easily found, and supported on the local news sites.
I can reformat the text any way I like
I think with a little effort they could make it pretty frictionless for their users who it turn would be happy to provide it.
https://news.ycombinator.com/newsguidelines.html
- AT&T was completely down for us but Verizon and its MVNOs were up
- I had a Verizon MVNO secondary e-sim that came free with a home internet plan, unused until the hurricane hit
- It worked pretty well!
- The day the Verizon disaster internet trucks showed up at the police station in our town my Verizon MVNO internet went down
Non-internet learnings:
- Fill up your vehicle’s fuel or battery before any big storm, we spent a lot of time siphoning and otherwise consolidating fuel to get ourselves and neighbors out of town, particularly because we didn’t know how far we’d have to go to find a gas station with electricity
Local copies of important information on your mobile device. Generally your laptops are not going to see much use. Mobile apps tend to fake local data and store lots of things to the cloud. We tend to ignore such things like backups and local copies nowadays. Most of the time we can get away without any worry here but consider keeping a copy of things like medications and their non commercial names for situations like this as well.
Truly a sign of our times
tl;dr Use dark mode and set f.lux (or the equivalent) to Cave Painting. Helped me out a lot
Many years ago, Google had a service I would use pre-Smartphone days to search when I was away from the PC and needed info for like a restaurant’s number. You would text 46645 and it would send you search results. It was useful during hurricanes.
If you decide to add an off-the-shelf wad of CSS, like Pico.css, consider hosting it alongside your HTML (rather than turning it into another third-party dependency and CDN cross-site surveillance tracker). Minified, and single-request.
This was the case when I got a Rapberry Pi 4 with 1GB of RAM about late 2019. You could run one tab of Chrome, but any more and it would be killed.
(1) https://log.schemescape.com/posts/hardware/farewell-to-a-net...
Restaurant websites mentioned — the majority of restaurant web sites I’ve encountered were much more annoying and difficult to read than a PDF, even on a small phone screen. Or should I say, especially on a small phone screen. Some would make a 32 inch monitor feel cramped.
This very article loaded 2.49MB (uncompressed) over 30 requests. It's served using Next.js (it does actually load fine with JS disabled).
Ironically this is a great opportunity for the author to have made a stronger point. It could have gone beyond the abstract desire of "going back to basics" to perhaps demo reworking itself to be served using plain HTML and CSS without any big server-side frameworks.
In fact, for a long time web forums were largely entirely usable without JS.
See the degradation of GitHub for a great example. You used to be able to interact with most of it without any JS at all; browsing the code repositories, reading and replying to issues, etc. Now it barely shows anything without JS. Of course, I suspect in that case it's deliberate so they can trick you into running a few more tracking and analytics scripts...
<html> <pre> TEXT </pre> </hml>
*4KB webpage files*
So a website where each page does not exceed 4KB. This includes whatever styling and navigation needed. Surprisingly you can share a lot of information even with such constraints. Bare bone html is surprisingly compact and the browser already does a whole lot of the heavy lifting.
Why 4KB? Because that used to be the default page size in x86 hardware. So you can grab the whole thing in one chunk.
This whole comment is not 1KB.