12 ms·

This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption a

This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption are still a pretty big deal in the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very optimized echo chamber. Users will be found elsewhere dealing with products that are faster (for them) and teams clamoring for how they can continue to improve the experience with each iteration.

jeffasinger 13y ago
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.
rdtsc 13y ago
> 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/ 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.
camus 13y ago
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.
- ChikkaChiChi 13y ago
  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.
  - svachalek 13y ago
    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)
dmunoz 13y ago
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-android/ http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...
- nathanhammond 13y ago
  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-android/8823/41 http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...
kevincennis 13y ago
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.
bencoder 13y ago
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.
- GrinningFool 13y ago
  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.)
rmrfrmrf 13y ago
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.
- tracker1 13y ago
  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.
ilaksh 13y ago
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.

jeffasinger 13y ago

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.

rdtsc 13y ago

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

camus 13y ago

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.

ChikkaChiChi 13y ago
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.
- svachalek 13y ago
  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)

dmunoz 13y ago

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-android/ http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

nathanhammond 13y ago
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-android/8823/41 http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

kevincennis 13y ago

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.

bencoder 13y ago

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.

GrinningFool 13y ago
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.)

rmrfrmrf 13y ago

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.

tracker1 13y ago
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.

ilaksh 13y ago

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.