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.
> 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.
HTML may have intended to deliver semantic markup, but web application developers want pixel-perfect layout. That ship has long sailed.
No disagreement about excessive scripting, ad serving and other bloat. But those are orthogonal to my points. Are there some things in AMP that would make HTML faster or improve the UX? If so, let's evolve HTML based on what we learnt.
Sidelining well established standards isn't the solution to the web's problems. This is one of the instances where being open source it's not enough and coming from Google it is actually worrying. A very obvious Trojan horse in my opinion.
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.
> You cannot share news links with anybody using the browser share option.
This. I want the user to know they are on my site and be able to share the URL when they want to. Google News, admittedly the only implementation of AMP I've seen so far, fails in making visible that basic unit of the Internet -- the URL.
I really am surprised that a mobile technology would compromise so much on how flicking the page to scroll works. I'm curious as to what kind of user testing this went through before it was cleared for production usage.
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].)
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.
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.
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.
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.
The AMP team 100% agrees with you. But the project goal is to be fast in current generation browsers. As soon as the current generation can perform well with more relaxed rules, the rules in AMP can be changed accordingly.
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.
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.
"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)
> 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.
When a new feature is being developed, whether it can be GPU-accelerated on day 1 should be a factor in the decision. If it can't, or it's tricky, perhaps we should think twice before even developing the feature. Rather than it being an afterthought, as it seems today.
Of course, all this is in the context of features that make sense to GPU-accelerate, like CSS filters.
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.
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.
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.
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.
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.
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.
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.
given that AMP has no explicit browser implementation right now, but is just some guidelines and JS, implemented on top of the "mistaken" standards: web developers already can write pages conforming to the goals AMP tries to enforce, but too many of them didn't.
Stricter browser engines would punish devs more, to avoid punishing devs with AMP?
I'm not a big fan of AMP, but I'm not sure if intentionally worsening browsers for unliked but valid markup would be better. Users will leave a browser doing so.
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.
Yikes looks like someone didn't setup SSL properly on the project's website (http redirects to https) 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.
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.
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.
> 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.
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.
[+] [-] niftich|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] kartickv|9 years ago|reply
No disagreement about excessive scripting, ad serving and other bloat. But those are orthogonal to my points. Are there some things in AMP that would make HTML faster or improve the UX? If so, let's evolve HTML based on what we learnt.
[+] [-] rpgmaker|9 years ago|reply
[+] [-] dingo_bat|9 years ago|reply
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.
[+] [-] putlake|9 years ago|reply
This. I want the user to know they are on my site and be able to share the URL when they want to. Google News, admittedly the only implementation of AMP I've seen so far, fails in making visible that basic unit of the Internet -- the URL.
[+] [-] dingdongding|9 years ago|reply
[+] [-] Anasufovic|9 years ago|reply
[+] [-] randomguy7788|9 years ago|reply
[+] [-] combatentropy|9 years ago|reply
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].)
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|9 years ago|reply
[+] [-] pcwalton|9 years ago|reply
(Disclaimer: I work on one of these libraries.)
[+] [-] tux1968|9 years ago|reply
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
[2] https://www.ampproject.org
[+] [-] cramforce|9 years ago|reply
[+] [-] hermitdev|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
It's like banning all screws because you've got a kickass shiny hammer.
[+] [-] kartickv|9 years ago|reply
[+] [-] kevingadd|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] kartickv|9 years ago|reply
Of course, all this is in the context of features that make sense to GPU-accelerate, like CSS filters.
[+] [-] tiles|9 years ago|reply
[+] [-] kartickv|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
[+] [-] ty___ler|9 years ago|reply
[+] [-] kevingadd|9 years ago|reply
[+] [-] ebbv|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] detaro|9 years ago|reply
Stricter browser engines would punish devs more, to avoid punishing devs with AMP?
I'm not a big fan of AMP, but I'm not sure if intentionally worsening browsers for unliked but valid markup would be better. Users will leave a browser doing so.
[+] [-] matt4077|9 years ago|reply
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|9 years ago|reply
[+] [-] humbledrone|9 years ago|reply
[+] [-] donatj|9 years ago|reply
[+] [-] puddintane|9 years ago|reply
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...
[+] [-] paulbakaus|9 years ago|reply
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?
[+] [-] dragonwriter|9 years ago|reply
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|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
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|9 years ago|reply
I can't tell what's worse: this post, or the fact that people are responding to it.
[+] [-] wfunction|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] ajdlinux|9 years ago|reply
[+] [-] nwah1|9 years ago|reply