Not true. For example, a rails website out of the box doesn't cache content pages. Before sprockets the assets were not explicitly cached. There's quite a bit of work that you have to do to make an application highly cacheable. Using a static site generator like Middleman ensures that your app has no moving parts when its on a server, which makes caching very trivial.
"And why would you get bonus points for making it 700kb or less?"
Yes, you would. In our world we might have 10,000 people sitting in a room pulling our mobile app over a crappy wifi connection. Every byte counts and we need to be super aggressive about caching. I encourage you to read http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput....
"And setting arbitrary limits (1.44mb) is just silly."
It is silly, that's the point! Our app weighs in at roughly 2.5mb with Retina assets, which I had to cut to get it to fit on the floppy.
Laugh a little bit, this is suppose to be fun!
Just to reinforce this point to folks who are skeptical, there's this great writeup called "Page Weight Matters" by Chris Zacharias where he talks about how smaller page size for a YouTube video literally lit up African, South American, and Southeast Asian smartphone traffic.
By minimizing page size through switching to html5, the page load times dropped to a sufficient level where people who previously did not have access to youtube could finally get access.
Key quotes:
> Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load!
> This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything.
Except not everyone is running a top of the line desktop in a first world country. Even in a first world country you have people on older laptops, slower internet, or even metered internet.
Minimizing the size of your app is still a worthy goal. Maybe not to the level pushed in the article.
If you're writing an HTML5 app, I assume your target doesn't comprise of Laptops from 1998 running IE5.
> Minimizing the size of your app is still a worthy goal. Maybe not to the level pushed in the article.
I agree.
Nope but laptops from '98 running FF20 (and probably other modern browsers) are a possibility.
What? Am I missing something, or is this a colossally irresponsible and narrow-minded way to approach software development?
Not to mention his complete ignorance of the variable bandwidth of mobile devices.
There are many reasons to want small files, but scaling isn't one of them.
If you want to scale, you'll have to reach me at some point and you won't reach me with a huge app that takes me 30 seconds to load.
Worrying about micro-optimizations (like making sure the size of your code is <= 1.44mb) takes time away from worrying about more important issues.
"Oh no, our application can't be simultaneously downloaded by 3 million martians because our client is too big." I'm being facetious, of course, but I think the point applies. Don't build stuff with weird contingencies in mind. The average user (of an HTML5 app) will not have to worry about processing power, bandwidth, or client size. As long as it's not like 20mb or something stupid.
And, obviously, websites are accessed from all kinds of connections. Not everyone has a generous 3G plan, and even the US doesn't rank that well in average broadband speeds.
Anything you don't have a limit for will become a problem. I don't care how fast computers are, or how much memory they have, or whether you have fibre-optic broadband. If you treat the resources in question like they're infinite, you'll find out the hard way that they most definitely are not. And that's so silly, when you can just set a reasonable limit that guarantees you won't have any problems, and then... not have any problems.
Realistic limits aren't so hard to stick to if they're there, and enforced, right from the start.
The interwebs is international. And even in the first world, many people have crummy Wi-Fi, and some even dialup still. Then there is the fact that your website gets cached, and that "if everybody thought like you", that cache would only be a fraction as useful (that goes for both browser and proxy caches).
And even on a fast machine with lots of ram and a huge SSD; some people like to have a lot of tabs open, and what might not matter much for a single webpage, does make a difference when you multiply it by 20 or 50. Even if that difference is just "the system has more RAM for the filesystem cache" and shaves off a tenth of a second here and there. This isn't 1983 indeed; assuming a big audience, if you only fail shave off 0.1 unnecessary seconds on average per day per visitor, you can easily waste several cumulative lifetimes, to save yourself a bit of time, or even worse, to save yourself thought. (Sometimes there isn't even a trade-off, it's just the difference between being mindless, and being curious and maybe testing a bit.)
Though I agree that the limit is arbitrary. What matters is how bloated it is; the flabbyness of the whole is the sum of the flabbyness of individual parts. If you implement photoshop or after effects as web app, feel free to weigh 5mb or 50mb for all I care. If it's a to-do list, even 50kb might be way too much.
But as a fun exercise for yourself? Limits are among the most interesting things there are, creatively speaking.
That's just plain false. Not only do the standards play a role in what is and is not cacheable by default, but browsers and (to some extent) users also play a role in deciding what is and is not cached.
>Why? And why would you get bonus points for making it 700kb or less? This isn't 1983. Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant. Instead, worry about scalability, cross-platform compatibility, code practices, etc, etc.
Bandwidth matters. The Web is not South Korea. Even in the US, broadband penetration in only 68 percent: barely over two-thirds.
Processor power matters. The Web is not gaming rigs. With the death of Moore's Law and the rise of mobile, the average Web-enabled device's processing power is actually falling, not rising.
Memory matters. See above; the same applies.
No, this isn't 1983. It's also not 2003. Keep up.
"According to surveys done by Akamai and Gomez.com, nearly half of web users expect a site to load in 2 seconds or less, and they tend to abandon a site that isn’t loaded within 3 seconds. 79% of web shoppers who have trouble with web site performance say they won’t return to the site to buy again and around 44% of them would tell a friend if they had a poor experience shopping online."
If your 5 MB app takes 50 seconds to load on someone's 1 MBit connection, there's a good chance they'll never see it.
You couldn't be more wrong. What about mobile users? What about international users? What about mobile international users?
When building a HTML5 web app it is very important to watch the download size of your application.
Building apps any way makes them cachable. I don't get it. The app could be 50mb and the browser would still cache it.
"A mobile HTML5 app should probably never be over 1.44MB. If it doesn't fit on a floppy its probably too big. Bonus for fitting on an 8"."
Why? And why would you get bonus points for making it 700kb or less? This isn't 1983. Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant. Instead, worry about scalability, cross-platform compatibility, code practices, etc, etc.
Size should be the last thing on your mind. And setting arbitrary limits (1.44mb) is just silly. Calling this kind of exercise in futility "practical" is even sillier.
"Impresses hipsters."
Ah yes. That explains the up-votes.