3 ms·
If it's just a website, then I agree that is indeed excessive. If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode vide
by osrec 8y ago
If it's just a website, then I agree that is indeed excessive. If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable, and probably a good candidate to be a PWA.
I know a lot of people hate the idea of doing everything in the browser, but seriously, it's the one ubiquitous platform that we have, which even competing entities have agreed to standardise. I personally think it will be the most popular app delivery mechanism in the next few years, even on mobile devices.
- dvtrn 8y agoIf, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable 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.
- zdragnar 8y ago> but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element? 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.
- dvtrn 8y agoParent 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. Since when did forms become useless and what web-based video editor are you (or the original reply-er) pointing to that uses AMP?
- zdragnar 8y agoWe're talking about two completely separate types of websites. Nobody said forms are useless. Web-based video editing was a hypothetical example. AMP wasn't really part of this discussion; presumably, lots of JS + PWA functionality in the hypothetical video editing example was the referenced useful functionality. 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.
- dvtrn 8y agoWe're talking about two completely separate types of websites. Nobody said forms are useless. Web-based video editing was a hypothetical example. AMP wasn't really part of this discussion 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?
- osrec 8y agoI agree that the initial hit to download 15MB is a lot. But if we think of native apps, users would need to download them from the app store as well. If their internet is slow, both experiences are bad. 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!
- dvtrn 8y agoOkay but why even are web editing applications even being pushed to the web? Why even is this hypothetical relevant for a discussion of AMP here? I understand more and more former desktop operations are being pushed to web clients but full-fledged video editors? 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.
- osrec 8y agoI assume you mean video editing. 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.
- dvtrn 8y agoSure, but this is just as achievable, if more agreeably challenging on the desktop as a platform as it is on the web. 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.
- 8y ago
- ForHackernews 8y agoWhy would you not just edit and encode video locally, with an actual installed program? 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!
- Spivak 8y agoSuch a web application would essentially be an installed program! 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.
- C1sc0cat 8y agoI wish I could upvote this more than once
- rlpb 8y ago> perhaps an app that lets you edit and encode video Fundamentally, 15mb is excessive even for that, even if it is common practice for such things to bloat to that size.
- ryandrake 8y agoTo put it into perspective, that's larger than the entire post-install size of the original DOOM PC video game, including all sound and artwork.
- osrec 8y agoNot really - imagine if you're looking to create a fully featured video editor, complete with 3d effects and whatnot. It could well exceed 15mb to deliver all the required functionality.
- dvtrn 8y agoShouldn't this be a native desktop application versus foisting it onto web clients? If we're talking "fully featured"?
- osrec 8y agoThis is where the paradigm shift is coming. Your past experiences say it must be a desktop native app, but I believe things like WASM, web workers etc will allow such things to run comfortably in the browser. I really do believe people will build for the browser more than they will for the desktop because it's a more universal platform. I can even imagine a future where, for the majority, the only native app you have on your machine is a browser, and everything else is some variant of a PWA. I really feel this will happen very soon.
- ForHackernews 8y agoThis sounds like a nightmare.