So about that AMP-script thing

Two days ago, Google breathlessly announced this amazing new revolution for websites:

Or in other words:

Let’s make a limited subset of the web that guarantees performance! No JavaScript, to keep it lean!

(Two weeks later)

So about that JavaScript thing…

It’s pretty clear to me that it’s less about providing a benefit to the web and more about providing a benefit to google. Like instead of having their own special markup that gets a mobile search fast lane they could have instead published guidelines for mobile-first design and semantic markup with html5 structure tags. You know. The things Safari and Firefox use for “reader mode,” and which are an actual standard.

And then combine this with Google’s tendency to create new projects and then discontinue them as soon as they’re no longer fashionable/cool/fun, and their tendency to try to lock everyone into their platform and sometimes even succeed… (By the way, did you know there are browsers other than Chrome out there?) But in the meantime, Google is prioritizing search results to AMP-enabled websites. You know, Google, that still makes the vast majority of their money off of ad revenue for search traffic. Yeah, no conflict of interest here…

I’ve long described Google as an incredibly curious and intelligent five-year-old with no concept of consequences or history. Right now they are seeming also like they’ve found an original historically-significant manuscript, torn a page out of it, scribbled all over it in crayon, and called it their own original story. And people are rushing to put it on their refrigerators. What the hell.

While discussing this on IndieWeb chat the other day, Peter Molnar asked: “no institutional memory, but they could at least use wikipedia, no?”

Wikipedia wasn’t invented there.

I haven’t worked at Google, but I have worked at Amazon (twice!) and their attitudes are, as far as I can tell, very similar. Google and Amazon both have severe problems with NIH.

At Amazon the common thought process was: that wasn’t built at Amazon so it doesn’t scale. How do we know? Because if it were built by someone who knows how to scale they would be at Amazon.

And this is why Amazon has their own in-house implementations of Stack Overflow, Twitter, GitHub, and Reddit. Which are all inferior to the originals.

And after each one gets built and internally launched, it gets used for two weeks and then forgotten about, only for someone else to decide to make another one a few months later. Or then they decide to invent entirely new paradigms for things internally, like the “simple issue manager” (SIM) which was anything but simple, used a huge pile of overwrought front end and frameworks, had terrible UX unless it was run full-screen on a desktop monitor (which was of course the programmer-designer’s preference for using it), and happened to manage issues “universally” in exactly the way the programmer-designer thought all issues should be managed for everyone. Which meant the only project that it suited was SIM itself.

But of course it became such an important thing to replace JIRA/TRAC/walls of sticky notes that it became the One True Way of doing things, use it to manage your projects Or Else. (Sticky notes worked way better. SIM did have the nice feature of making issues and their prioritization part of sprint planning, but the sprint planning process itself was incredibly onerous and annoying.)

Anyway, back to AMP. The idea behind it was sorta well-intentioned; websites have gotten enormously overly-complicated and Google decided to develop and publish this new specification that makes things lighter and faster, especially for mobile. And then to throw a bone to folks who do React and Angular and so on they “invented” the concept of “AMP server-side rendering,” which just means… having a directive to tell your webserver to render out HTML instead of doing it client-side? Isn’t that called, um, building a web app?

Why have we gotten to the point that web apps are doing client-side HTML rendering in the first place? Why not just have the server emit fully-formed HTML with an API hook or whatever and then the client can download that HTML blob and set container.innerHTML as a progressive enhancement to classic page-based flows? Like if you REALLY need a single-page app (which does have a few legitimate use cases! yours probably isn’t one, but let’s assume it is for the sake of argument) there’s no reason you need to have separate rendering paths for the client side vs. the server side – the server side can just call into the same dang APIs that generate the rendered HTML for the client! And now you don’t need JavaScript for people to view your site or for search engines to crawl it or whatever, and the amount of effort it takes over making a traditional server-based site is minimal (and the amount of effort it takes vs. making a properly-SEOed, accessible, client-side-rendered “app” is WAY THE HELL LOWER).

(Incidentally, Kevin Marks calls that JAH, which I’m sad never caught on, because it makes way more sense than AJAX. Which nobody even calls AJAX anymore because in this day and age people no longer even think about the mechanisms that they’re using when they’re building a web app any more than people think about their car’s spark plugs while they drive. … Do cars even use spark plugs anymore?)

Every now and then I see a CSS tutorial online where someone describes a really simple CSS attribute, and then provides a JavaScript function to add it to an element, with a whole bunch of overhead and assumptions necessary to add it to the element. When they could just… add it… to the CSS?

What the heck, people.

Reinventing the web the long way around, in a way that gives Google even more control of it. No thanks.

Comments

Before commenting, please read the comment policy.

Avatars provided via Libravatar