HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ampproject
amphtml
JavaScript2015–2023
ampproject / amphtml

amphtml

The AMP web component framework.

96Distinct people
146Mentions
0Explicit recommenders
14.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The AMP web component framework.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year146 dated mentions

Observed mentions: 2015-10-07 14:41:30 UTC to 2023-02-21 19:56:36 UTC.

01020302015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 14 mentions; 4 submissions, 10 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 28 mentions; 2 submissions, 26 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 27 mentions; 1 submissions, 26 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 30 mentions; 5 submissions, 25 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 17 mentions; 0 submissions, 17 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC14410
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC28226
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC27126
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC30525
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC17017
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC17017
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC909
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC312

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
AMP ⚡ ⚡⚡⚡ Tooling AMP is a web component framework for easily creating user-first websites, stories, ads, emails and more. AMP is an open source project, and we'd love your help making it better! Want to know more about AMP? amp.dev is the best place to learn more about AMP--and of course the site is made using AMP! For developers using AMP, amp.dev includes guides and tutorials examples reference docs example templates tools to make using AMP easier Having a problem using AMP? The amp.dev Support page has resources for getting help. Use Stack Overflow to ask questions about using AMP and find answers to questions others have asked. Let us know about bugs, and file feature requests to suggest improvements. AMP accepts responsible security disclosures through the Google Application Security program. Want to help make AMP better? docs/contributing.md has information on how you can help improve AMP, including ongoing participation through Slack, weekly design reviews, etc. We strongly encourage code contributions! We enthusiastically welcome new contributors to AMP even if you have no experience being part of an open source project. We've made it easy to get started contributing. Consider joining one of AMP's Working Groups, where most of the day-to-day work in AMP gets done. Other useful information AMP's release documentation provides details on how and when AMP releases new versions, including how to know when a change is live in a release. AMP's roadmap provides details on some of the significant projects we are working on. The AMP meta repository has information about the AMP open source project, including AMP's governance. AMP's code of conduct documents how all members, committers and volunteers in the community are required to act. AMP strives for a positive and growing project community that provides a safe environment for everyone.
Read the full README on GitHub

What Hacker News says

146 sources
Without disclosing too much, I am fairly involved around this topic, and I would say it's definitely heading for deprecation this year. The key giveaway is that Google Analytics 3 will be shutting down in July[0] and AMP has made no progress towards supporting Google Analytics 4[1]. I think it'll be deprecated at first rather than shut down because there are still billions of AMP documents floating around the web. [0] https://support.google.com/analytics/answer/11583528?hl=en [1] https://github.com/ampproject/amphtml/issues/24621
In Ask HN: Is AMPhtml Dead or Dying?
I did some hacky analysis and roughly half of the PRs originated in GitHub and the majority of those are not google employees. Most changes have a github issue attached with discussion, all of the changes have descriptive commit messages regardless of who authored them and there is significant effort to document the decisions and decision process throughout. I can't speak for the release frequency for other organizations' production that consumes this code. That includes many publishers, as well as other AMP caches such as Bing and webmail clients like Yahoo. The repo is for all of AMP, not just the validator. The validator related issues are handled by the "caching" working group (since caches are the consumer of the validator) and you can search for them with this query: https://github.com/ampproject/amphtml/issues?q=is%3Aissue+is...
In Resigning from the AMP Advisory Committee
I won't try to address every part of this writing, but there is one claim that I feel is false: namely that the AMP validation rules are not open source. Here is the code: https://github.com/ampproject/amphtml/tree/main/validator All of the rules are written in human-readable config language. Here are the rules for common HTML elements (https://github.com/ampproject/amphtml/blob/main/validator/va...) and there are rules per-amp-tag (example: https://github.com/ampproject/amphtml/blob/main/extensions/a...) You can build it, run it locally, etc. There are open-source implementations that run in the browser, in a vscode plugin, on the command line via NPM, etc. Other entities can and do use the same code for their validation of AMP. Pull Requests are accepted from anyone and those changes land in Google production and all of the aforemention
Read the rest
ed tooling targets within a few days. There is documentation on how to contribute to and edit these files (https://github.com/ampproject/amphtml/blob/main/docs/compone...).
In Resigning from the AMP Advisory Committee
> all non-amp ad tags, such as my company, Ezoic’s, were delayed by 1 second to make them less effective This is really not true. I was able to find the previous discussion on HN where someone linked to the Github issue about this design decision: https://github.com/ampproject/amphtml/issues/3133 . Note the root goal of this was actually to get non-AMP ads to run faster. This was all fully transparent, and was not some nefarious hidden functionality that Google tacked on in the hopes of tanking other ad networks. Look, I hate AMP as much as your average HN poster, and I don't really disagree that Google is willing to make "technological improvements" as long as they hurt the other guy, and not Google. But I think the discussion gets better, not worse, when folks are more honest about the real reasoning behind why something is implemented
Read the rest
the way it is.
In The End of AMP
Huh. Interesting! https://github.com/ampproject/amphtml/blob/master/spec/amp-f... says that as of April 2020 self-hosted pages don't pass validation: >The AMP Project is looking into options for validation of AMP pages that use an AMP framework hosted outside of cdn.ampproject.org (#27546). As of April 2020, these AMP pages do not pass validation. The linked issue is still open: https://github.com/ampproject/amphtml/issues/27546 And if I look at the official Specs page ( https://amp.dev/documentation/guides-and-tutorials/learn/spe... ) it says this: > Any AMP document MUST [...] contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag. So it seems they're planning on supporting self-hosting, but it's not there yet (and it might be complex to get working).
In I Have Resigned from the Google AMP Advisory Committee
A Google employee commented above about the design reasoning behind this, and it's worth reading and understanding the linked GitHub discussion: > It looks to me like the design for this was https://github.com/ampproject/amphtml/issues/3133 To be clear, I'm not defending Google here, but I just want to point out that it's possible to be "evil" (for whatever that means) without being malicious. That is, I don't think any Google engineer was thinking "Haha! We'll slow down all those non-AMP ads deliberately!" The thinking seems to have been "We want to be somewhat 'backwards compatible' to allow non-AMP ads, but we don't want those ads to kill AMP's performance benefits, so we'll still load them but only after the AMP content has loaded and rendered." However, this is exactly the mindset that I hate about AMP, and it drives me a little nuts
Read the rest
when I see Googlers defending it. I get that your intentions are good, but don't you realize that it's not an accident that the primary beneficiary of AMP is Google, e.g. by keeping users in the SERP instead of going off to sites where the content is hosted, and by making everything ideal for the ad network you own? Googlers have to come to realize that essentially all of their engineering decisions are constrained by what makes more money for Google, not what is best for users. Sure, faster page loads are great, but do you honestly think Google would have supported a tech that made page loads faster ig it didn't cause people to look at more Google ads? I mean, if Google really supported what was best for users, they'd support more privacy controls a la what is coming in iOS Safari, but of course they don't because that's bad for their business. I hate AMP and hope it dies, but I don't hate it because I think there aren't some user benefits to it, I hate it because it is a further attempt by a single company to own even more of the Internet.
In States bring action against Google under federal and state antitrust laws [pdf]

Showing the 15 most recent of 146 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.