The Opposite of Modern Web Design is Useful Design

"Ignore conventions"

"Aesthetics without utility is art"

created Fri, Mar 13, 2020

My title implies that "modern" web design does not provide utility. That's false. On my laptop and smartphone, Fastmail's web-based email client is useful. I consider it a well-made web application. Many other complex web apps that permit tasks to be completed in private are also useful.

But as usual, I'm focused on the "Web of Documents" type of websites.

Mmm, is a web app or a web of documents website? I lean more toward the latter, even if the site offers the ability for users to create accounts and to login, and even if most pages are dynamically generated on the SERVER.

That's my modified definition for a web of documents. It's not as strict as what the author suggested at

In my opinion, my website here at (static HTML files for readers) and my message board are web of documents websites. At Toledo Talk, most of the people who viewed the site were browsing-only users. They did not create user accounts.

But even for logged-in users at Toledo Talk, I believe that the message board was still a web of documents website. Every web page at Toledo Talk was dynamically created on the server. Except for the goofy drop-down menu that appeared on small screens (my bandwagon-design from the mid-teens), Toledo Talk readers did not need to execute code on their computers to display text and images in the threads.

Newspapers websites, such as the, are or SHOULD be a web of documents, but the Blade fails at this.

My older posts:

And if website uses static HTML files, that does not mean that the website is fast-loading and lightweight. So-called static HTML pages can contain links to megabytes of JavaScript that gets executed on users' computers. If it's a web application that requires users to login and perform tasks in private, then that's fine, I guess. But if the site is suppose to be a web of documents type of website, and it forces unsuspecting readers to download and execute megabytes of JavaScript to view text, then that's an abomination.

So-called static document-based websites do not imply fast, lightweight, easy-to-use websites. And conversely, document-based websites where every page is dynamically-generated on the server does not mean that those sites are slow-loading and cumbersome to use.

In my opinion, a Web of Documents website should not require readers to use JavaScript.

  1. I should be able to read the website in a modern web browser with JavaScript disabled.
  2. I should be able to read the website in limited web browser, such as Links2.
  3. At the command line, I should be able to generate a plain text version of the webpage by using the dump command associated with either Lynx or Links2 or by using cURL and some kind of html2text utility.

Sadly and pathetically, too many websites, such as's homepage,'s article pages,'s homepage, fail on point number one, listed above.

When viewing those sites in Chrome or Firefox with JavaScript disabled, the screen is blank, or it's blank where it's important, such as the content area.

But when I view those same sites in Links2 or fetch their content with command line tools, the sites work fine.

Well, not exactly. fails all three of my conditions, listed above, and Dave Winer was one of the pioneers of blogging and RSS in the 1990s. The open web weeps. Dave's /yyyy/mm pages, however, display without JavaScript.

Obviously, their CSS is tied to their absurd JavaScript setup somehow. Why? They are Web of Documents websites and not web applications. I don't attempt to visit those sites for their aesthetics. I want to READ their content.

My "quote" type of post from Feb 10, 2020 contained the follow comment from a Hackers News thread:

I hate browsing the modern web. It's like wading through a sewer looking for treasure.

And my quote-type of post from Jan 31, 2020 contained this gem from a HN thread:

People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy.

JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requirements for a web of interlinked documents are a protocol (we have HTTP) and a document format (HTML); a style format (CSS) is nice too, albeit not strictly necessary (one can read unstyled documents in links, lynx, elinks, eww, w3m or whatever else just fine).

That's true only if web publishers of WOD sites have a desire to support the open web.

Also known as, if it's not curlable, it's not on the web.

More from that same HN commenter, mentioned in my Jan 31, 2020 post:

There is absolutely no requirement for executing arbitrary, potentially malicious, unverified code from untrusted authors distributed globally. Are there great examples of cool JavaScript applications? Yes, certainly.

Is JavaScript a core requirement to support a web of interlinked documents — i.e., the Web? No, not at all.

To the contrary, JavaScript is murdering the Web, and this page's misuse is a prime example. JavaScript delenda est!

And now my comment from that post:

The problem is not JavaScript. The problem is the unnecessary usage of client-side JavaScript that is murdering the open web of documents.

My Jan 31, 2020 post also contained this HN comment:

Please render your markdown on your server and not my client. You're wasting my battery, man. Shame on you!

Hey, that's right. Web of Documents websites should be designed to be environmentally-friendly.

Web of Documents websites should function like tools. I use tools, such as a claw hammer, a pitchfork, a garden rake, and a snow shovel for specific tasks. I choose to correct tool for the task. I don't use a garden rake to remove snow from our sidewalks and driveway. I don't use a claw hammer to sling mulch.

I don't visit for political news. I don't visit to read about blogging and RSS concepts. I view Web of Documents websites as tools, meant to inform, inspire, entertain, and to ponder.

If the content is interesting and/or useful, then I return to those websites. If the content disinterests me, then I don't return. Aesthetics are not enough.

Besides, I prefer to theme other websites on MY computer, which was how the web was originally conceived, I think. Readers were suppose to be in control of how websites looked to themselves. This is my related post and test website to the idea of readers controlling how websites should look.

Mar 12, 2020 Hacker News thread that pointed to this article:

From the article:

When I showed this design to Yuri Westplat, a colleague of mine and very experienced UX designer, he exclaimed: "this is what websites looked like in the nineties! Where did we go wrong?!"

Yuri seems to agree with me that there may be something wrong with our current conventions and that it might be a good idea to follow the second Exclusive Design Principle, which says that we should ignore conventions.

Excerpts from that principles page, which contains links to pages that explain the following:

A couple of my other older posts:

Quote: "Design without content is just decoration." — Jeffrey Zeldman tweet

Sun, Mar 22, 2020

So-called "modern" web design is failing at the wrong times. At 3:22 p.m., Ohio governor Mike DeWine concluded a press conference. The conference focused on a new directive handed down by the governor that will go into affect tomorrow night. I have no idea what it's about. The governor and the others speaking at the press conference know that their website is unresponsive, but the officials were not repeating whatever it is that we are suppose to read on a website that does not work because of traffic.

Simple, static HTML pages that contained mainly text should respond if hosted at AWS S3 or at some other similar service. But I have visited Ohio's Covid-19 website recently, and it uses a bloated modern web design.

These are the errors that I'm receiving when I attempt to access that site around 3:00 p.m. today.

The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

Generated by cloudfront (CloudFront)
Request ID: yXWRjI4DvVH5u3puyXvt6y9NSQ0bKVuLjYo0ObzUEtmoaCnAE-G1FQ==

502 Bad Gateway

504 Gateway Time-out

I saw this once on a partially loaded homepage:

IBM WebSphere Portal

There is no alerts.
Click here for view more about it. VIEW MORE

Mon, Mar 23, 2020

Unsure of results from a week or two ago. Need an older test to compare to see if changes were made to make the homepage more efficient. redirects to the URL shown below in the test.
From: Dulles, VA - Chrome - Cable
3/23/2020, 6:20:49 AM
First View Fully Loaded:
Download time: 7.774 seconds
Web requests: 82
Bytes downloaded: 3,560 KB

1.89 megabytes of the download were do to JavaScript. This is obscene for an important informative website that SHOULD be designed to be a Web of Documents type of website.

Nearly 2 megabytes of JavaScript. Was that one of the main culprits for why the site was unresponsive during the state's presser yesterday afternoon? It was probably one of MANY reasons why the site failed.

The HN threads listed below were started today, Mon, Mar 23, 2020. It's nice to see others think about this issue too, but it's not new. Failed web designs have existed for years at the local and regional levels, and it these failures become apparent after natural disasters and other major local news events.

Websites for media orgs and local governments are designed with too much bloat on the client and server sides, leading to either unresponsive websites or sites that fail to load in a reasonable time over reduced internet access speeds.

Today's "live blogs" maintained by media orgs during major news events are horribly bloated. The media's live blogs are not designed with empathy for people who may have trouble powering devices or might have sluggish internet connections. Client-side bloated websites drain batteries faster.

Media live blogs should be a useful source of information for the public, during major news events. But media live blogs are polluted with embedded videos, large images, and far too much social media bloatware. Since media people can easily access their live blogs from within their companies, and then must assume that everyone can access the content in the exact same manner.

Get Static (

A Starter Kit for Emergency Websites (