To suggest that an end user would go about disabling JavaScript and other reasons just shows how HN is in a bubble and don’t really understand that 99% of the users don’t care.
To suggest that an end user would go about disabling JavaScript and other reasons just shows how HN is in a bubble and don’t really understand that 99% of the users don’t care.
Amp gets ride of those.
- the video is automatically muted before autoplay starts
- when the video is scrolled out of view, the video is paused
- when the video is scrolled into view, the video resumes playback
- when the user taps the video, the video is unmuted
- if the user has interacted with the video (e.g., mutes/unmutes, pauses/resumes, etc.), and the video is scrolled in or out of view, the state of the video remains as how the user left it. For example, if the user pauses the video, then scrolls the video out of view and returns to the video, the video is still paused.
Source: https://github.com/ampproject/amphtml/blob/master/spec/amp-v...
So why isn't it done?
You think Google could get away with stripping or editing commercial pages by default? Be serious.
>Reader mode on browsers do a good job of it on most sites
Then use it.
>they can publish guidelines on how to structure your site to make it easier for reader mode to work which wouldn't be that problematic (it would also encourage accessibility).
Google actually does a lot of that. They publish a lot of guidelines, including testing tools (like Lighthouse) to have developers build faster websites. Case in point: https://web.dev/measure
No one said anything about default. It can be opt in like amp but the difference is here simply that they don't require a new standard.
Other ways they could solve is just disincentivise slow loading pages. They have said speed is a factor and tried to introduce some features such as showing how fast a page is on chrome as an experiment.
They could have pushed that more.
But that's exactly what amp is. An opt-in set of standards for creating fast-loading, cach-able pages. There is also no reason why websites couldn't replicate this outside of amp ... but they don't.
>Other ways they could solve is just disincentivise slow loading pages.
They do that ... in all kinds of ways. The problem is that with their position, they can destroy a lot of businesses if they apply these kinds of rules haphazardly. There's no simple solution here.
Not exactly. For one, you could introduce opt in for Google to cache your page through a meta tag. No need for entirely new markup and tools. I have no problem with amp as a concept but the implementation leaves me sour. Amp specification has been growing in complexity that I don't notice speed differences on many sites anymore.
They also inject their own js which I don't find amusing.
Many sites are abusing amp to rank on Google. Reddit, pinterest, etc. It's a terrible experience as a user. They also didn't fix url and domain problem until recently. It's a usability problem.
I can't search for the specific tab by the domain name of the site on my browser. They default opt-in to downloading content in the background for amp feed on chrome android. There are many little annoyances like this one that make me dislike amp.
Plus, amp isn't heuristic based. If my network speed is fast enough, I don't need the stripped out page.
Google doesn't create standards. They are one of the major stakeholders, but they don't have the final say.
>That's the whole issue here.
No. The issue is that Google built a browser that is better than anything now, and was better than anything out there for the past decade and got themselves into a dominant position. They haven't yet abused that position - contrary to a lot of the posts in this thread - but people are nervous. I can respect that viewpoint because it is something to worry about.
That is leveraging their existing position as a search engine and aggregator to force a standard.
Switch your search engine to something else.
Google search results have become less and less relevant unless I'm actually trying to buy something.
I don't think AMP is necessary for that.
This can be solved by blocking 3rd party JavaScript, no need for anything Google related.
Half the argument is "Google is taking too much control over the web by forcing people to use AMP" and the other half is "Google is to blame for companies using non-Google related services when they don't use AMP because they created the platform for it (??)".
I can understand the first half of the argument. The second half seems to blame Google for creating the web or something?
But that argument doesn't hold up with Javascript based ad serving, which was around prior to Google.
JavaScript based ad/analytics tech is bloating the web. Everyone knows this, and there's no denying it. Google is one of the main advertising/analytics platforms on the web. Google is aware that JS is poisoning the web, but they don't want to kill the golden goose and they do want to entrench their ad monopoly. How to square the circle?
They should but won't just tell advertisers that creatives need to be static image/video assets, thereby saving bandwidth, protecting privacy, and not really doing anything to ad buyers (because ad buyers are driven by their fixed budgets and not by absolute platform capabilities, just relative capabilities). Since that's too risky to Google's core business, instead they create a new format (AMP) with deliberately limited JS capabilities and, oh yeah, built in support for Google ads.
For everyone who is not Google, this solution sucks. It means duplicate work to create a new format, the new format is different than the web but not a meaningful source of new traffic because it's just a splinter of existing traffic, and it further exposes your business to Google as the core gatekeeper of revenue (FaceBook is the other revenue gatekeeper). That is, you need Google search and Google ad money to survive and if they change the search algo or ad rates (ie now ads need to be videos or now ads need viewability or whatever), you can be crushed without notice.