What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles.
This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.
What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers.
Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.
>Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue.
If a single company killing a sigle product could kill RSS, then it wasn't that alive in the first place.
The fact is, after 10 years of RSS being available in blogs, news sites and elsewhere, Reader still had an insignificant number of users in the web scale of things. A few tens of millions (all estimates put it in the low tens, like 20 to 40 millions).
>And did you just say "few tens of millions" of users is insignificant?
Yes.
>How many users are we here on Hacker News again?
I'd say well under a million (or around that at most). What does that have to do with anything? Did anybody say that HN has a significant amount of users web-wise?
Slashdot and then Digg, which were both something like 100 times HN in size fell off the side and nobody much cared.
I would say that Hacker News' few hundred thousand users are extremely significant both for YC and web-wise. I really hope we'll not end up with a Facebook-only Internet because that's the only service big enough to keep running.
It's, ironically, a case of the "embrace and extinguish" philosophy that Microsoft was reviled for.
I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it.
RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.
RSS -> Twitter
Usenet -> many proprietary platforms
IRC -> Slack
XMPP never took off
Many open, interoperable services died off or never took off, but companies built similar services and are enjoying success.
"Some of these parallels are obvious, and even more or less literal: Gmail is IMAP and SMTP, and Google Talk is (or was) XMPP, all on port 80 in the same browser window. Others are more metaphorical. Twitter is IRC on port 80, although one primarily listens to users instead of channels — but listening to channels is still possible, if one uses a client that can follow hashtags, and the syntax is even the same. Dropbox is FTP on port 80. Reddit is Usenet on port 80."
https://medium.com/@maradydd/on-port-80-d8d6d3443d9a
Urbit looks cool, but it will not magically make things distributed. What causes centralization are business factors. It's just a lot easier to build a great product if you have a revenue source, which is most easily acquired if you can lock people into paying for your proprietary thing.
Also, it's a lot easier to make good protocol decisions if you don't have to get them published into a standard and deal with the beauracracy etc. If you look at the level of polish in slack vs one of the many previous open source irc clients, the difference is clear. It helps to have money.
I was as annoyed as the next person when Google killed Reader but, to be honest, RSS was killed off for typical users way before that when browser manufacturers dropped/hid support for it. I still use RSS every day, as do many of our customers.
Not just browsers, but Facebook and Twitter both killed their RSS feed at some point.
That's much worse than Google killing Reader, because reader is just a reader, you can still switch to a different one. If the source doesn't provide an RSS feed, there's not much you can do.
RSS never was an open standard like you would expect from a real standards organisation, e.g. IETF or W3C.
Because of dominance posturing and fights between the multiple parties involved in the development of RSS, it is a train wreck of ad-hoccery and incompatibilities, and serves as a prime example of how not to do things. https://web.archive.org/web/2004/http://diveintomark.org/arc...
This is kind of orthogonal to RSS. AMP and RSS work great together. Your feed reader can detect that the feed item URL has an AMP alternate and chose to display that instead.
How? Multiple <link>-Element as in Atom with special rel-values? Or a link in the already linked HTML page?
There's nothing on that in the Github Wiki and neither on the project page. The superset of HTML is specced, yes, but information on the containing ecosystem is spare.
<amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work.
You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.
Scanning your comments, I haven't learned about what tracking is accomplished by serving the https://cdn·ampproject·org/v0·js file itself, can you please comment on what data (if any) is collected by being 'the' place all AMP sites phone home to on page load by default?
Two other points, and I hope these are received as constructive criticism.
1- You only score 'B' on SSL labs for the domain serving the AMP JS file.[0] Maybe this is intentional so as to include support for Android devices that no longer get updates but it's not great security for the rest of us.
2- Your page explaining the project executes Google Analytics tracking code and has no privacy policy and does not disclose the fact that you are tracking visits. This is a breach of your very own Google Analytics T&C's[1] which read in part "...You must post a Privacy Policy and that Privacy Policy must provide notice of Your use of cookies that are used to collect data. You must disclose the use of Google Analytics, and how it collects and processes data...".
Neither of these inspire confidence and I hope you can get at least one of them corrected soon.
Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.
In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate:
If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content.
In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs).
I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed.
What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :)
By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.
While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).
I follow your thinking. The ad networks could begin transforming their content in subtle ways which the eye cannot detect but which could throw off simple pattern matching thereby forcing the blocker client to employ an algorithmic approach.
The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices.
The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility.
As you rightly point out there may be both vectors for either side which neither of us has thought of though.
What are they selling, exactly? Why does this need to be a framework, with js and all that?
I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just html and common sense.
You might get it :)
There isn't that much to it. AMP is as much about technology as finally getttig that tech adopted. Since AMP is built on web tech there is nothing in it that you cannot chose to do yourself
The problem we are solving is that many sites don't.
So what's with the approach then? Why would websites choose to use AMP (whatever "using AMP" means), when they don't apply common sense in the first place?
One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.
With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU.
That allows for instant feeling loading of pages (because they are already loaded when the user clicks) which in turn makes users happy :) While all web pages can be fast, AMP allows proving that they are which makes such a feature possible.
A referrer like Twitter or Pinterest or Google could e.g. indicate: Clicks on these links will be super fast (because they are AMP docs). If users click them more (because they like fast) there is a strong incentive for everyone to be fast – and then we all win.
I don't think XKCD927 applies, because we only combine existing standards and restrict ourselves voluntarily to a subset of those. Its still just HTML, CSS, JS. Browsers do not need to change.
't
You're not "combining" standards though. As other comments pointed out, this is not a subset of html. It's a separate spec, based on a subset of html, which is different enough that it's not quite compatible. For example, what's with the amp-prefixed tags? Why amp-img instead of img with data-amp- attributes?
You also didn't address my first point: If you're building this for people who don't make the effort right now, why would they suddenly make a seemingly bigger effort to support something they haven't even heard of before today?
We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like <img data-src="foo"> is possible but a less explicit hack.
To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.
Good demo. The benefits are indeed attractive, but you still have not sold me on why this is a better approach than ... well, everything that's been suggested in this thread. This stuff is possible without what you're proposing, as you yourself admit. What I see amp giving is a framework in which it is impossible to "mess up", which can be beneficial but I agree with the general sentiment here: New tech has a cost to it. Learning it has a cost. Implementing it in browsers has a massive cost (because I'm sure this will eventually find its way in Chrome, which means Firefox will follow suit, which means a larger potential for technical debt and a higher bar to developing a web browser from scratch).
Like someone else said: If Google wants performance, Google can start aggressively penalizing article-type websites which make unnecessary requests etc. I know you guys already penalize slow sites, so what's wrong with that approach? Especially since such an approach has a much higher chance of actually working.
I totally agree that the "penalizing" approach is important.
But I like to present both a solution "this is how you make it fast" as well as the penalty.
If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.
Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.
The custom-elements document you linked to is a W3C Working Draft, not a Recommendation. It might someday be part of the Web platform (w.r.t. standardization), but for now it's just under discussion.
It has an implementation in Chrome and Firefox and both Microsoft Edge and the WebKit teams have indicated that they will support it. On top of that there are 2 super excellent polyfills.
In the world of the web platform it doesn't get much more standard than that.
> One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.
Which begs the questions: Who prerenders and on what criteria?
Assume page A which has a link to AMP-forked page B.
Does that link need rel=prerender for every browser? Does one need to query the AMP-ness of every page one links to? Does one need to be Googles page cache to link to AMP-pages and get in the benefit of prerendering?
Or is the prerendering implemented in the AMP runtime? Does it only work if page A and page B are both AMP-enhanced?
They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.
If they're putting ads in custom tags that makes it extremely easy to block them.
I think it's nothing so sinister as a "fork of the web", but a badly thought out approach of going back to faster loading web1.0 by recognizing that quite a lot of JS adds no value to the end user.
My point is that this project is not about providing value to the user. Google could have done that more easily.
It may not be so sinister because it's a badly thought out approach indeed. Although they got quite a few big partners already, this undertake requires rewriting the whole Web which is too much to ask even if you are Google.
Then don't pull random statements out of your ass about it? What are accepted as standards spend most of their life as W3C working drafts. The W3C doesn't finalize a draft until the feature is obsolete, more or less.
WebWorkers, for example, is still a working draft. So is Web Storage.
The only thing that has ever mattered is browser support, not W3C specs.
To expand on this, custom elements are supported in Chrome and Firefox (behind a flag in FF at the moment), and there has been public support from both Webkit and Edge, as well as high quality, high performance polyfills.
Yes, custom elements are not fully finalized, but all of the browser vendors are invested in the spec and finalizing it. There is a lot of activity on it right now.
What annoys me are people who speak out of ignorance without really knowing what they're talking about, but like to give the impression to others they do.
AMP is an open source project any publisher can use and tailor to their needs. If you don't want to factor Google into the solution then you don't have to.
But, keep on praising Facebook because you at least got their agenda right.
>What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles.
This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls.
if you run a whois on ampproject.org, the results clearly indicate it's owned by google.
Registrant ID:mmr-87489
Registrant Name:DNS Admin
Registrant Organization:Google Inc.
Registrant Street: 1600 Amphitheatre Parkway
Registrant City:Mountain View
Registrant State/Province:CA
Registrant Postal Code:94043
Registrant Country:US
Registrant Phone:+1.6502530000
Registrant Phone Ext:
Registrant Fax: +1.6502530001
Registrant Fax Ext:
Registrant Email:dns-admin@google.com
The tech lead of the project is Malte Ubl who by their twitter page : @cramforce indicates that "I make www internet web pages for Google. "
Unless it's a 20% off time project (or a side project of some kind), I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee.
>I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee.
For the same way that tons of open/collaborative projects with multiple partners are not "X projects" even if they started and/or are hosted by X.
Heck, even something like Webkit is not an "Apple project"...
Downvotes? Are you kidding me? What part of "open source initiative" containing multiple industry leaders (like Twitter, and lots of others) don't people understand?
Is Angular involving multiple major-name partners such as Tweeter, and has been such from the start -- to the point of downplaying Google's involvement in the project site?
For something like SPDY/HTTP2 etc, I can say it's Google first and foremost (even if it got adoption later on).
Google's slogan shifted from "don't be evil" to "do the right thing", the former is arguable to say the least based on its records, but moving to the latter is worse, as google can just do the "right" thing for its own benefit, which could be selfish, and blatantly evil sometimes.
> Google's slogan shifted from "don't be evil" to "do the right thing"
False. Google's slogan did not change.
Also the full slogan for Alphabet is "do the right thing – follow the law, act honorably, and treat each other with respect." This cannot be selfish & blatantly evil.
This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.