The unreasonable effectiveness of simple HTML

As someone who did a lot of desktop application development prior to the web just totally gutting native app development, this is my take:

The problem is that people want to make dynamic applications that have a rich UX and deep system integration while being highly portable.

Unfortunately, it turns out that "portable" is basically a Great Filter for applications. If you can't run it, you can't use it and the rich UX and deep system integrations don't matter.

So developers cast about looking for alternatives to Qt and GTK and friends. Flash and Java (and Silverlight....) all had browser plugins and offered vaguely convenient APIs for building applications with rich UXs. Unfortunately those plugins had inherent technical issues and died (or were killed, as it were).

So what platform remained that had super easy distribution and portability? A XML document format that supported directives for styling xml and some rudimentary scripting language that could dynamically change that xml and styling.

So that's what ended up getting built upon. And now, since abstraction can do anything, we finally have things resembling what we had 30 years ago in desktop applications but built on top of a standardized runtime with a JIT and a sandbox and a nascent assembly language. So that's finally what people use.

I really had nothing but disdain for web applications built with javascript/jquery soup for the longest time. They worked, sure, and printed money and all that, but I was bitter that such poor technology was what won, instead of some evolution of the existing desktop app paradigm.

Now with React et al it's finally getting bearable again. But I still find myself wishing I could just say forget all this web junk, I could write this as a Swing or JavaFX program in 10% of the time.

(It's just unfortunate that nobody would be able to use it because nobody downloads programs off random websites anymore except Putty and nobody has an (independently-installed) Java runtime anymore. Which brings us right back to the initial problem).

> It was never intended to be overweighted virtal machine and not a good one by the way.

Citation needed. It's been two and a half decades since people started using the web as more than just a delivery mechanism for text and images.

The trouble is that you can’t support HTTP without completely undermining HTTPS.

If you support HTTP at all, you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL, and you’re causing trouble with search engines, and it’s a regular maintenance burden because no one treads this path so you’ll have to figure out the cut-off points yourself as certificates change, and on top of that it’ll always be subject to a downgrade attack, so now you can’t ever depend on HTTPS.

Remember also that various new features are gated on using a secure context (which roughly means “HTTPS”), like HTTP/2 and HTTP/3. And as for entering passwords or the likes, you’d be opening quite a can of worms if you allow that over cleartext HTTP.

So… yeah, it sounds nice in theory, but I think that it’s just not practical or advisable to retain plain HTTP support. Even supporting TLS can’t support ancient devices without harming things materially for everything else.

If the site looks correct visually, the designer has actually completed their job. You’ll find that very few businesses care how a page is implemented and happily pay for shit html if it looks right.

That might be the way many companies work, doesn’t mean it’s correct. Design is more than how things look, in fact how things look is secondary.