Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form.
Sadly, these aren't going to get to experience a decent chunk of the internet anyway, since video, gifs, and images all frequently weigh significantly more when put together.
Since when did forms become useless and what web-based video editor are you (or the original reply-er) pointing to that uses AMP?
Take Google Sheets as an example. I don't know what the total download size is for the JS (certainly not 15mb), but it's an example of a JS heavy website where you wouldn't want to serve -> submit form -> serve cycle for every user input.
This entire discussion started from an opinionated blog post that directly discusses AMP and it's performative nature on the web.
So yes.
It is.
You can't just invent a hypothetical that makes it easier to justify exceptions to the very topic the original blog post we're talking about here, of course exceptional things like resource-heavy, full-featured web apps are going to be outliers to lightweight payloads for web apps. For some reason I highly doubt those were the types of use-cases Google had in mind when AMP was released, so why are we even considering exigent outliers on this one?
Having re-read your post, you seem to have misunderstood my point. You seem to be arguing that keeping things lightweight is good. I agree with you there! But remember, for certain applications, this is not always possible. In my hypothetical video editing app, 15MB could well be just the core logic - it's not 1MB of logic and 14MB of bells and whistles!
As I mentioned to another commenter: can you show me an example of a full-featured, web-based video editor using AMP?
I'm not sure if I can buy in that this is the example to rest upon here.
Many reasons, but the top one in my opinion is having a single code base across all devices. I think it's a worthwhile goal, personally.
I'm not sure if it's a particularly convincing axiom here for heavy payloads of web-apps, particularly when we're talking about simply delivering content to cite a singular code base for why a web application that would benefit from AMP (which was the central conceit of the actual blog post we're all here discussing today) needs to be 15MB heavy.
Well formed markup and smart content compression could accomplish the same thing.
I guess you got your wires crossed, as AMP is not something I was talking about - my focus was specifically on PWAs and the fact that it's not a problem if their payloads are large.
But yes, AMP (read: glorified CDN) wouldn't solve much if you have 15MB to download each time you visit a site (aside: you wouldn't need to do this with PWAs because of caching).
Everyone with a computer produced after 2010 has the equivalent of late-90s supercomputer, and we were doing video editing on desktops in the 90s!
Look, I know its weird but there is finally a multi-implementation cross-platform runtime that people actually want to use. I would be so excited if I could run full Photoshop in my browser on Linux.
You either have an abundance of high speed internet access, or benefit from internet usage that isn't metered by the amount of data consumed, or both.
Functionality or not, heavy web experiences leave out a lot of people who would otherwise be willing and capable users of %product% if it weren't for the excessive payloads they're often expected to consume just to be a user when that payload could quite trivially be reduced and still accomplish the goal of delivering content and information to the end user.
So here's my question: forget about people who hate doing everything in the browser, what about the users who just don't have access to Cable+ internet speeds, want to use the product, but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element because the browser is all this user is familiar with?
Not everyone on the internet is a regular of HackerNews who groks native applications versus web apps. At what point do we start focusing on the content and asking ourselves "Do I REALLY need this animation library just to indicate 'Start here' is where they should be interacting with my webform"?
To answer that rhetorical question for you: probably, quite likely not.