5 ms·

"Building apps this way makes them highly cachable. It''s trivial to deploy this app on a CDN." Building apps any way makes them cachable. I don't get it. The

by dvt 14y ago

"Building apps this way makes them highly cachable. It''s trivial to deploy this app on a CDN." 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.

dwild 14y ago
I think his first point is not about the file size but about the fact that it need to be static content (or content that use jsonp on an external server). That way you can drop it on any CDN and it will still work.
Keyneston 14y ago
> This isn't 1983. Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant. 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.
- dvt 14y ago
  >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. 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.
  - ajross 14y ago
    No, it might simply be a phone from 2009 on a EDGE network with poor signal. Hell, I'm routinely annoyed by slow web apps on my very nice phone from 2012 on LTE...
  - pbhjpbhj 14y ago
    >Laptops from 1998 running IE5 // Nope but laptops from '98 running FF20 (and probably other modern browsers) are a possibility.
devindotcom 14y ago
"Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant." What? Am I missing something, or is this a colossally irresponsible and narrow-minded way to approach software development?
- tsunamifury 14y ago
  Yes he doesn't seem to realize that the larger the app the harder it is to scale i.e. thousands of requests per second for a <1mb HTML5 app could be a serious scaling problem. Not to mention his complete ignorance of the variable bandwidth of mobile devices.
  - dvt 14y ago
    Scaling a service has nothing to do with client size. Like, literally nothing.
    - waxjar 14y ago
      It has something to do with the size of your app, though.
      - wnsnw 14y ago
        No, it doesn't. Size of application can correlate strongly with complexity and thus number of queries to the server, but there is nothing that dictates a 1.44MB+ HTML5 application ever even touches a server.
        TheZenPsycho 14y ago
        Aside from uhh.. DOWNLOADING the app. from. the. server. Unless you are imagining those files magic themselves onto your local machine somehow?
        Dylan16807 14y ago
bradgessler 14y ago
"Building apps any way makes them cachable." 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_Computing 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!
- mvanveen 14y ago
  > In our world we might have 10,000 people sitting in a room pulling our mobile app over a crappy wifi connection. 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. Link: http://blog.chriszacharias.com/page-weight-matters http://blog.chriszacharias.com/page-weight-matters
phylae 14y ago
Minimizing app size is quite relevant in some circumstances. For example, when an app is being used at a live event, you could have 1000s of people downloading it at the same time over the same wifi connection. Even a small decrease in the app size will help decrease that initial bandwidth spike.
coenhyde 14y ago
"Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant." 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.
kalleboo 14y ago
> Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant "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.
PavlovsCat 14y ago
This isn't 1983. Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant. 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.
Millennium 14y ago
>Building apps any way makes them cachable. I don't get it. The app could be 50mb and the browser would still cache it. 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.

by dvt 14y ago

dwild 14y ago

I think his first point is not about the file size but about the fact that it need to be static content (or content that use jsonp on an external server). That way you can drop it on any CDN and it will still work.

Keyneston 14y ago

> This isn't 1983. Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant. 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.

dvt 14y ago
>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. 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.
- ajross 14y ago
  No, it might simply be a phone from 2009 on a EDGE network with poor signal. Hell, I'm routinely annoyed by slow web apps on my very nice phone from 2012 on LTE...
- pbhjpbhj 14y ago
  >Laptops from 1998 running IE5 // Nope but laptops from '98 running FF20 (and probably other modern browsers) are a possibility.

devindotcom 14y ago

"Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant." What? Am I missing something, or is this a colossally irresponsible and narrow-minded way to approach software development?

tsunamifury 14y ago
Yes he doesn't seem to realize that the larger the app the harder it is to scale i.e. thousands of requests per second for a <1mb HTML5 app could be a serious scaling problem. Not to mention his complete ignorance of the variable bandwidth of mobile devices.
- dvt 14y ago
  Scaling a service has nothing to do with client size. Like, literally nothing.
  - waxjar 14y ago
    It has something to do with the size of your app, though.
    - wnsnw 14y ago
      No, it doesn't. Size of application can correlate strongly with complexity and thus number of queries to the server, but there is nothing that dictates a 1.44MB+ HTML5 application ever even touches a server.
      - TheZenPsycho 14y ago
        Aside from uhh.. DOWNLOADING the app. from. the. server. Unless you are imagining those files magic themselves onto your local machine somehow?
        Dylan16807 14y ago

bradgessler 14y ago

"Building apps any way makes them cachable." 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_Computing 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!

mvanveen 14y ago
> In our world we might have 10,000 people sitting in a room pulling our mobile app over a crappy wifi connection. 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. Link: http://blog.chriszacharias.com/page-weight-matters http://blog.chriszacharias.com/page-weight-matters

phylae 14y ago

Minimizing app size is quite relevant in some circumstances. For example, when an app is being used at a live event, you could have 1000s of people downloading it at the same time over the same wifi connection. Even a small decrease in the app size will help decrease that initial bandwidth spike.

coenhyde 14y ago

"Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant." 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.

kalleboo 14y ago

> Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant "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.

PavlovsCat 14y ago

This isn't 1983. Worrying about bandwidth, memory, and processing power (in user space) is no longer relevant. 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.

Millennium 14y ago

>Building apps any way makes them cachable. I don't get it. The app could be 50mb and the browser would still cache it. 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.