Static HTML pages are better than "web apps".

Static HTML pages are more lightweight and destroy "web apps" in performance, and also have superior compatibility. I see pretty much no benefit in a "web app" over a static HTML page. "Web apps" appear like an overhyped trend that is empty inside.

During my web browsing experience, static HTML pages have consistently loaded faster and more reliably, since the browser is immediately served with content useful for consumption, whereas on JavaScript-based web "apps", the useful content comes in **last**, after the browser has worked its way through a pile of script.

For example, an average-sized Wikipedia article (30 KB wikitext) appears on screen in roughly two seconds, since MediaWiki uses static HTML. Everipedia, in comparison, is a ReactJS app. Guess how long that one needs. Upwards of three times as long!

Making a page JavaScript-based also makes it fragile. If an exception occurs in the JavaScript, the user might end up with a blank page or an endless splash screen, whereas static HTML-based pages still show useful content.

The legacy (2014-2020) HTML-based Twitter.com loaded a user profile in under four seconds. The new react-based web app not only takes twice as long, but sometimes fails to load at all, showing the error "Oops something went wrong! But don't fret – it's not your fault." to be displayed. This could not happen on a static HTML page.

The new JavaScript-based "polymer" YouTube front end that is default since August 2017 also loads slower. While the earlier HTML-based one was already playing the video, the new one has just reached its oh-so-fancy skeleton screen.

It would once have been unthinkable to have a website that does not work at all without JavaScript, but now, pretty much all popular social media sites are JavaScript-dependent. The last time one could view Twitter without JavaScript and tweet from devices with non-sophisticated browsers like Nintendo 3DS was December 2020, when they got rid of the lightweight "M2" mobile website.

Sometimes, web developers break a site in older browser versions by using a JavaScript feature that they do not support, or using a dependency (like Plyr.js) that breaks the site. Static HTML is immune against this failure.

Static HTML pages also let users maximize speed and battery life by deactivating JavaScript. This obviously will disable more sophisticated site features, but the core part, the text, is ready for consumption.

Not to mention, single-page sites and fancy animations can be implemented with JavaScript on top of static HTML, as GitHub.com and the 2018 Reddit redesign do, and Twitter's 2014-2020 desktop front end did.

From the beginning, JavaScript was intended as a tool to complement, not to replace HTML and CSS. It appears to me that the sole "benefit" of having a "web app" is that it appears slightly more "modern" and distinguished from classic web sites due to use of splash screens and lack of the browser's loading animation when navigating, while having oh-so-fancy loading animations and skeleton screens inside the website. Sorry, I prefer seeing content quickly over the app-like appearance of fancy loading screens.

Arguably, another supposed benefit of "web apps" is that there is no blank page when navigating between pages, but in pretty much all major browsers of the last five years, the last page observably remains on screen until the next navigated page is rendered sufficiently for viewing. This is also known as "paint holding".

On any site, whenever I am greeted with content, I feel pleased. Whenever I am greeted with a loading animation, splash screen, or skeleton screen, be it ever so fancy (e.g. fading in an out, moving gradient waves), I think "do they really believe they make me like their site more due to their fancy loading screens?! I am not here for the loading screens!".

To make a page dependent on JavaScript and sacrifice lots of performance for a slight visual benefit does not seem worthed it.

Quote:

> "Yeah, but I'm building a webapp, not a website" - I hear this a lot and it isn't an excuse. I challenge you to define the difference between a webapp and a website that isn't just a vague list of best practices that "apps" are for some reason allowed to disregard. Jeremy Keith makes this point brilliantly.
>
> For example, is Wikipedia an app? What about when I edit an article? What about when I search for an article?
>
> Whether you label your web page as a "site", "app", "microsite", whatever, it doesn't make it exempt from accessibility, performance, browser support and so on.
>
> If you need to excuse yourself from progressive enhancement, you need a better excuse.

– Jake Archibald, 2013

Firefox and Chrome removing FTP support in 2021 was a terrible decision.

Web browsers were simply the more convenient FTP browsers, more than file managers, due to browsers' built-in multimedia capabilities like photo viewing and opening documents, distinct purple highlighting of already opened directories and files, browsing history, familiar mouse shortcuts like middle click for new tab, and no possibility of accidental writes due to a botched drag-and-drop operation or similar.

If I wanted to browse an FTP server in "read-only mode", web browsers used to be the preferred choice.

I despise it when software developers remove features because "too few people use them".

Is this what those shady telemetry features are for? So they can pick which useful features to get rid of because some computer rookies whined that it is "feature creep" rather than just ignoring it?

Now I have to fear losing useful (or at least occasionally convenient) features each time I upgrade, such as Firefox ditching RSS, FTP, and the ability to view individual cookies. The third can be done with an extension, but compatibility for it might be broken at some point, so we have to wait for someone to come up with a replacement.
Also, the performance analysis tool in the developer tools has been moved to an online service ("Firefox profiler"). I hope I don't need to explain the problems with that.

But perhaps the biggest plunge in functionality in web browser history was Opera version 15. That was when they ditched their native "Presto" browsing engine for Chromium/Blink, and in the process removed many features including the integrated session manager and page element counter.

The same applies to products such as smartphones. In the early 2010s, it was a given that a new smartphone should cover all the capabilities of its predecessors in its series, so users can upgrade without worrying a second that anything will be missing. But that blissful image was completely destroyed with the Galaxy S6. (There have been some minor feature removals before that, such as the radio and the three-level video recording bitrate adjustment on the S4, but that's nothing compared to what was removed with the S6.).

Whenever I update software to a new version or upgrade my smartphone, I would like it to become MORE capable, not LESS (and to hell with that "less is more" nonsense).

I want to replace Windows with Linux on a very old Notebook. It‘s for my father who uses it only for web browsing and Skype.
Can you recommend me a distro?
I think Ubuntu should be fine but I don‘t know.

How did mid-2000s computer users get along with just 1 GB of RAM or less?

As of today, anything less than 8 GB of RAM seems impractical. A handful of tabs in a web browser and file manager can quickly fill that up.

Shortly after booting, 2 GB of RAM are already eaten up on today's operating systems.

When I occasionally used an older laptop computer with 6 GB of RAM (because it has more ports and better repairability than today's laptops; before upgrading the memory), most of the time over 5 GB were in use, and that did not even include disk caching.

It appears that today's web browsers are far more memory-intensive than 2000s web browsers, even if we do similar things people did in the 2000s: browsing text-based pages with some photos here and there, watching videos, messaging and mailing, forum posting, and perhaps gaming. Tabbed browsing already was a thing in the 2000s. Microsoft added tabs to their pre-installed browser in 2006, back when an average personal computer had 1 GB of RAM, and an average laptop 512 MB!

Perhaps a difference is that people today watch in 720p or 1080p whereas in the 2000s, people typically watched at 240p, 360p, or 480p, but that still does not explain this massive difference. (Also, I pick a low resolution anyway when mostly listening to a video in background.)

One could create a swap file to extend system memory, though that is not healthy for an SSD in the long term. On computers, RAM is king.

It's 2022 and web browsers are still unable to unfollow redirects.

If I open some URL in a new tab and it redirects me to /503.html or similar due to some server errors (which is bad design to begin with), there is no way to see which URL was redirected from. The "back" (←) navigation button is greyed out, so there is nowhere to go back to.

One might open a new tab to look at it later without realizing it redirected to an error page. Then one opens it, sees /503.html, and has forgotten which article one was going to read.

Only on the mobile edition of Chrome/Chromium, switching between desktop and mobile view unfollows the redirect. But on Firefox mobile, Chrome/Chromium-based desktop, and Firefox desktop, there is no way to know which URL redirected me there.

ENOSPC = random things go wrong.

There are many synonyms for ENOSPC, like "disk full", "space storage full", "space storage exhausted", "no more space left on device", and those other repulsive errors. For the sake of simplicity, I am going to refer to it as ENOSPC.

If you are in this condition on the operating system partition, get out of it quickly or random things will go wrong. Text editors which write directly to a text file rather than creating a temporary file and then replacing the text file could end up blanking the text file, softwares' configuration files might fail saving which causes a reset, and web browsers might spontaneously reset cookies and lose history.

For example, Firefox has created a gap in the web browsing history, as shown here. The history that is now memory-holed initially appeared to have been recorded successfully. Apparently, a failed write to the places.sqlite database when closing the browser created this gap.