
AMP Is What HTML Should Have Been - kartickv
https://kartick-log.blogspot.com/2016/08/amp-is-what-html-should-have-been.html
======
niftich
HTML isn't a renderer-output-description-language like PDF or PostScript. It
was always intended to deliver content alongside semantic markup and
intermixed with only basic formatting. Later, nearly all non-semantic tags got
deprecated when CSS came of age; together they deliver structure and
presentation. The image tag argument is a red herring: in HTML, that the exact
resulting render is up to the browser's layout engine based on the CSS and the
viewport.

The blog post isn't wrong, but it's also not right. Today's web isn't slow
because of HTML's features, shortcomings, or other properties; it's slow
because of excessive reliance on client-side scripting, including client-side
DOM manipulation, ad serving, tracking, and A/B testing. Turning off
Javascript vastly improves pageloads, and did -- once upon a time nearly 10
years ago -- improve UX, but these days more sites break without Javascript
than those that don't.

AMP can impose constraints because it's a corporate effort to re-frame content
in a way that provides centralized ad serving, tracking, and the like. It
gives the content publishers the same tools (ads, tracking) they have to
provide themselves with on the open web, while simultaneously benefiting those
like Google who will put their own viewport and context around that content.
It's not that much different from when an individual wants to publish on
Medium or Tumblr, so the platform provides the author with a box to put text
in, a dashboard, view tracking, and stuff the author wants, while they get to
host interesting content with which to attract an audience for ads. It's a
win-win, symbiotic relationship, while on the self-hosted web, every publisher
is on their own.

This isn't about HTML vs AMP at all. It's about business models, which are
given in AMP, but left as an exercise for the publisher on the open web.

~~~
Benjamin_Dobell
> Today's web isn't slow because of HTML's features, shortcomings, or other
> properties; it's slow because of excessive reliance on client-side scripting
> [...] Turning off Javascript vastly improves pageloads

Sure, disabling JavaScript will improve pageloads. However, are you suggesting
clicking a link and waiting for an entirely new page to load is good UX?

Good UX is instantaneous feedback, client-side code is a requirement... Unless
you want some kind of enormous super-spec that is supposed to encompass
anything anyone could ever wish to express in pure markup. In which case, good
luck getting that supported and rendering quickly.

The whole point of JavaScript (or any client side code, including mobile apps)
is that it _vastly_ improves UX.

~~~
Alphasite_
If it loads quickly, why not? My connection is a sub 3ms ping to the nearby
datacenters, what exactly is the bottleneck?

It's not to say there isn't a place for SPAs but I would argue many of these
would be better suited to being full fledged desktop apps instead (better
performance and snative integration).

~~~
Benjamin_Dobell
Okay, for you there's no bottleneck, just woeful UI/UX. Seriously, seeing just
one stateful element at a time, then pressing "Next". Wow, just wow.

I fully expect that when I type the first few digits of my credit card number
that the site knows precisely which card provider I'm supplying and updates
the UI (highlight the card type) accordingly and immediately update the
security code field to request my 3-digit MasterCard CCV vs. a 4-digit AMEX
CID.

To be clear, I'm not suggesting code _needs_ to run on a client. One day when
we all have fast enough connections (with minimal latency), including on
mobile network, then perhaps all the code can run server-side and we just be
streamed the output (video) - which again, updates in real-time!

However, living in the real world as it stands today, client-side scripting is
a fantastic solution to a real-world problem i.e. latency and bandwidth
constraints, and real-time responsive UIs.

------
dingo_bat
Even though technology may be superior, the implementation by Google news is
terrible. You cannot scroll properly because the page hijacks it and replaces
it with a janky scroll mechanism. You cannot share news links with anybody
using the browser share option. Also, the whole thing refuses to work without
js enabled.

So give me plain old HTML any day. It renders fast, scrolling is predictable
and smooth, and the URL is right there if you want to share.

~~~
dingdongding
I think scrolling on AMP pages is really fast on iOS. Not sure which device
youre feeling it slow on

~~~
dingo_bat
Android (SGS7 edge) here. I wouldn't call it slow. It's just different from
the normal scrolling. And unpredictable. And frame skips sometimes.

~~~
nness
Might be specific to the Galaxy — Samsung still forces its own browser on
phones instead of the stock Chrome other manufacturers rely on.

~~~
dingo_bat
That's wrong. Samsung includes both. Google forces OEMs to include it's apps
if they want to use the Play store and Play APIs.

But yes, I use the Samsung browser because of the performance and feature
benefits, and my complaints may not be applicable to chrome.

------
combatentropy
The best thing about this article is that it is short, a rare feat in today's
world. So I don't want to scrutinize it too hard on its mere two examples:

It says, like Google's Accelerated Mobile Pages (AMP) project, HTML should (1)
require each img tag have the height and width specified, and (2) allow only
the CSS filters that can be GPU-accelerated.

These are nice and all, but the problem is this. Why stop there? Why not
forbid illegible fonts, text columns that are too wide or too narrow, green
text on a red background, and assortment of other "poor UX"? Why not enforce
that no page exceed the byte length of a Russian novel? (Now that's a law I
can get behind
[[http://idlewords.com/talks/website_obesity.htm](http://idlewords.com/talks/website_obesity.htm)].)

HTML could be better, but like all open-source projects, I'm amazed how good
it is, and even more so how much better it is than any alternative offered for
money.

~~~
themodelplumber
Can we just create a community standard of plain-jane HTML to separate it from
all this "publisher" junk that AMP stands for, and then build a gigantic web
ring and a search engine and all that? Like tilde club but with standards
enforcement. I'd put a weather forecast site like that on my home screen in an
instant.

~~~
Animats
Here's a possible set of restrictions:

1\. HTML5, without syntax errors. UTF-8 only.

2\. IMG and EMBED tags must have size info.

3\. All CSS, Javascript, and font files must have subresource integrity
hashes. The browser can cache anything with subresource integrity, even across
site boundaries, since the hash guarantees the content value. This will speed
up asset loading. No more loading "jquery.js" over and over.

4\. All off-site content (ads, trackers, etc.) must go in iframes. All iframes
must have a height and width, so rendering can proceed without waiting for
them. This eliminates delays caused by slow ad servers. Iframe content is
requested at a lower priority than main page content.

5\. Rendering doesn't start until the entire main page is loaded, or a <page>
tag is encountered for really long pages. Almost everybody has enough
bandwidth now that we don't really need to frantically re-render as pages come
in.

~~~
flukus
Number 3 is already possible and widely used by minification frameworks. They
generate a file with a hash in the filename that is cached forever. It cuts
network time but browser still re-parse it every time.

------
pcwalton
AMP doesn't "allow only CSS filters that can be GPU-accelerated". It allows
only CSS properties that _Blink_ (and other current engines) can GPU-
accelerate via layers. There is no need for this restriction in general, and I
think a better approach for the long run is to adopt rasterization strategies
that don't have such unnecessary performance cliffs.

(Disclaimer: I work on one of these libraries.)

~~~
tux1968
Would be interested in taking a look at your project if you'd offer a link.
:-)

The Amp guys make the claim in one of their videos[1] that the GPU can do
nothing if a page-layout event is triggered. Amp is geared to minimizing the
number of times this has to happen, by demanding that elements are size-
bounded for example; the same reason for the CSS GPU-acceleration limits.

Hopefully new render engines will address this, but having them out in the
wild is a ways off even if they were ready today. Amp seems like a pretty
reasonable stop gap. Although I find their demo site[2] not a perfect
experience with all of my normal Firefox plugins. Another comment in that
video mentioned above is that Amp sites should be faster without an ad
blocker.

[1] [https://youtu.be/hVRkG1CQScA](https://youtu.be/hVRkG1CQScA)

[2] [https://www.ampproject.org](https://www.ampproject.org)

~~~
pcwalton
> The Amp guys make the claim in one of their videos[1] that the GPU can do
> nothing if a page-layout event is triggered.

That's a Blink restriction, not an inherent one. It's also an onerous
restriction. Having these footguns is a bad way to treat Web developers.

> Would be interested in taking a look at your project if you'd offer a link.
> :-)

WebRender [1], part of Servo.

[1]: [https://github.com/servo/webrender](https://github.com/servo/webrender)

------
hermitdev
I agree with the annoyances. Try reading any major US news site on your phone.
You see a headline you want to read and tap on it. Sometimes the page is
unresponsive. When it becomes responsive, it has loaded some new links to
other articles, and what you tapped on is no longer on screen. Now, you're
navigating to sothing you either didnt want to read or maybe already have.

This is a problem with all major news sites. CNN, NBC, FOX all do this to
varying degrees. The main page is static, subsections are injected via async
requests. It's annoying on a desktop (because you cant necessarily go back to
where you were) and infuriating on a phone. I can't imagine what it's like for
people on a limited data plan.

I also find it annoying when I see multiple links I want to read, but it's not
obvious if I click on one, read it and go back that the other is now replaced.

------
justicezyx
The accusation is valid, but is nonetheless missing the point.

The evolution of technology always starts with ramification of features, and
mature with a much smaller set of them, which have been proven to be really
useful and efficient.

At the beginning, no one really know that html should just be like AMP. So we
tried, and it largely worked. Use this to prove that html should start like
AMP is like to claim the cave man 10000 years ago should use internet to
communicate, which is plain irrational.

~~~
Splines
In addition it means we've arrived at this solution backwards.

It's like banning all screws because you've got a kickass shiny hammer.

~~~
runeks
How so? How could we know what does and doesn't work without trying it out
first? Languages designed by commission usually don't get very far.

------
kevingadd
"Allows only features that are fast/can be gpu accelerated" is a nice idea in
theory, but in practice it's wrong. The web started out as a platform where no
features were accelerated, and browser vendors started incrementally adding
faster software implementations of features, and then eventually GPU-
accelerated implementations. More obscure/uncommonly used features tend not to
get an optimized implementation, because carefully tuning every single web
platform feature is _extremely_ expensive to do. So if AMP forbids things that
aren't fast Right Now, you're freezing the state of the platform forever until
vendors get around to improving features nobody uses... and then you have to
wait until every vendor ships the optimized implementation before anyone can
use it in AMP.

The fact is that there are many barriers between web apps and native-level
performance. AMP's focus on delivering good performance on mobile is to be
applauded, but you don't do it by trapping software in the past.

(Context: Previous member of Firefox and Chrome teams)

~~~
pcwalton
> So if AMP forbids things that aren't fast Right Now, you're freezing the
> state of the platform forever until vendors get around to improving features
> nobody uses... and then you have to wait until every vendor ships the
> optimized implementation before anyone can use it in AMP.

Agreed that AMP is the wrong approach. But I think it's not that difficult in
terms of programmer-months to fix the rasterization problems. You just need
the right design as opposed to '90s style imperative APIs.

------
tiles
I'll upvote this for the discussion, but I still think it's unreal that we had
to create an entire proprietary AMP/Instant Article standard rather than
guidelines for making working mobile sites. Even an HTML validator (hello
1999!). It just seems like every ancient WAP solution that's gone out of
fashion.

~~~
kartickv
You reminded me of Google Gears (disclosure: I worked on it), which was
supposed to have played a part in getting the W3C committee to work on HTML5
seriously.

Likewise, HTTP2 languished for a long time, but took off quickly once SPDY was
implemented in Chrome + Safari + Firefox.

As I was told, the best way to spur a standards body into action is to
threaten to make them irrelevant.

------
hawkice
I just flipped my blog over to AMP, which required essentially no change at
all, except adding their cdn'd (but not client-cached) JS and some weirdo
attributes here and there.

I run a pretty tight technical ship, so that non-cached JS ends up being more
than half the page weight. I don't _really_ care about the additional ~40kb,
but I guess I'm not seeing any advantages yet.

AMP != An HTML-subset. If it were, that'd be fine, and I'd basically agree
with the article. But AMP seems to also require me using some strange JS from
an ad company, which I'm extremely skeptical of.

------
rajangdavis
Pardon my ignorance, but when you specify the height and width of an image,
wouldn't this hamper the ability to utilize media queries/responsive design? I
understand what AMP is trying to solve, but it seems to be backwards in terms
of how CSS can be utilized for responsive design.

~~~
kevingadd
It theoretically does, yes. The width/height could probably be specified
through media queries, but I don't know how well that would perform in modern
layout engines - I expect they've implemented this in Chrome for AMP but I
haven't tested it.

~~~
rajangdavis
I am just trying to wrap my head around the use case for AMP.

On one hand, you have a faster loading site/page which is good for users and
helps with SEO ranking, but as a developer, you lose some flexibility in terms
of specifying your layout for multiple cases.

I guess if the majority of your traffic is mobile-based in areas with
typically slower internet connections, then it makes more sense to utilize
something like AMP. But if that is not the case, it seems like you have to do
twice the work for not much gain...

~~~
detaro
The use case is that it will improve your search rankings, and giving you an
argument to force your organisation and your ad-partners to make your site
faster. It's effectively Google making up a tool they can force-feed big
publishers to get them to make websites that perform less horribly, which
makes the top results of Google search on mobile more useful and leaves more
traffic to look at more pages and more Google ads.

There is no reason why a normal website can't be as fast or faster than an AMP
one, but AMP gives the framework to get organisations that otherwise wouldn't
care enough to do so.

~~~
AstralStorm
This is the exact strategy Microsoft used for lock in way back when. You could
use ASP and other MS technologies and they even worked well. Until you wanted
to exit their walled garden - then they were a real pain to integrate with
anything usual.

~~~
kartickv
Isn't AMP available as an open-source library? I don't see the lock-in.

Besides, Google has announced that search rankings will be affected by speed,
not by what library you use. So, if your site is already optimal (doesn't
benefit from AMP) or you want to use some competing project that also does a
great job, you won't be penalised.

I don't see the walled garden argument here.

------
ebbv
This seems to me like punishing users (in this case web developers) for the
mistakes of standards organizations of the past (W3C).

HTML is what it is and it's not going anywhere. AMP is not a solution to
anything, because the whole world isn't going to adopt it.

A real solution is to write your HTML rendering engine to eliminate behaviors
you don't like. If you don't want repainting/reflowing of the page when the
img dimensions aren't known then don't start rendering until you know them.

But browser vendors aren't going to do that because users DO prefer
reflow/repaint over waiting for the page to load. So this is a silly argument.

~~~
pjmlp
If they handn't fooled around with XHTML set of standards, we could probably
already have something like XAML on the browser, with its GPU backend.

Alas, what we have is a Frankenstein stack, which when one does the magic
incantations of HTML and CSS, maybe just maybe if the browser and
corresponding version are the right ones, those transformations will land on
the GPU.

~~~
flukus
> If they handn't fooled around with XHTML set of standards, we could probably
> already have something like XAML on the browser, with its GPU backend.

HTML + knockout is a lot like xaml, but a lot simpler.

------
matt4077
I'm quite happy with how the web platform has proven to be powerful and
flexible enough time and again to stay relevant. Javascript is probably doing
some nasty (but well-animated) things on Flash's grave, meanwhile HTML is
annoying the newest W3CWG drafts with that they-wanted-to-replace-me-with-word
story.

The web needs interactivity and without a powerful open platform it's going to
be 2 or 3 incompatible, non-free silos. No links & nothing too abnormal please
– not one piece if information outside of some AOL/MS/Apple/Google-controlled
curated marketplace.

------
pcunite
Please don't make me (as a designer) know what the exact width of an image is,
ahead of time.

~~~
humbledrone
Please don't make me (as a user) deal with pages that re-flow every three
seconds as images load, pushing the paragraph I was reading off-screen.

~~~
kevingadd
The size of an image is in the header right at the front, so arguably it's not
that hard to avoid the reflow. Just prefetch the headers. This is already done
for video files and audio files that have the relevant info.

It's still ideal to put the sizes inline if you can, though.

~~~
kevingadd
For the people who are downvoting, some more details on how this would work
from a person who actually works on web platforms and standards:

Along with crypto and improved compression, HTTP2 offers multiplexing. HTTP
also has historically offered range requests, where you can request a small
subrange of a file.

This means that a browser could collect image URLs when doing its initial
parse of the page (pretty easy, since you want a small, simple page for AMP
anyway) and then issue a set of requests for the headers of all the images -
for PNG, at least, you know the header will be of known, relatively small
size. The header requests can all be multiplexed by HTTP2, which means that
you will be able to get all the headers before you start getting the full
bodies of the images. You won't have to download the headers or images twice
since you can download the rest of the image bodies with another range
request. Range requests could also be cached under this scenario.

This optimization can be implemented (in theory) by every browser engine and
doesn't require changes to developers' content or web servers. And it would be
an improvement that is web-wide instead of just focused on AMP.

~~~
querulous
you can do even better with http2. on a request to get a page the server can
just optimistically send the image headers to the client up front with the
page text then backfill the image bodies in whatever order the client wants

~~~
kevingadd
Oh yeah, I forgot about server-driven preloading. There's some great stuff in
HTTP2, thanks for pointing it out!

------
donatj
Of all the things that cause pages to reshuffle on the modern web un-sized
images are the least of my worries.

------
puddintane
Yikes looks like someone didn't setup SSL properly on the project's website
(http redirects to https)
[https://www.ampproject.org/](https://www.ampproject.org/) it'd be nice to see
some of the examples.

 _edit_ Google cache isn't loading everything - at least to my knowledge.

 _edit 2_ Yay web-archive to the rescue!

[http://web.archive.org/web/20160811220337/https://www.amppro...](http://web.archive.org/web/20160811220337/https://www.ampproject.org/)

~~~
paulbakaus
AMP team member here. Not sure I understand the issue.

It's by design that our site is only available via HTTPS. Is there a good
reason for why you can't consume the HTTPS version?

~~~
puddintane
I am not entirely sure, as a web developer I've never seen a certificate pass
all SSL checkers yet chrome and firefox on my computer (up-to-date) won't load
them. I pondered a MITM attack but it's literally the only site this happens
on - not exactly sure what is causing the https to not load on my end.

 _edit_ All I get is "ERR_SSL_PROTOCOL_ERROR" \- I'm pretty sure I tested this
link out at work but I will again on Monday to verify it happens there
(currently I'm tethered as well as vpn'd to PIA and I don't think my provider
T-Mobile is doing anything to block this one ssl)

------
dragonwriter
No, HTML is what HTML should have been.

AMP is an optimization with narrow application focus than HTML has that
introduces a number of things (including coupling, limitations on technologies
other than HTML, etc.) that are undesirable in general for the broad role HTML
has, but tolerable trade-offs for the focus of AMP.

~~~
kartickv
To take an example, in what context is it better to have img tags that don't
specify their width and height?

------
pjmlp
The AMP presentations at Google IO were a bit strange.

They were throwing jabs at native applications while at the other tracks
everyone was talking about _native_ Android applications, how to run _native_
Android applications on ChromeOS and how to stream _native_ Android
applications.

------
justrossthings
This an intro, conclusion and 3 paragraphs that don't say much more than "HTML
is shit because people don't specify image size and this irritates me".

I can't tell what's worse: this post, or the fact that people are responding
to it.

------
wfunction
> For example, images should have their width and height set so that the page
> doesn't re-layout when they're loaded.

I hate this idea. What if I just want the photo to be there at its natural
size? Why should I keep updating my CSS when I change the photo?

~~~
fluxsauce
> Why should I keep updating my CSS when I change the photo?

They're talking about the HTML image attributes so layout placeholders can be
rendered, not CSS. The original height and width should be specified and
styling can optionally be applied in CSS.

~~~
wfunction
Replace CSS with HTML?

The question applies to either.

------
nwah1
I like Firefox's Reader Mode for cluttered pages, and this approach could be
widely adopted and improved upon. However, anything that catches on too much
is going to get peppered with ads or paywalls, one way or another.

------
carsongross
and through the years

and perfectionist tears

it echoes, echoes:

 _worse is better_

~~~
leoc
By that logic .doc is the greatest format ever, or in the top 5 at least.

------
ravivyas
It is easy to criticize in retrospect. If HTML was not what it is, we may
never have reached where we are and said ok we need to step back a little and
figure things out for the multitude of consumption mechanism.

~~~
kartickv
Not intended as finger-pointing, just forward-looking. HTML was great
historically. What do we do now? How could we improve things?

