In some cases, doing things client side is massively faster, and in other cases it isn't. It's something that teams need to look at case by case.

For example, over a small data-set, doing typeahead search on about 5000 elements was many times faster, even on some of the slowest hardware than doing it server side.

Alternatively, I could suggest that CPU is cheaper than bandwidth, especially on mobile, so not sending a full html document with every request and just sending the required data and updating via JS makes much more sense for mobile.

Although this article is mostly about javascript on the server, and so isn't focussing on the fat js sites that you are talking about.

Bandwidth is a deferred cost. CPU is an immediate cost (on a mobile device).

When you run a CPU-sucking stie on your device, you typically know exactly which site or app is the culprit - you can watch your battery drop and feel your CPU heat up.

When you get your bill at the end of the month, it's a lot less clear why, exactly, that happened. And - fairly or not - it's a lot less likely to be blamed on a lightweight site that grabs extra data.

Not that these two things should be mutually exclusive anyway: an app designed for mobile will do most of its processing on the server with short bursts on the client, and ALSO be optimized for data on the server side. (The server, after all, typically knows what kind of client it's serving.)

Moving more responsibility to the client can let you be a lot smarter and more selective about the data you request from the server, though.

So yeah -- you might have more JS, which will eat some CPU cycles, but you can save yourself from having to request a lot of duplicate data. So, smaller request sizes and if you do it right, fewer requests. The less you can bother the radio, the better.

It would be interesting to try a solution where Node.js incorporates itself either on the client side or the server side depending on the device. Or even putting Node on both sides and "load balancing" depending on processing power.

I'm also really interested in seeing how feasible it would be to push all Javascript to the server and basically letting the client act as a dummy terminal that sends and receives Javascript snippets through a WebSockets connection (which is more mobile-friendly than AJAX since some mobile users pay per TCP connection). I would expect that latency would result in an overall slower app, but maybe some client side-heavy apps could benefit from it.

There are projects to do exactly this... LinkedIn for example does this for mobile vs. desktop rendering... so they can share the same rendering templates and logic.

Discourse has run into a pretty nasty performance issue on Android lately [0]. It would be too strong of a critique to say they are already having the problem you mentioned, but surely if they shipped this as a finished problem and had this issue it would be a big deal. It doesn't appear to be a fundamental problem with their codebase, as the video comparisons to iOS show that it runs reasonably smoothly there. This shows that JavaScript performance on mobile has a ways to go yet.

[0] http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

From that same thread, the issue isn't with Ember, it's with V8. Ember itself is looking for a workaround to the issue.

http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

> the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake.

I've been thinking about that as well and was playing this N2O framework: http://synrc.com/framework/web/ they are sort of making this point as well, render on the server and send html to client but do it via a websocket. That is an interesting approach.

The advantage with JavaScript is that you can run the same rendering code on the backend for static pre-rendering as you can on the front end.

NodeJS is async by default and RAD. Does it really scale at the corporate level ? depends on what is your product. If you are better off with the JVM or .net , there is no reason to use it. But in my opinion , it definetly has its place in startups.

The concern I express isn't with Node; it's with the front end tools like Angular that shift the cost of building UI scaffolding to the client side javascript engine.

The potential with Node is that you could have the best of both worlds, using the same code to render on client and server depending on which would provide the best experience given the current hardware and connection capacity. (Edit: it looks like Rendr and Derbyjs are starting to realize this potential)