Hacker News Reader

Comment by dvt | Hacker News Reader

"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.

View on HN

"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_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!

> 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

> 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.

>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.

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...

>Laptops from 1998 running IE5 //

Nope but laptops from '98 running FF20 (and probably other modern browsers) are a possibility.

"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?

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.

Scaling a service has nothing to do with client size. Like, literally nothing.

It has something to do with the size of your app, though.

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.

Aside from uhh.. DOWNLOADING the app. from. the. server. Unless you are imagining those files magic themselves onto your local machine somehow?

We're talking about static files, right? If you're trying to scale those should be nowhere near your application server. They get served from a CDN and the size is completely irrelevant to technical scaling issues.

Because CDN's are magic and have zero cost?

Money is easy. It's not part of the difficulty of scaling. 1000x the static traffic means 1000x the bandwidth heading to simple, independent, easy to load balance servers. Difficulty added per user: zero. Cost per user: the same or less.

There are many reasons to want small files, but scaling isn't one of them.

Indeed. Downloading the app. A one-time cost. No, I'm not imagining anything - are you?

A one time cost in a universe where your app never changes, CDNs cost nothing, and browsers have perfect caches, and everyone ubiquitously uses the localstorage and app-cache html5 apis.

Not everyone has a blazingly fast internet connection. I don't, even Hackernews loads slow for me at times.

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.

Not at all. There's a very clear trend of micro-optimization obsession. It's funny to see how many questions on SO deal with absolutely silly micro-optimization issues when the rest of the code-base has much bigger problems.

Worrying about micro-optimizations (like making sure the size of your code is <= 1.44mb) takes time away from worrying about more important issues.

Ensuring your app loads quickly over the network is definitely an optimization, but to call it a micro-optimization is wrong. Size on the wire for html5 apps (frequently loaded over mobile connections) is completely relevant.

3g is virtually ubiquitous. And building an app having weird contingencies in mind (atrocious wifi connections, 5 billion people downloading simultaneously, downloading from outer space, etc.) is not good engineering. Unless you like spending time in development hell.

"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.

I'm reading your comment on an intermittent 2.5 g connection.

It is well known that lower response times increase conversions and reduce abandonment on any website. There is absolutely no reason for a website to cross the 1-2mb threshold unless it's a huge web application, a game or image-based app, or is serving you hi-res photos.

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.

3G isn't nearly fast enough to make megabytes irrelevant.

One third of the US audience is not a "weird contingency"; it's basic awareness. Developing only for the highest of the high end is not good engineering. Get your head out of the cloud.

Those in that situation should probably start by optimizing the whole "frequently loaded" part... by not frequently loading it. Then they would realize this shaving of a few hundred bytes here and there is, indeed, micro-optimization.

And setting hard limits is the best way of ensuring that your bigger problems ARE elsewhere :)

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.

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.

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.

>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.

> 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.

"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.

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.

Reply on news.ycombinator.com