Don't be Evil Unless It's Profitable

This is a bait-and-switch post

created Feb 5, 2020

Unofficially, big G may have changed its motto more than 10 years ago.

"Google tracks individual users per Chrome installation ID ("

Blah, blah, blah. Or yada, yada, yada.

Many businesses, orgs, and individuals consider Google's vast array of products to be useful. That's a tough monster to undercut, regardless of Google's privacy issues.

Same with Facebook. Literally billions of people find Facebook to be useful and/or entertaining.

Further down in that HN thread, I found this comment, which sounds like something that I would create.

As long as web developers continue to create (app-)sites that only work in the latest versions of Chrome(and Chromium-ish) browsers, giving users little effective choice over what browsers they can use, this sort of abusive behaviour will continue.

The sort of "feature-racing" that Google engages in is ultimately harmful for the open web. Mozilla struggles to keep up, Opera surrendered a while ago, and more recently, Microsoft seems to have already given up completely.

I feel like it's time we "hold the Web back" again. Leave behind the increasingly-walled-garden of "modern" appsites and their reliance on hostile browsers, and popularise simple HTML and CSS, with forms for interactivity, maybe even just a little JavaScript where absolutely necessary. Something that is usable with a browser like Dillo or Netsurf, or even one of the text-based ones.

Making sites that are usable in more browsers than the top 2 (or 1) will weaken the amount of control that Google has, by allowing more browsers to appear and gain userbases.

And as usual, some geeks fail to recognize the difference between a document-type website, such as and an app-type website, such as Basecamp.

When we log into "websites" to do work, such as manage projects, update employee information, email, banking, manage our personal health care, do tax prep, and a zillion other services that permit us to complete private or somewhat private tasks that are not meant to be indexed by search engines, then these can be web applications that place a lot of computer processing on the client-side in the form of sophisticated JavaScript, CSS3, and HTML5.

And these logged-in apps can be accessed over the public internet or within the "intranet" of companies. Many web apps are created for usage within companies.

Do these web apps need to use JavaScript? Probably not, since similar "apps" probably existed 20 to 25 years ago that were built with fairly plain HTML and simple HTML forms and server-side programs via the Common Gateway Interface.

If JavaScript-heavy client-side web apps IMRPOVE the user experience, then that's a good use of JavaScript.

I use Fastmail, which requires client-side JavaScript. I'm good with that because I like Fastmail's web-based email client. But we can use web-based email clients without JavaScript.

When I log into this site, a backup login activiation link is emailed to my account at, which provides two web-based email clients. One uses Squirrel Mail, which functions without JavaScript.

I have created and updated this post by using the Links2 web browser. Links2 does not support JavaScript nor CSS.

Using Links2, it's amazing how suck-ass most document-type websites have been designed. Links2 also shows how incredibly fast the internet functions over a nice home or work internet connection. Links2 shows how incredibly fast websites can be. Sometimes, I blink when I click a link, and I don't realize that the site has loaded. The browser is lightweight and fast, and document-type websites can be incredibly fast if publishers desire.

Anyway, I should not repeat my anger yet again about how designers and developers have created a "modern web" that has ruined the open web for document-type websites, but I will yell at the cloud again.

For logged-in users, the should function more like, but thanks to modern web design's fascination for creating reader-hostile web designs, the Blade's website is an abomination.

The Blade's technical design and its obscene ad pollution is so disgusting that it nearly makes me root against local journalism and root for Facebook to dominate the world, even though I don't use Facebook.

Since small, fast web browsers like Links2 will continue to exist, and since some of us will continue to create humane websites for readers, then a fast, lightweight open web will remain, despite the massive complexity and bloat that exists in the modern web.

HN reply comment to the great HN comment mentioned above:

This proposal would not accomplish what you intend. By slowing the adoption of open web technologies, developers and users would lean more heavily on mobile apps, which are also under Google's control considering Android's huge market share.

Lean more on mobile apps? What in the hell happened in Iowa in this week with its failure to report election results? Why was a native app produced instead of a website or a web app?

Developers who want to level the playing field need to develop sites that fully support Firefox and other browsers that are not based on Chromium. Users who want to see a more open web need to use Firefox and non-Chromium browsers, and complain to developers who don't properly support them.

Firefox has 4 to 6 percent browser share. Web app developers may not have the resources to ensure that their web apps work in a browser that is mainly used by geeks. And the clients who pay for this development may not care if their web app works in Firefox. Why should my bank ensure that its webapp-based site works well in Firefox?

And for web apps meant for internal usage at companies, I'm guessing that most companies standardize on one or two web browsers, and that probably excludes Firefox. I could see internal company web app development focusing only on Chrome.

The frigging document-type web does not need Firefox, Chrome, Safari, nor any of these so-called modern web browsers.

Modern web browsers have become nearly as big and as complex as small operating systems. That's why I like Links2.

Again, I don't think that the first commenter that I excerpted was focused on ALL web app services. I inferred that the commenter complained about complex, bloated modern web design being used for document-type websites. Websites that publish mainly text do not need to be web apps.

Here's another HN reply to the first comment that I mentioned above.

I wish, but that's not what most people want.

Define "most" people. I would love to see the survey where most respondents clamored for the Blade's current atrocious web design.

If most people desired bloated web designs for document-type websites and for websites that permit logged-in users to complete basic tasks and then leave, then NOBODY would use Craigslist.

Craigslist is a document-type website, and it's a website that permits users to create accounts, login, and complete tasks.

Craigslist still uses a fairly lightweight web design. Designers might call Craigslist's design dated. But Craigslist users might call Craigslist's design USEFUL.

A disconnect continues to exist between what designers WANT to create and what USERS find useful.

Craigslist would not exist in 2020 if most users wanted complex, clunky, bloated web designs.

This HN reply comment confuses me.

HTML is not enough. It’s why templating languages / libraries were invented, and it’s why SPA’s are so popular. There’s a difference between “sites” and applications. The web has been trending toward supporting applications more and more for a very long time.

Huh? For over 16 years, I managed a local message board at I created the code that powered the site. The content was stored in a database, and every thread page was dynamically generated on the fly by server side (CGI) code. Obviously, people who posted to the message board created user accounts and logged in to create their thread posts and comments. But in my opinion, Toledo Talk was and still is a document-type website because it was available for the public to READ. Users did not care how the content was stored nor how the web pages were created on the server. The users only wanted to read the threads.

I used Perl on the Toledo Talk server to power the website. I used HTML::Template to help create web pages dynamically. Today, I use Mustache templates with NodeJS and Lua for web applications where web pages get created on the server, either to be stored on the file system as static HTML files or to be sent back to the web browser.

I don't understand what that commenter is saying. Regardless if the requested web page is a static HTML file or a dynamically generated web page, the reader's web browser receives HTML, hopefully. Readers should not receive a blob of JavaScript to display text.

The issue is not with private web apps that we use to complete tasks. The issue is why do document-base websites, such as Reddit, need to be SPAs or need to rely on client-side JavaScript to display content that is mainly text?

That commenter also said:

The only thing that will make people who want to preserve the content-web happy is if we split the protocols somehow, and that will never happen. This is not likely to change ever.

Yeah, I have mentioned that 20 years ago, a new protocol should have been created called "bloat," which would be used to support Java applets, Flash, JavaScript, and today's crappy modern web design.

I can use http or https for my websites, such as,, and, but abominations, such as the new Reddit, the new, the new, etc. would be accessed over the bloat protocol that would require users to install the bloat browser on their various computing devices. What's one more app for desktop, laptop, and mobile computers?


The real, useful web can support HTML4 and CSS2 (maybe some CSS3). NO JavaScript. The useful web would still support HTML forms for user input that get processed on the server, like I did in 1996 when I first started web development.

Of course, this lightweight, useful web still exists alongside the hideous modern web design. I'm proving that with this post.

I continue to use the Links2 web browser to update this post. I'm typing within a textarea box. A plain, humble textarea box.

At, I use a web-based static site generator that I created. I like to create and update web posts through a ... web browser. uses Perl and FastCGI on the server to create and update static HTML files. READERS only see static files that Nginx serves from the file system. READERS see no JavaScript and only a small amount of CSS.

The future for local journalism will probably not include today's newspapers, like the Toledo Blade, that began in the 1800s. Even in 2020, too much 19th and 20th century thinking exists within our local newspapers, especially regarding web ads that exist for logged-in subscribers. ?!?!?

Most of tomorrow's local media orgs do not exist today. The business models used by future local media orgs need to be either hard paywall-based or non-profit, donation based where the content is available to all, but the local media orgs exist because some readers donate money.

The Blade's website does not respect its paying customers. The Blade's website abuses its subscribers. It's an amazing way to treat paying customers.

Future media orgs either need to use ONLY the social media silos, which means no web development, or the media orgs need to respect its subscribers and donors by creating reader-friendly websites, hosted at domain names that they lease.

I like this comment from another HN thread that I read yesterday.

the Web is simply not made for small devices with touchscreens

I think that you are 100% incorrect: the Web (i.e., HTML) is perfect for small devices with touchscreens. As asdff notes, late-90s websites would work perfectly on a mobile device. It's all the cruft we have spent the past twenty years polluting the Web and our browsers with that doesn't work so well in a mobile context.

A mobile phone is perfectly capable of displaying images and text. HTML is perfectly capable of displaying images and text in a device-independent fashion: that was its raison d'etre, as I recall.

I think where we went wrong was assuming that browser windows would be maximised on a desktop screen. That, and JavaScript.

The misuse of client-side JavaScript has been the problem.

This webpage was created in 2003 or earlier.

"The Ancient Craft of Tablet Weaving"

That page uses basic HTML with no JavaScript and no external CSS files. A few HTML tags contain some inline CSS.

The page loads fast and displays fine on my old iPhone 5C. Since the webpage contains no CSS governing font size, the text displays in a tiny font when I hold my phone in portrait mode. It's a little more readable when I hold the phone in landscape mode.

Since the page contains no media queries, the page content is adaptive to the screen size. The content stretches as wide as the browser width.

All of that is okay with me. It's like With Safari on my old iPhone and with Firefox on my new laptop, I can use those browsers' built-in reader mode functionality to display the page even better for me. And I can control some of the typography within those reader mode features, such as foreground and background colors, font type, and font size.

That's how the web SHOULD work. READERS should be in control of how websites appear to READERS.

That tablet weaving webpage uses a brilliant web design in my opinion because it focuses on the content. That page is not being updated to support every damn web asthetic fad that occurs every few years.

The tablet weaving page loads fast and displays well within the Links2 web browser too. The Links2 web browser supports static images.

The brilliantly designed tablet weaving webpage supports modern web browsers and limited web browsers. It's easily cURL-able. That page supports the open web better than most modern web designs.

For this list of images, I used Firefox to update this page because, unfortunately, Flickr requires JavaScript to display images. *%#@!

I use Flickr to store my images that I embed in web posts. I do not use any of Flickr's social whatever features.

This is a screenshot of the tablet weaving web post, displayed within an updated Firefox web browser in full-screen mode, running on my new Ubuntu Linux laptop.

tablet weaving webpage in full-screen mode in firefox

And this is the same web page, further down, that is displayed within Firefox's reader mode, whatever it's called. I set the typography to display dark text on a light background.

tablet weaving webpage in reader mode in firefox

This is the webpage, displayed within Safari on my old iPhone 5C.

tablet weaving webpage displayed normally in safari on old iphone 5c

And displayed within Safari's reader mode on the same phone. This time, I chose the typography to use light text on a dark background.

tablet weaving webpage displayed in reader mode in safari on old iphone 5c

tablet weaving webpage displayed in reader mode in safari on old iphone 5c part two

That tablet weaving webpage and are great examples of brilliant web design for the web of documents, and I consider the page below to be the best article about web design.

When reading that humorous article in the web browsers on my computers, I can increase or decrease the font size, I can resize the browsers windows on desktop and laptop computers, and I can chose the readability or reader mode options if they exist within the web browsers, which allow me to choose my typographical preferences.

Fast, lightweight web pages that FOCUS on content are examples of great web design.

I'm back to updating this page with the Links2 web browser. I also have been using the Links2 web browser to read Hacker News today. And I've used Links2 to view Iowa caucus results at, which have slowly trickled in over the past two days.

A lot of websites seem to work fine within the Links2 web browser, including aggregator sites, such as Memeorandum and Mediagazer. And the sites mentioned on those aggregator sites work too, at least most of them.

With the Links2 web browser, I can read the Atlantic, Washington Post, Politico, Axios, HuffPost, Vanity Fair, the Hill, Daily Beast, NY Times, Talking Points Memo, ProPublica, Hollywood Reporter, BuzzFeed News, and more, but not Mother Jones.

It's unfortunate that micropayments has not and may never become a viable option for paying media orgs for reading their content. It would be great if such a system worked with the Links2 web browser. I probably would not trust micropayments if the setup required client-side JavaScript.