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.

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.

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.

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.

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.

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

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

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.