| > r authenticate the library with a durable subresource integrity (SRI) hash while still remaining valid According to the discussion, there's concern this creates large scale hard to fix security issues. The alternative is to build something like AMP into browsers themselves, and then the normal Chrome/Safari/Edge/Firefox release process could fix issues. But in lieu of that, what's your suggestion? Wait years for standards committees to hash out something at the W3C so that browser vendors implement it, all the while users suffer and Facebook Instant Articles or Apple News soak up more and more web traffic into native, or, ship something that creates an unpatchable security flaw across the web without millions of pages being updated? If not AMP, then what? XHTML Mobile? We've been down that route and it didn't work. Bring back RSS and force mobile publishing to just be RSS summaries for fast loading? Lost in all of this geek fighting is the fact that there's a billion users out there who don't care about the Web vs Native, they only care that shit's slow as hell and their data plan is expensive, and despite all of this, there was apparently no forcing function enticing publishers to make their pages load faster, if anything, right before AMP, it seems each and every "redesign" of top level mobile sites got SLOWER and loaded even more JS. I don't really care about AMP, I care about the Web and I hate closed App Stores soaking up content and making it DRM'ed. In my view, we were on a path to the web collapsing under it's own weight, and AMP is a much needed band aid. If someone can produce a competing framework that does the same thing, can be easily and wildly adopted, and solves all of the problems people are complaining about, I'd wholeheartedly support it in lieu of AMP. But what I don't want to see is more and more of my content forcing me to download stuff from the App Store, or run inside Facebook only. That's a far far worse situation than what we're in now. |