Can someone provide more info on this? the obsolescence of devices part specially. The linked essay talks about what is web waste, i.e. useless high res videos and images, trackers, and bad code only.
It’s wasteful, a massive waste of storage and energy that both accelerates the obsolescence of computational devices and is environmentally irresponsible
Can someone provide more info on this? the obsolescence of devices part specially. The linked essay talks about what is web waste, i.e. useless high res videos and images, trackers, and bad code only.
I think the general idea is that when a website has a .75 gigabyte memory footprint, as youtube can, it pushes the limits of old devices, or breaks them. Ditto with websites that need to execute...
Exemplary
I think the general idea is that when a website has a .75 gigabyte memory footprint, as youtube can, it pushes the limits of old devices, or breaks them. Ditto with websites that need to execute 30,000,000 machine instructions in order to format and pretty print some text and images, that's going to tax a CPU.
As a curious little anecdote, I opened amazon.com and captured the network stats up until the point that amazon issued the actual / response to let the browser know that the page is considered loaded rather than loading:
332 requests
5.12 MB / 3.04 MB transferred
DOMContentLoaded: 601 ms
load: 21.44 s
of this, 811kb that wasn't blocked by uBlock or adBlockPlus was javascript. 811k is a lot of potential code to be executing. If you assume folks are writing 50 characters per line of code on average, that's 16 million lines of code and associated libraries to make amazon.com run. Obviously not all (or in many cases most) lines are executed, but others are likely executed many times. For example, Amazon.com phones home every 30 seconds so you are eating the performance hit of that call twice a minute every minute that you have an amazon tab open.
How are you extrapolating 811 kb to 16 million LoC? That would require encoding 20 LoC per byte, which I don't think is physically possible. Javascript files are typically encoded as UTF-16 so...
Exemplary
How are you extrapolating 811 kb to 16 million LoC? That would require encoding 20 LoC per byte, which I don't think is physically possible. Javascript files are typically encoded as UTF-16 so that means something like 400k "characters" of Javascript. It's minified so the actual source code is definitely more, but Photoshop CS6 is only 4.5 million LoC. There's no way in hell the Amazon home page loads 16 million lines of Javascript.
Big oof. I'm off by a factor of 1,000 (derped and took kb as 1MM bytes), meaning my conservative assumption should be 16,000 lines of code. You're right of course that that also isn't realistic...
Big oof. I'm off by a factor of 1,000 (derped and took kb as 1MM bytes), meaning my conservative assumption should be 16,000 lines of code. You're right of course that that also isn't realistic (un the opposite direction) given that they've minified the output.
Web pages have evolved to take more and more resources so that older devices aren't powerful enough to run them. But this is more true of mobile phones and tablets; desktop-class machines can last...
Web pages have evolved to take more and more resources so that older devices aren't powerful enough to run them. But this is more true of mobile phones and tablets; desktop-class machines can last a lot longer.
I partially blame Apple and its Retina displays, resulting in web designers using larger file sizes. There are ways to choose appropriate file sizes for the device, but it's kind of a pain and not everyone does it.
I remember when retina displays first came with iPhone 4S, PPI (pixel per inches) was one of the lookout features in Android phones here. About large file sizes, does using AMP pages help in any...
I remember when retina displays first came with iPhone 4S, PPI (pixel per inches) was one of the lookout features in Android phones here.
About large file sizes, does using AMP pages help in any aspect?
There's two parts to AMP that provide benefits: it imposes some restrictions in javascript and page resources you can use, and it allows the page to be preloaded into a user's browser before they...
There's two parts to AMP that provide benefits: it imposes some restrictions in javascript and page resources you can use, and it allows the page to be preloaded into a user's browser before they click a link to it. The first part, the imposed performance and resource size restrictions, can be self-imposed without AMP. The second part is useful for some cases (for getting the very first load time lower) but it's about removing the time spent on downloading resources, not about lowering the CPU time needed to render the resources.
They certainly could. But why not... let websites choose whichever web framework they want to use? We don't normally notice whether a website is using React or Angular or some other home-grown...
They certainly could. But why not... let websites choose whichever web framework they want to use? We don't normally notice whether a website is using React or Angular or some other home-grown thing. That's their problem. These are also frameworks from Facebook and Google, which a lot of people don't like, but somehow they don't attract the same negative attention.
I think AMP's biggest mistake was putting it into the URL, making users aware of it. Oddly, that was supposed to be fixed last year and yet I still see a lot of AMP in URL's, so I wonder what happened?
Yes, good point. I think CDN’s help more than they hurt, though. Web bundle caching should hopefully help even more in places far from where most people host their websites. In the old days there...
Yes, good point. I think CDN’s help more than they hurt, though. Web bundle caching should hopefully help even more in places far from where most people host their websites.
In the old days there was a network of mirror servers where people would download big files from SourceForge or wherever, and it still seems like a waste to ship files around the world again for each user when they can be cached locally.
React is a javascript framework. AMP is (sort of) an HTML framework but there's a reason HTML frameworks aren't much of a thing. They're unnecessary. The only reason anyone uses AMP is for better...
React is a javascript framework. AMP is (sort of) an HTML framework but there's a reason HTML frameworks aren't much of a thing. They're unnecessary.
The only reason anyone uses AMP is for better Google rankings, as a framework it doesn't provide any benefits by forcing you not to do things you can just as easily choose not to do.
As a caching/preloading system it doesn't provide any benefits that outweigh giving Google more control of the web.
I think those of us that understand what AMP is, why it exists, and what the future implications are, have an obligation to increase awareness.
I'm curious, why aren't HTML frameworks more of a thing? I haven't used them, but I also haven't used Javascript frameworks all that much either, since most recently I've used Dart more for this,...
I'm curious, why aren't HTML frameworks more of a thing? I haven't used them, but I also haven't used Javascript frameworks all that much either, since most recently I've used Dart more for this, and before that I did things more on the server side.
Large file sizes typically come out of lack of optimization, in both pre- and production. "Pre-production" here means optimization of goals. Are you looking to deliver 10k high-resolution images...
About large file sizes, does using AMP pages help in any aspect?
Large file sizes typically come out of lack of optimization, in both pre- and production.
"Pre-production" here means optimization of goals. Are you looking to deliver 10k high-resolution images to the end user at once, or 10 lower-res previews at a time? This applies to every aspect of making a website: from HTML (page structure can get bloated very quickly), CSS (stylesheets aiming to make sure they capture every possible scenario end up weighing like a decent photo), and JS (which is where the real fun starts; see further), to secondary assets: images, audio, video, network requests...
Production is likely where your bloat starts even when you have a clear goal. You see, bloat is not a consequence of "fat code": you can make the most diverse code lean and lightweight (relative to its "domain breadth") if you care enough. Most enterprises cannot begin to give a damn. If it loads okay for high-end users (the easiest metric to fool yourself by), it's fine. They resort to using third-party libraries (bloated by their being required to handle damn near every case possible within the confines of their own domains) to render the final website quickly because that's how money is made.
Even with a clear set of goals, when you have generic tools at hand, you're far more likely to produce a site that's heavy and loads slowly as a dev because nobody's paying you to be careful, and whatever headache of optimization and thoughtful design that could be eliminated with readily-available methods will be acted on as such, even when this thoughtful design is what makes your site load like it's on CDN even though it's served from a crowded shared hosting.
You can make the choice yourself. AMP forces you to choose the restrictions in return for a promise of performance. It's a second-order cure: a cure for a disease that's caused by an overwhelming change in lifestyle to begin with. You change the lifestyle (adopt a more thoughtful design paradigm as a company), you no longer need AMP because the "health problem" is no longer there.
This and what it links to is relevant. This site loads better than most other sites I use, even ones that are pretty much just straight text. It's super bad that Medium articles, despite being...
I really appreciate this blog post. I myself have been digging in a little more into tilde-esque sites, etc.; partly for the same reasons that the author noted, but also out of sheer curiosity...
I really appreciate this blog post. I myself have been digging in a little more into tilde-esque sites, etc.; partly for the same reasons that the author noted, but also out of sheer curiosity (sort of chasing the new, novel thing). As days pass, and as i'm exposed to more of these communities (and associated platforms), i feel i'm becoming more of something like a digital/cyber/tech punk. Here, i thought only the young folks go through a punk/rebellious phase...but i'm finding that i'm doing so as i get older (nearly into my 50s)!
Can someone provide more info on this? the obsolescence of devices part specially. The linked essay talks about what is web waste, i.e. useless high res videos and images, trackers, and bad code only.
I think the general idea is that when a website has a .75 gigabyte memory footprint, as youtube can, it pushes the limits of old devices, or breaks them. Ditto with websites that need to execute 30,000,000 machine instructions in order to format and pretty print some text and images, that's going to tax a CPU.
As a curious little anecdote, I opened amazon.com and captured the network stats up until the point that amazon issued the actual / response to let the browser know that the page is considered loaded rather than loading:
332 requests
5.12 MB / 3.04 MB transferred
DOMContentLoaded: 601 ms
load: 21.44 s
of this, 811kb that wasn't blocked by uBlock or adBlockPlus was javascript. 811k is a lot of potential code to be executing. If you assume folks are writing 50 characters per line of code on average, that's 16 million lines of code and associated libraries to make amazon.com run. Obviously not all (or in many cases most) lines are executed, but others are likely executed many times. For example, Amazon.com phones home every 30 seconds so you are eating the performance hit of that call twice a minute every minute that you have an amazon tab open.
How are you extrapolating 811 kb to 16 million LoC? That would require encoding 20 LoC per byte, which I don't think is physically possible. Javascript files are typically encoded as UTF-16 so that means something like 400k "characters" of Javascript. It's minified so the actual source code is definitely more, but Photoshop CS6 is only 4.5 million LoC. There's no way in hell the Amazon home page loads 16 million lines of Javascript.
Big oof. I'm off by a factor of 1,000 (derped and took kb as 1MM bytes), meaning my conservative assumption should be 16,000 lines of code. You're right of course that that also isn't realistic (un the opposite direction) given that they've minified the output.
Web pages have evolved to take more and more resources so that older devices aren't powerful enough to run them. But this is more true of mobile phones and tablets; desktop-class machines can last a lot longer.
I partially blame Apple and its Retina displays, resulting in web designers using larger file sizes. There are ways to choose appropriate file sizes for the device, but it's kind of a pain and not everyone does it.
I remember when retina displays first came with iPhone 4S, PPI (pixel per inches) was one of the lookout features in Android phones here.
About large file sizes, does using AMP pages help in any aspect?
There's two parts to AMP that provide benefits: it imposes some restrictions in javascript and page resources you can use, and it allows the page to be preloaded into a user's browser before they click a link to it. The first part, the imposed performance and resource size restrictions, can be self-imposed without AMP. The second part is useful for some cases (for getting the very first load time lower) but it's about removing the time spent on downloading resources, not about lowering the CPU time needed to render the resources.
Obligatory: Pushing more of the web onto Google servers really isn't worth any of the potential benefits.
It can be used as an ordinary web framework, though, like React. Caching on Google or Cloudflare is separate.
They certainly could. But why not... let websites choose whichever web framework they want to use? We don't normally notice whether a website is using React or Angular or some other home-grown thing. That's their problem. These are also frameworks from Facebook and Google, which a lot of people don't like, but somehow they don't attract the same negative attention.
I think AMP's biggest mistake was putting it into the URL, making users aware of it. Oddly, that was supposed to be fixed last year and yet I still see a lot of AMP in URL's, so I wonder what happened?
Yes, good point. I think CDN’s help more than they hurt, though. Web bundle caching should hopefully help even more in places far from where most people host their websites.
In the old days there was a network of mirror servers where people would download big files from SourceForge or wherever, and it still seems like a waste to ship files around the world again for each user when they can be cached locally.
React is a javascript framework. AMP is (sort of) an HTML framework but there's a reason HTML frameworks aren't much of a thing. They're unnecessary.
The only reason anyone uses AMP is for better Google rankings, as a framework it doesn't provide any benefits by forcing you not to do things you can just as easily choose not to do.
As a caching/preloading system it doesn't provide any benefits that outweigh giving Google more control of the web.
I think those of us that understand what AMP is, why it exists, and what the future implications are, have an obligation to increase awareness.
I'm curious, why aren't HTML frameworks more of a thing? I haven't used them, but I also haven't used Javascript frameworks all that much either, since most recently I've used Dart more for this, and before that I did things more on the server side.
HTML is markup, there isn't a lot of value a framework can bring, so front end frameworks focus mostly on javascript and CSS.
Large file sizes typically come out of lack of optimization, in both pre- and production.
"Pre-production" here means optimization of goals. Are you looking to deliver 10k high-resolution images to the end user at once, or 10 lower-res previews at a time? This applies to every aspect of making a website: from HTML (page structure can get bloated very quickly), CSS (stylesheets aiming to make sure they capture every possible scenario end up weighing like a decent photo), and JS (which is where the real fun starts; see further), to secondary assets: images, audio, video, network requests...
Production is likely where your bloat starts even when you have a clear goal. You see, bloat is not a consequence of "fat code": you can make the most diverse code lean and lightweight (relative to its "domain breadth") if you care enough. Most enterprises cannot begin to give a damn. If it loads okay for high-end users (the easiest metric to fool yourself by), it's fine. They resort to using third-party libraries (bloated by their being required to handle damn near every case possible within the confines of their own domains) to render the final website quickly because that's how money is made.
Even with a clear set of goals, when you have generic tools at hand, you're far more likely to produce a site that's heavy and loads slowly as a dev because nobody's paying you to be careful, and whatever headache of optimization and thoughtful design that could be eliminated with readily-available methods will be acted on as such, even when this thoughtful design is what makes your site load like it's on CDN even though it's served from a crowded shared hosting.
You can make the choice yourself. AMP forces you to choose the restrictions in return for a promise of performance. It's a second-order cure: a cure for a disease that's caused by an overwhelming change in lifestyle to begin with. You change the lifestyle (adopt a more thoughtful design paradigm as a company), you no longer need AMP because the "health problem" is no longer there.
This and what it links to is relevant. This site loads better than most other sites I use, even ones that are pretty much just straight text.
It's super bad that Medium articles, despite being text, takes seconds to load.
I really appreciate this blog post. I myself have been digging in a little more into tilde-esque sites, etc.; partly for the same reasons that the author noted, but also out of sheer curiosity (sort of chasing the new, novel thing). As days pass, and as i'm exposed to more of these communities (and associated platforms), i feel i'm becoming more of something like a digital/cyber/tech punk. Here, i thought only the young folks go through a punk/rebellious phase...but i'm finding that i'm doing so as i get older (nearly into my 50s)!