Personally I almost wish that the majority of sites out there didn't pretend like they need to be highly dynamic, interactive and inevitably wasteful experiences.

It had nothing to do with a quest for better performance. It had everything to do with ad impressions.

Why not both? Even if the former was the "public justification", AMP pages still performed better than bloatware-ridden websites that otherwise took 2-10 MB to load, not even mentioning the amounts of JS and the impact of it on performance, especially on mobile devices (as well as batter usage on those).

The only reason it performed better is because Google would preload over 1MB of Javascript needed to run AMP on its search page.

A cold start for AMP was barely better than most of the top sites that used it.

It was cheating, pure and simple.

Edit: IIRC it was also preloading the entirety of the search carousel, too. And you could get into the carousel only if you had an AMP page.

I wonder what he actual metrics are for how often that was used, what % of people chose one of the AMP results, because those were at the top of the list. That preloaded data might be common for most of AMP pages, which is much better than the mess of each site having different React/Angular/Vue bundle versions or even jQuery versions back in the day.

As a thought experiment, I wonder how much we could save on bandwidth, if all of the "popular" frameworks/libraries split their base code from each individual application's code (we already have code bundling, after all) and browsers included all of those packages of base code, preloaded.

Maybe even follow SEMVER as close as possible, so the browser can always ship the latest minor/patch release for a given major release, to cut down on space needed in the browser.

Something along the lines of:

  <script src="/browser/react@18"></script>
  <script src="/js/my-app-react-bundle.js"></script>

  <script src="/browser/react@17"></script>
  <script src="/js/my-older-react-bundle.js"></script>

After all, browser install sizes are already horribly bloated, a few dozen MB will hardly matter at this point, whereas each site needing 1-5 MB of JS is absurd, especially because those are re-downloaded for each of them, despite the fact that most sites out there use one of like 3-5 popular solutions.

My wife has a MacBook Air that doesn’t even have a fan.

This is incredible!

> enough maturity to implement essentially an entire operating system / virtual machine AS the browser

Yes, an operating system-- but one without user-facing persistence! Only per-application, networked, silo'd persistence, where the user sees a rendered form of data but not the data itself.

IMHO these two facts, that

a) Web browsers are BETTER than Linux, Windows, etc as an OS in a very important way, package management

and

b) They're missing one of the primary features of an OS, persistence

overshadow any other facts about them. What a strange tool they are.

You can copy and/or edit said data from that view as well!

Albeit the convention is clearly to not presume your browser app user will be interacting with their data at _all_ through the devtools, which I find regrettable but unavoidable with the current state of "computer literacy" and the state of "devtools-as-an-interface" (obviously the ergonomics aren't great for the average user today).

Eg take web forums (not this one since there's weird lisp stuff down there and I don't know how it works, but the average web forum).

On the app (server) side they have access to everything, all of your posts in nice beautiful structured SQL.

On the user side you have access to none of that, just HTML soup and maybe some cached stuff in the "Storage" tab, or maybe not.

> Albeit the convention is clearly to not presume your browser app user will be interacting with their data at _all_ through the devtools, which I find regrettable but unavoidable with the current state of "computer literacy" and the state of "devtools-as-an-interface" (obviously the ergonomics aren't great for the average user today).

I really like your use of "convention" and "presume" here, because I think that's the essential lens to view these things through. It's absolutely possible for an app to provide all of a user's data in a nice structured form in IndexedDB, that will just be rare because it's not the convention.

Maybe even Smalltalk in the 80s if Kay and company had foreseen the rise of the global internet back in the 70s.

Ironically, for all the fragmented wild ecosystem of webdev today, with a million different libraries & toolchains & frameworks, the web has maintained & iterated on a very consistent & coherent underpinning that is fundamentally cross-computer, that is globally connected via the url. Applications were always a lesser beast, damned by lower horizons, and if they dared to try to do more, were on their own with no other applications to interoperate across & on their own with their protocols. The web grew many UI development options atop consistent DOM and protocols, but the application had consistent UI development options across scattered connectivity protocols, if any (and often none).

Looking at the internet as an application delivery platform ignores that the web grew because it was both an application and content delivery system, interwoven, together, and infinitely remixable & extensible.

I do very little on the web where I actually want there to be code running on my document.

Just some random examples, but how do you do your tax, pay your bills, buy/sell stuff online, make appointments etc?

Some things yes client side code makes sense, like an appointment finder, and that’s fine, but such things make up a tiny amount of my internet activity.

Or just a proper GUI framework not based on HTML.

Emphatically no. The absolute vast majority of those "polished dropdowns" are horrible to use, and break all possible platform conventions (for example, not accessible or usable with a keyboard)

> countless other controls you interact with every day require javascript.

Very few, if any, "polished controls" used on the absolute vast majority of web sites require javascript.

"Dropdowns are toggleable, contextual overlays for displaying lists of links and more. They’re made interactive with the included Bootstrap dropdown JavaScript plugin"

- don't follow platform conventions (don't trigger the actual system dropdowns with actual expected behavior)

- get cutoff by browser chrome when page is zoomed in (because you can't control that behavior from JS)

- default implementation's touch targets are too small

And that's for a framework which has had over a decade to make this work.

This is not to throw undue shade: they've done a very good job. But that's about as far as you can get.

I got one can do without the "polish I am used to". I'm generally fine with HTML form controls.

My problem with JavaScript frameworks is they are huge beasts that build their components out of non-semantic block elements. A button or text field is just a giant mass of divs and spans with events attached everywhere with one-off CSS. The browser is stuck doing tons of work in its single-threaded JavaScript engine to build and manage these components.

It's a lot of wasted memory and clock cycles to recreate a text field the browser already provides. It makes for a worse user experience, wastes my battery, and eats up my bandwidth. To me it's not polish but waste.

Regarding the massive nestings of divs. Well this is computer generated HTML. It is ugly as hell, but browsers are well geared up to deal with it, it doesn't create any serious performance issues unless taken to stupid levels. The other side of the coin, with this rather ugly generated HTML, is you get a human benefit, a time saving efficiency. You can spin up a web page with React/Bootstrap in a fraction of the time it took you in the 1990s.

If you think about that maybe you come also to some conclusions regarding the questions you just asked.

Back in the day, we didn't even have modems or compilers, let alone internet - so we would go to Ye Olde Computer Store and copy the disks of Fred Fish. That was how I got my first experience of Hack, which was great, and Emacs, which has always been a WTF for me.

I wonder if for some reason computer hardware had stopped getting faster and more complex at the stage of, say, a 25 MHz 486, how much different the world would be, or whether it would just force software to be consistently purged of cruft.

Back in the day there were several P-Code aware platforms.