So AMP is designed to be so so fast, and yet has such a big JavaScript library attached that we need to process the content twice (once in a server-side render, and then again when the client side JavaScript loads)?
Anyone fancy going through the AMP library and inspecting it for cruft?
Maybe it's because I primarily use Brave, Samsung Internet, and sometimes Firefox on Android, but amp pages never load quickly for me. It's usually quicker to click the link and load the source page even bogged down with all the ads, trackers, and slow servers!!
I just don't get it. Maybe it works great in the Google News app, but nowhere else I've seen and I refuse to use Chrome on Android. With the lack of ad blocking the web is borderline unusable on a phone.
When I last looked I to it, it turned out that blocking certain scripts from Google blocked page rendering and only showed the page in full when the browser eventually gave up trying to load the blocked resources.
I mean, there are valid concerns over the ethics or intentions behind AMP, but let’s not kid ourselves—it’s definitely damn fast to load. Say what you will about the implications or whatever, but they nailed it in a technical performance sense.
Strongly disagree. It’s way faster than a badly-implemented strawman (which is most media sites, admittedly), but markedly slower than implementing basically the same thing but without AMP.
AMP’s main benefit has been making it harder to do expensive things. (Not impossible, by a long shot; merely harder.) And they’re deliberately planning to scuttle that benefit by allowing you to run your own scripts (see worker-dom). At that point, I believe that the only benefit of AMP will be how Google search treats it, rather than anything about actual performance.
The fact that Google is also moving forward with AMP4Email, which has nothing to do with fast-loading mobile websites, reveals that the true purpose of AMP is simply to create a Google-proprietary replacement for HTML.
Another explanation for the name is that it uses a subset of the components of normal AMP, which are all prefixed with "amp-". Microsoft, Yahoo!, and Mail.ru are also moving forward with AMP4Email.
As we've discussed previously, the other mail providers are being forced to comply with Google's proprietary format since Google holds a near monopoly on email and they want to remain compatible. It isn't a defense for Google's behavior.
And Google has communicated in multiple other ways that it thinks websites should be developed exclusively in AMP, a replacement of the open standard everyone agreed upon in HTML5.
"In this special episode of Amplify, discover how to go "AMP First" and use AMP as your main development framework to significantly increase your productivity as developer. You'll also learn why "paired AMP" was never really meant to be an end state for AMP."
At the beginning of your video, the presenter says, "It's not a replacement for HTML." This is obvious because HTML5 supports far more than what is exposed in AMP. He later says they want it to be a natural choice for "web development for everything content related." Again, this is not a "replacement for HTML" any more than RSS is a replacement for XML.
I take it you've admitted the rest of your mistakes as you have left them unanswered?
The only reason AMP is faster than most webpages is because Google preloads and prerenders the content when you are still on the Google results page. It's not a fair contest. We've seen our HTML pages be consistently faster than our AMP pages when all else is even.
But the whole point of AMP is to make prefetching possible in a safe and privacy-preserving way. The AMP caches are where the big wins come from, and what clearly guided the rest of the design.
If option one makes prefetching possible and option two doesn't, why would a comparison with prefetching be unfair?
(Signed exchanges could in theory change this and allow safe cached serving and prefetching of arbitrary HTML pages, but the crowd that hates AMP seems to despise signed exchanges even more. Such is life.)
Incidentally, there was just a large scale study made on the performance characteristics of AMP in the real world.
TL;DR is that the AMP pages from the origin were loading on average in 3.1 seconds compared to 7.7 seconds for the matching HTML. (Not all sites are as diligent as you about keeping their HTML light). And then pre-rendering sped that 3.1 seconds to 1.2 seconds. Though the bandwidth used for the prefetching was more than I would have expected.
I think that's the same tone of most comments on these threads. I don't think the HN crowd believes Google will do anything positive for internet users as a whole, unless it's also positive for Google's bank accounts. Hard to be a knight in shining armor when you've proven yourself a scoundrel, ya ken?
Hackernews is just as fast to load. There's no amazing innovation with AMP, it's only a fork of HTML to limit what people put on the page, incentivized by higher search result placement.
Does AMP even make sense for a website like HN having user authentication?
I sheepishly haven't even seen an AMP page yet because I rarely surf on mobile. But it seems like you'd click into an HN AMP page from google results which of course is cached unauthenticated. And then you'd have to click into the website proper if you want to up/downvote or write a comment.
AMP on iOS is profoundly buggy. Rotation, reader mode, and URL bar hiding are routinely broken in all modes. AMP in landscape is particularly unusable. Google should be embarrassed to have shipped this.
That's Apple standing its ground. End result is my default search is Bing, without these AMP links. I also noted that on VPN Google shows Ads in 6 out of 10 first page results.
I'm somewhat happy that's the case. And I've been an IE6 hater myself for keeping the web back. But let's face it, Firefox isn't in a position to save the web from Google ducking it sideways to their liking, so safari is pretty much the only thing with some significance, able to push back. AMP being broken there is good news to me. Hope they don't bother improving this so some users will just be driven away to other search engines.
It’s not. They are just not rushing to implement half-baked standards that are being hastily designed and forced down everyone’s throat by a handful of Google engineers.
"Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up)."
Service Workers is drafted by 4 people. 3 of them are from Google. [2]
A lot of standardisation work on web standards is completely taken over by Google. A lot of discussions on JS and HTML are being handled by the same group of ten or so people who are in every open issue and every open proposal on GitHub.
A common thread is "oh yes, we should involve the wider web community that's why we reached out to Angular and Polymer for comments", which are, unsurprisingly, also Google projects. A recent proposal where I saw this happen is a proposal by Apple, Template Instantiation [3] Which is now almost entirely taken over by Google. See for example this issue: [4]. Three engineers from Google decided on the future of the project and chose only Angular and Polymer as the frameworks to talk to.
Indeed. Facebook does this. It deanonymizes Facebook news feed visitors to every third party whose links appear on their news feed. You consider this a better approach? In addition to losing in privacy, it loses in speed because it doesn't prerender the page, and it doesn't know enough to load just the resources needed to render above the fold.
I don't consider either necessary. Clicking a link and then loading the page works just fine for the web.
Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site (and now SSR) is a worse approach than placing loading speed into search results ranking and letting sites optimize the site for everyone with a browser.
> Clicking a link and then loading the page works just fine for the web.
No, it doesn't. If it did, there would be no need for Facebook Instant Articles, Apple News, or their successor, AMP.
> Creating a custom HTML fork that puts more pressure on limited publisher dev teams to end up with another copy o the site
They're already doing this with Facebook Instant Articles and Apple News. Imagine if they had to do separate integrations with Bing, Google, Yahoo! Japan, Baidu, and any future link aggregators. AMP lets them publish one page and support all of them.
No, none of this is needed. Make speed a factor in search results and sites get faster. The single HTML version will get faster for everyone on every device, not just mobile sites from certain platforms.
Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers. IA and AN have both failed in providing anywhere near the benefits and revenue they promised. AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results.
It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
> No, none of this is needed. Make speed a factor in search results and sites get faster.
You can't get faster than prerendered, which is what Apple News and Facebook Instant Articles offer, which AMP is the open alternative to.
> AMP only survives because it's compatible with existing ads served by Google's ad network and given higher placement in their search results.
If that's the case, why does Bing use it?
> It's rather amazing how Google is specifically offering the solution to a problem caused by their own adtech software.
What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages), you continue to straw man what it solves and what technologies it competes with.
> Facebook IA and Apple News are also attempts to control ads and data, just like AMP. They're all bad for publishers.
Yet only AMP gets the rabid hate. Why is that? AMP is essentially RSS items with support for above the fold prerendering, interactivity, and monetization. You probably love RSS, even though it is even worse for publishers. Why?
It doesn't matter if it's prerendered, as long as it's fast enough, and fast HTML sites are fast enough. If AMP was so good then this entire SSR wouldn't even be necessary in the first place, let alone all the complaints about user experience and data.
You also seem to argue that because Facebook Instant Article and Apple News exist, AMP must also compete. I'm saying none of them are needed and creating yet another standard to push onto publishers because others have done it is poor justification. It's more work for no gain. Google already has vast control over UX by using search results, the very same search results it currently uses to pressure sites to implement AMP.
If Google wants to, it can force speed standards that change the majority of websites overnight. It can implement rules and restrictions in its adserver that change the majority of ads overnight. It can optimize Google analytics that change the majority of tracking overnight. It can do all of this if the intentions were pure, but it doesn't, because the only intentions are more control over publishers and data.
Facebook doesn't pressure IA and normal links work just fine. Apple News is new inventory and doesn't take away from Safari or the web. And RSS is completely irrelevant and nothing more than a feed of updates where pubs can share as much or as little as they want.
> It doesn't matter if it's prerendered, as long as it's fast enough, and fast HTML sites are fast enough.
If that were true, Bing et al would not spend resources maintaining AMP caches. It's clearly not true.
> If AMP was so good then this entire SSR wouldn't even be necessary
This just shows that you don't know what AMP does. It allows prerendering from the link aggregator, and it does this well enough that every competent search engine implements it. The problem this solves is that people share AMP links directly, which can't be prerendered because they aren't loaded until someone puts the link in the location bar. In this case, it is slower than plain HTML, but this isn't the case AMP is meant to solve. By using SSR, they can make it faster than most plain HTML and just slightly slower than hand-optimized HTML with above the fold optimizations.
> You also seem to argue that because Facebook Instant Article and Apple News exist, AMP must also compete. I'm saying none of them are needed and creating yet another standard to push onto publishers because others have done it is poor justification.
The publishers use it, and as we demonstrated above with Bing's A/B testing, the users want it. What more justification do you need?
> If Google wants to, it can force speed standards that change the majority of websites overnight. It can implement rules and restrictions in its adserver that change the majority of ads overnight. It can optimize Google analytics that change the majority of tracking overnight.
Who says they don't? None of those solve the problem that AMP solves, which is instant loading of pages .
> Facebook doesn't pressure IA and normal links work just fine. Apple News is new inventory and doesn't take away from Safari or the web.
It's the same with the search engines and AMP.
> And RSS is completely irrelevant and nothing more than a feed of updates where pubs can share as much or as little as they want.
So what you're saying is that RSS is exactly like AMP, where pubs can share as much or as little as they want.
Your arguments are circular and repetitive. Publishers do not want AMP. Users dont care about AMP, just fast sites. "Instant" is a marketing gimmick and makes no material difference when sites are fast enough. AMP is not necessary to make sites fast enough.
Google can influence site speed through SERP rankings, speed that is lacking primarily because of its other products, but instead it's forcing AMP pages. This is the fundamental problem that you are not acknowledging. There is no way around AMP if you don't want to lose ranking on an existing search results page.
FB doesn't treat IA ranking differently from links. RSS doesn't treat content differently. Apple News doesn't even support the web and can already accept RSS feeds. They also get plenty of critique that you're ignoring. Have you ever worked with a publisher?
Then why does every major search engine support it? They're trying to please their users, so they just need fast, not instant
> "Instant" is a marketing gimmick and makes no material difference when sites are fast enough.
Instant means actually instant, not just fast. Of course it makes a difference, or the search engines, Apple, and Facebook would not put in the resources to enable it.
Your current problem is that you're confusing your hatred for Google's search results ranking with AMP. If you don't like how Google ranks its results, just use a different search engine. Bing ranks differently and also uses AMP.
The comments on this page alone are evidence, let alone the 100s of publishers my company has business relationships with and the feedback I get.
The only speed that search engines are responsible for is the results page. AMP has nothing to do with their user experience. And as stated several times, Bing joined for the same reason Google forces it, for more control over data by never leaving their domains.
And no, the ranking is not my problem. I don't know where you came up with that. The argument is that publishers lose ranking unless they use AMP and the same effective speed can be provided in much more neutral and friendly ways that doesn't require an extra copy of the site.
Anyways, it's clear that you're religiously defending AMP at this point with no acknowledgement of any of the arguments by myself or others on this page so I'll end it here.
> The comments on this page alone are evidence.... AMP has nothing to do with their user experience.
The comments on this page are from people who don't understand what AMP does and have a blind hatred for anything produced by Google, as I have repeatedly demonstrated. If people actually didn't like AMP, Bing wouldn't spend the money to support it.
> And as stated several times, Bing joined for the same reason Google forces it, for more control over data by never leaving their domains.
Where has that been stated several times? This is the first time you have used "Bing" in any comment in this thread. If it were really the case that people prefer slower loading articles, it would be a competitive advantage for a search engine not to support AMP.
> And no, the ranking is not my problem. I don't know where you came up with that.
Let me refresh your memory:
"There is no way around AMP if you don't want to lose ranking on an existing search results page. FB doesn't treat IA ranking differently from links. RSS doesn't treat content differently."
Notice how you even confuse a publishing technology (RSS) with ranking.
> The argument is that publishers lose ranking unless they use AMP
Because users prefer fast loading results! If users preferred slower loading results, a competing search engine could rank non-AMP results higher than AMP results or not show AMP results at all to win users from the search engine that shows instant loading AMP results.
> with no acknowledgement of any of the arguments by myself or others
I've quoted your arguments and addressed each one. As I've shown above, you've pretended arguments were made that weren't, and now you're blaming me for not acknowledging these phantom arguments.
Saying things like "blind hatred for anything produced by Google" isn't accurate or productive.
Bing cares about control like Google, that's why they also implemented it. I stated this, you quoted this, and yet you're changing the argument to be about slow sites for some reason. They are not related. Users can get fast sites as a secondary benefit of more control by search engines through AMP.
Nobody is confused about RSS, but you brought it up first and said AMP was the same. However using RSS does not give you higher placement. Are you disagreeing with that?
As for the rest, I'll try one last time: Users want fast sites, and nobody said they didn't, but Google can influence this speed through rankings without AMP. Rank sites by speed and you get the same outcome with sites that are fast enough. Instant is not necessary and doesn't nearly outweigh the extra cost of implementation and maintenance. This has been the argument this whole time, one that you haven't provided any rebuttal against.
> Saying things like "blind hatred for anything produced by Google" isn't accurate or productive.
I don't see anybody complaining about Bing's AMP usage, do you? Most of the commenters don't understand what AMP does, but they still hate it. You yourself didn't understand how AMP worked when we started this discussion, wondering why origin SSR was necessary when it is obvious to anyone who understands what AMP does, yet despite not understanding the problem AMP solves, you still hate it.
Google does some shady things, but contributing to AMP is not one of them. In fact, AMP is far less shady than its competing technologies that get far less attention on HN.
> However using RSS does not give you higher placement. Are you disagreeing with that?
What does that have to do with anything? Publishers implement RSS, which allows instant loading but gives even less control to publishers than AMP does, yet you are not complaining about RSS. As far as placement, implementing RSS gives them placement in news aggregators including Apple News. Forget about poor ranking — you can't get placement at all in these systems with just a plain HTML page and instead have to hand full control over to the aggregators.
> Google can influence this speed through rankings without AMP.
Who said they don't?
> Instant is not necessary
Says who? If instant weren't necessary, explain Apple News. They could have implemented it as links to existing web pages, but they instead make publishers give them a feed to ingest.
> This has been the argument this whole time, one that you haven't provided any rebuttal against.
I've repeatedly rebutted it by saying instant is necessary. You've been sticking your fingers in your ears and pretending it isn't. I strongly prefer to click on AMP links, and I can guarantee that most other users do as well, or why would the search engines bother labeling them with an icon?
If it were just about control, there is no reason to tell the user ahead of time that a particular link is to an AMP page. If it were just about control, what is the point of SSR on the origin and signed exchanges to make shared links not go to Google or Bing?
HN is a highly technical audience and the commenters here perfectly understand what AMP does. There's no irrational hatred here, and that's a silly thing to say in the face of multiple reasoned explanations of what people are finding wrong with it.
RSS is completely voluntary and used for inventory that is not serviced by websites. It has nothing to do with instant loading and can carry as little data as the pub wants. Apple News is Apple also wanting control, the same reason as FB-IA and AMP, and was also designed for offline use and device-local recommendations. Pubs willingly trade-off the loss of control for the extra reach but both FB-IA and AN support RSS feeds now because of pushback to use an existing syndication format.
You haven't actually provided as reason for why instant loading is necessary other than saying it exists and therefore it must be. That's not an argument, it's a tautology. If Google highly ranked sites loading under 1-second on the top half then you would get fast sites like HN. No AMP and yet here we are on instant loading website. Stackoverflow and dev.to are other examples, with no AMP required. Perhaps if publishers had both the incentive and didn't have to waste resources on AMP for SERP ranking, we could all be enjoying faster sites now.
These comments are highly upvoted, so the readers of the comments also don't understand AMP. If they haven't bothered to understand it but hate it anyway, that is clearly irrational, is it not?
> RSS is completely voluntary
Just like AMP.
> and used for inventory that is not serviced by websites.
Nonsense. RSS items almost always link back to plain web pages with the same content but with more publisher control.
> You haven't actually provided as reason for why instant loading is necessary other than saying it exists and therefore it must be.
I showed you an example of users preferring it. These results are clearly labeled, and users like me click them on purpose. If it was purely about control, they wouldn't be labeled.
As far as it being about control, you still haven't explained why Google ceded control to all other link aggregators just like RSS instead of following Apple's and Facebook's path.
And finally, if it were just about control, why wouldn't Google have set up a system for direct integration like Apple and FB instead of defining a publishing format that all link aggregators, including current and future competitors, could use and then make a steering committee for the format with only minority representation?
Because websites are standalone properties with much greater fidelity, design and content than a single article. Google is linking to results, not showing articles like FB or Apple News.
This is also why AMP is not used for much other than news sites, and yet another reason why it's limited, wasteful and unnecessary.
> Google is linking to results, not showing articles like FB or Apple News.
Results in general shouldn't be written in AMP. The AMP documentation is very clear that it is meant for content pages and by attacking it for a problem it isn't meant to solve, you are engaging in strawmanning.
> This is also why AMP is not used for much other than news sites, and yet another reason why it's limited, wasteful and unnecessary.
It is far less wasteful than Apple News, FBIA, and RSS, which are limited to the same problem but solve it in a much worse way for the publisher. Once again, why aren't you complaining about them?
Continuing in the Captain Obvious role, how do you propose to replace FBIA, Apple News, RSS, and AMP with something that both users and publishers love? AMP is just as fast as the first three, and it provides more control to the publishers than the first three, yet you are not ranting about the first three. Why?
It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1]
The only reason AMP exists is because Google needed its own way to control content. That is it.
> If that's the case, why does Bing use it?
Because you're forced to compete against the behemoth on the behemoth's terms.
> What's rather amazing is that after having repeatedly heard the problem that AMP solves (instant loading pages)
AMP's problems are well documented. You chose to ignore all of them and go for "instant loading pages".
> Yet only AMP gets the rabid hate. Why is that?
Because it reaches a wider audience and Google has the gall to call it "open" and "good for the web". It's neither.
> It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1]
> The only reason AMP exists is because Google needed its own way to control content.
That's nonsensical. Why then does Bing use it?
> Because you're forced to compete against the behemoth on the behemoth's terms.
Why are they forced to use it? I would really like to see your position stated coherently.
> AMP's problems are well documented.
How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?
> It is not like RSS in any way, shape, or form.
This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.
Advisory Committee has no say in anything that AMP does. Everything is designed and specced inside Google (or Google-dominated work groups) and then vetted by the Technical Steering Committee. Advisory Committee's findings and advise is non-binding: https://github.com/ampproject/meta/pull/37 And all the WG's are assigned projects that have already been accepted into AMP (such as AMP 4 Email).
And yes, my example is important because it was a huge change that no one asked for, but now it's in AMP. As are all the other changes that already hurt the web.
> Why are they forced to use it? I would really like to see your position stated coherently.
Google has near monopoly on search. In order to compete with it you need to provide nearly all of the same features.
> How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?
There are no bugs in iOS that preclude instant pages. And the bugs that AMP introduced are, well, the bugs that AMP introduced. AMP broke the behaviour on purpose and refused to implement any suggested fixes.
> This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does.
I perfectly understand what AMP and RSS are. You don't understand what either one is. RSS was never about caching or link aggregators.
RSS is a web feed. That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.
Also, RSS always leads to the original URL.
AMP is not a feed. It's a collection of specially constructed HTML pages (which are not valid HTML5, by the way). They are not "instant". They are underperformant by Google's own standards (try running Google's own Lighthouse tools report against one from cold cache).
They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.
They are not discoverable. A meta tag linking to an AMP version will only link one URL, that's it. There is no feed.
An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.
Implementing an AMP cache is a significant endeavour, and only a handful exists (as far as I know, there are no opensource AMP caches).
> Advisory Committee has no say in anything that AMP does.
Why did you focus on one irrelevant aspect of that document? The document also includes the Technical Steering Committee, a majority of whose members do not work for Google. That doesn't fit your narrative.
> In order to compete with it you need to provide nearly all of the same features.
In other words, users want it.
> There are no bugs in iOS that preclude instant pages.
iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.
> RSS is a web feed.... There is no feed.
I was talking about items in the RSS feed as you quoted yourself in an earlier comment and then somehow forgot, but lets ignore this strawmanning and continue.
> That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.
So exactly the same as AMP.
> They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.
Aside from effort, this is exactly the same as RSS. The additional effort is from doing things that RSS cannot do like monetization, interactivity, analytics, A/B testing, and above the fold optimizations. Cloudflare handles that effort fine.
> An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.
Exactly the same as RSS. A link to an RSS reader is a link to the reader's URL, not the original URL.
> Why did you focus on one irrelevant aspect of that document?
Because that irrelevant part was the only one that would give AMP any semblance of being open.
> iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.
I advise you learn something for yourself. Several fixes were provided to AMP but they were rejected without discussion.
> Exactly the same as RSS.
Let's see how AMP is "exactly the same as RSS":
- RSS is a feed, AMP is not
- RSS feed is discoverable via a meta tag, AMP pages are not (you have to search in a search engine, or have a cache of pages)
- RSS is a simple format that can be trivially parsed to retrieve data such as: author, publish date, url to original page, description, and content. AMP requires a near-full HTML parser with AMP-specific extensions: AMP is not valid HTML 5, AMP validator will allow some non-valid HTML5. Additionally, AMP relies on custom elements.
- Any and all RSS readers and aggregators link to the original website in a trivial and discoverable way. There's no url hijacking. AMP all but requires AMP Caches to be fast, and AMP Cache design all but requires to display content not at the original link, but at the Cache's URL. For several years the "open" AMP would deny this was a problem and pretended "it was an implementation detail that AMP is not concerned with" and "we will work with browsers on how to present the canonical URL". And even now the largest AMP cache regularly employs dark patterns to prevent users from visiting the canonical URL.
> Because that irrelevant part was the only one that would give AMP any semblance of being open.
No, that is the only part of the document when taken out of context that gives AMP any semblance of not being open. The TSC is what makes AMP open, and you ignored it and continue to ignore it after I explicitly called it out.
> Several fixes were provided to AMP but they were rejected without discussion.
Where?
> RSS is a feed, AMP is not
You need to work on your reading comprehension. That quote that you took out of context says that AMP is exactly like RSS on that particular point. I have repeatedly explicitly pointed out that AMP is like RSS items, not like RSS feeds.
Let me know when you're ready to continue the discussion in earnest instead of going to great distances to strawman every point.
Google's entire reason for not using the browser preload function is is violates the users privacy - the site gets to know the users cookies and IP even if they never end up visiting.
It's a legit excuse, but not enough if a privacy leak in my opinion to slow down everyone's browsing substantially.
> With this attribute being set, the validator treats SSR’d AMP as valid AMP. SSR’d AMP optimizations break the rules of the AMP spec, hence making the document invalid, which is why it’s necessary to indicate this case with this new flag. With the flag and the optimizations both being in place, the document is considered valid and you’re good to go.
Wait, does this mean that websites could serve plain HTML but set this flag and this avoid being penalized by Google? Win!
Ask yourself... Is that really the minimum amount of script needed to render a basic fast text and images only webpage? Notice the handcoded crypto functions? Notice the copious numbers of debugging functions and log messages and error messages? Notice the large numbers of copyright notices and complete license texts.
This stuff, if Google's dream comes to fruition, will be downloaded billions of times per day. For every byte of cruft in this file, an ethernet cable needs to be installed/upgraded somewhere.
We shouldn't let Google get away with such massive inefficiency in the name of efficiency.
The sad truth is that Google's goal isn't efficiency, it is keeping people on Google's property. The best way to do this is to make people package their websites into little bundles that are safe for Google to preload. They're even working on a way to capture sites that don't want to invest in AMP (signed exchanges).
I count 185 "try" statements with only 162 "catch".
I don't know much about javascript, but could someone explain what happens with the 20 that don't get caught? Do they bubble up and get caught by another "catch"? Or is this indicative of lots of "holes" in the code path?
Ok, fair enough. But then does that lead to a "fatal error" of some sort? I'm curious because I find AMP page quite buggy. ie. not loading at all. Or loading, then reloading a blank page. And thought maybe these were the "dead end" code paths.
It’s caught by a higher-level catch if there is one.
Try blocks without a catch are a sign of any of these: poor coding, remnants from refactoring, features started and abandoned, possibly result of some build steps combining and optimising code.
Try without a catch is fairly common and IMO quite fine when it's not the current method's job to deal with an error but it is its job to clean up state or some resources.
There might be a parent class/component/whatever that deals with errors and shows them to the user. The image component is responsible for showing the loading spinner and it shouldn't be left spinning if there's an error.
An aside: one interesting thing about this is that Google's lawyers believe that copyright notices are required in minified JavaScript, and other people don't.
Who's right? Is everyone else breaking copyright agreements?
Many licenses require that the license be distributed with the code. uglifyjs, babel minifier, and google closure compiler all try to preserve license information.
Check the advertised site, https://amp.dev/, and look at the headers for v0.js.
I'm seeing an "expires" tag of "now", a cache-control header of 'private' and 'max-age' of 50 minutes. You'll also see the 105KB Javascript used to support animated gifs, 46KB amp-bind which allows documents to "add interactivity", and several others.
I don't fully understand the implications here, and I know I'm oversimplifying given the SSR half, but I find it amusing that part of this feature is "remove the code we told you to add".
> It doesn’t make sense to hand-write SSR’d AMP. Instead, use a tool to automatically transform your AMP files into a SSR’d version, like a compiler would.
"Compiling HTML" would've been Star Trekian techo-babble a few years ago. And yet, here we are, where a straight-faced Google developer advocate is telling us to do just that. Should we laugh or should we cry?
It's just sad that enormous amount of developer resources are being wasted into a tech which should have been used for the standard web instead. It's not just the developer hours put into the AMP project itself. Thanks to all the SEO blogs, every site out there has to wasted resources into an AMP implementation.
The days of maintaining two versions of a website - a "mobile version" (in AMP) and the normal - are back again. Takes me back to the WAP days (not saying it's that bad). Then there are those that are going AMP-only - getting locked into AMP and all the excessive-yet-limited JS baggage (try building a full-fledged site and you will have a lot of AMP JS). JS compilation and execution isn't cheap on phones either. I sure as hell can make faster-rendering sites without that AMP bloat that can compete despite their prefetch.
This proprietary tech isn't helpful and is a massive dev resource sink. And let's not kid ourselves, there were many better ways for Google to prioritize and encourage speedy websites.
>And let's not kid ourselves, there were many better ways for Google to prioritize and encourage speedy websites.
That's not the goal, though. Better tracking of your social graph is the goal of AMP. It's like alt.test to see how fast your link propagates, and where it goes. Useful information for influencing you and others.
> wasted into a tech which should have been used for the standard web instead.
But its all just javascript, html, and css. It is the open web. They're also taking bits, like Signed Exchanges, to the standards bodies to make then "standard web" as well.
I mean many of their actions, on the surface, could be euphemistically called "helping humanity" when in reality they're only helping Google.
Penalizing non-https sites: "we're making the web more secure" - and lock out advertisement surface to the benefit of our ads quasi-monopoly (admittedly, a weak case though)
Android Stagefreight bug: "we're disabling MMS to protect Android users" - and by the way close a channel for easy publishing with carrier billing that is part of the highly regulated 3G/4G stack
HTML5: "we're advancing the web and make it fully portable" - and also capture HTML standardization and make it so overcomplicated and never-ending that even MS (and long-time pioneer Opera) are forced-out of producing web browsers alltogether
"Evil"? Is that the word you're searching for? Here, let's use it in a sentence for context: "Google is Evil."
Yeah, that seems like it fits the billet!
If you publish AMP pages, you should publish server-side-rendered AMP pages. Similar to minifying your HTML or CSS, running AMP Optimizer or the Go transformers should be a normal part of your build / rendering chain. The improved rendering performance makes a big difference in FCP times, but more importantly, in the user experience.
"
Other than being the most heavy handed, imperative/authoritarian style call to arms I've seen, the part of this that really bakes my cake is "makes a big difference... in the user experience."
Ya know what makes the experience of visiting my website great for a user? When they actually visit MY website. It's like, the single most fundamental part of a website visiting experience. When their browser and my server host kanoodle around in cyber space together, instead of having some creepy cuckold experience involving Google's server. So I'm thinking that AMP, and all derivative technologies, should really make like 'Google Health' and retire to the trash bin.
Anyone fancy going through the AMP library and inspecting it for cruft?