31–40 of 225 posts
This guy doesn't know what AMP does. AMP is a subset of HTML that can be validated safe to prerender. That means instant page loads for the user, not merely fast.
What do you mean by “safe to prerender?”
Earlier quoted context omitted.
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…
> 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.
This guy doesn't know what AMP does. AMP is a subset of HTML that can be validated safe to prerender. That means instant page loads for the user, not merely fast.
The outside bits of a Trojan horse are attractive for a reason.
The author says you can do these things anyway without AMP, but what he doesn't get is that web developers were not doing them. It took the nudge of AMP to get decent performance on the mobile web. He also failed to mention a key AMP rule: all CSS is in the head, a max of 50 KB. There is no external CSS at all. That's crucial. It reverses a persistent anti-pattern in web development that calls for a bunch of separate…
Ironically, with the advent of HTTP2, more requests might be a better thing. Separate out bundles into per-page (or even per-component!) chunks and ensure you're only sending the user the content they need, without additional overhead.
Earlier quoted context omitted.
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…
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 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…
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!
But you do need "PWA" if you want your site to work offline. PWAs were never really sold as something that would make your site's initial load time faster. Not really sure how the author got that impression. It's almost like saying "you don't need jQuery to make your site faster" - to those who understand the purpose of jQuery, it's a bit of a nonsensical statement.
Can't you just use ServiceWorkers in a regular webpage? Seems like you can. That would allow you to have an offline persistent website while still using a webpage. https://caniuse.com/#feat=serviceworkers
(but I also avoid using the term for exactly this reason)
Earlier quoted context omitted.
> 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.
To 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.
> By the way, since you first opened this article my ServiceWorker has downloaded XXX Mb of useless data in background. I hope you are on WiFi :)
But the code doesn't really download anything. It stores the intial datetime your first load the page, and diff to the current time, convert it to "bytes" every second.
Earlier quoted context omitted.
The outside bits of a Trojan horse are attractive for a reason.
It is the only available solution to a real problem. If you have a better solution, by all means, be a hero. Meanwhile, the rest of the search and content aggregation industry has gone with AMP, which works today.
Because Google effectively gave them no choice.