How fast is client side javascript versus server side Java?

Question

I am wondering how fast client side Javascript is compared to server side Java in terms of raw computational power.

For instance, sorting. Should it all be done server side if possible? And how about iterating through a collection?

Moe

In addition to everything mentioned below (server vs. client resources, compiled byte-code in a VM vs. an interpreted script, etc... ) - JavaScript speed is browser dependent. – Confluence

I note that Facebook has shifted work onto their [massive] server farms from JavaScript in order to increase performance. – Pelecypod

Answer 1

The answer is very complex and depends on each specific situation.

A server is generally going to be orders of magnitude more powerful than a client machine; and managed code is generally much faster than scripting.

However - the client machine also usually has a lot of spare computational power that isn't being used, while the server could be running requests for thousands of users. So in that case much of the work that can be offloaded to the client is preferable.

You must understand the needs and expectations of your users for each individual piece of functionality in your application and look at the relative load versus development cost for your organization to split development between two environments and figure out what works best. For example, your users probably expect that your site does not freeze their browser or cause unfortunate "this web page is eating your computer" dialogs, so your client scripts should be written intelligently. That's not to say you can't do a ton of work on the client (you can), you just have to be smart about how you do it and remember it blocks the UI thread.

Arlo

You also must be careful about how much you offload to the client... you don't want to get that pesky browser pop up that says "This script is taking too long... Continue/Stop Script" – Healall

There is also the issue of postbacks. Anything you do server-side will require a postback, which will reload at least part of the page. That takes a round trip to the server and can cause your user to lose where they were on the screen (which is generally annoying to users filling in a form or viewing a long page). If you can do it client-side, this is not an issue; you can mitigate behavioral problems with AJAX, but you can still run into some loss of browser position. And of course, if your operation requires server-side resources like the DB, the op simply must be handled server-side. – Dryfoos

Answer 2

Server side Java will certainly run much faster, you'll need to benchmark for your particular case but you're probably looking at a 10-20x speed advantage.

However that probably doesn't matter much: regardless of raw computational power I would still recommend trying to do as much calculation as possible client side in Javascript for the following reasons:

• Even 20x slower is still likely to be unnoticeable to the user
• When you factor in the latency of client to server communications, doing it locally on the client will almost certainly be more responsive to the user
• Client machines are probably not CPU-bound, so executing some additional code on them is effectively free
• If you can offload work from the server to the client, you will need less server side infrastructure, which can get expensive when you need to start scaling up
• Having lots of client to server communications is likely to complicate your architecture and make it harder to develop new functionality in the future.
• Doing calculations on the client can often reduce bandwidth requirements

There are of course good reasons to keep things on the server e.g.:

• Security implications (if client can't be trusted)
• Very large data set needed (would take too long to download to client)
• Need to exploit massively parallel calculations (e.g. for Google search)
• Avoid need to allow for differences in clients (e.g. Javascript versions)

But if these don't apply then I would try to push things to the client as much as possible.

Dogie

+1 Good Answer. You can add to the advantage server list - Don't worry so much about which version of JavaScript the client's browser supports. – Illfounded

If there's a 10x-20x speed advantage, then wouldn't that make up for whatever latency there is between sending the data to the client in a lot of cases? – Primp

Network latency tends to be much longer than most computations. If a complex calculation takes 20ms (JS) vs 1ms (Java), and the the network round trip is 200ms, it is still much quicker to do it in the client (20ms) than send to server and wait for result (201ms) – Dogie

Answer 3

The big difference here is not the speed of the VMs. The difference is that a single server has to serve dozens or hundreds of clients. Another factor: round trips to the server add a lot of overhead, so you want to minimize them.

Basically, anything that's not security-critical and can be done on the client easily, should be done on the client.

Unimpeachable

Answer 4

These two things cannot be compared side-by-side.

There are far too many factors, and the languages are far too different, and serve far too different purposes to effectively compare their speed.

You really need to decide where you do your calculations on a case-by-case basis.

If the client machine is required to do too much work, it will degrade the performance of the app, but if the server is asked to do too much, it can slow down the response time for everybody.

Dosser

Answer 5

Javascript is way fast enough to do sorting of data on the client. I have used it with datasets of 5,000 rows, 11 fields per row and used that to sort tables on the client (with pagination). These sorts used compare functions so that it would sort the rows by field and datatype. The actual Javascript part of the process took something on the order of the high tens of milliseconds (~80 if I recall).

I would rather push that kind of mundane task down to the client any day rather than clog up a very busy server with it. YMMV.

Balance

Answer 6

Don't mixup Java with Javascript - the name is similar but they are completely different languages. Javascript is a client side, interpreted language, Java is a byte-code language running inside a virtual machine, with much more optimization for handling large data. As of the fact, that servers running Java services are normally have much more power (faster CPUs and disk-I/O, more RAM) computing on Java is always faster on my experience. Javascript can be used on client-side if you want to compute small datas (like sorting just a few hundred elements).

All in all you will have to decide which way is faster: compute and prepare the data on a server and transmit them to the client (where the transmit via internet is the by far biggest slowdown reason), or to compute the data already on the client-side via javascript.

My suggestion is: if there are none of the data you want on client-side are already on client-side it is meaningful to compute them on the server and transmit the already prepared data to the client. But if the data is already on the client-side and they are not more than a few hundred the better user-experience is to compute them in the user's browser.

Pinta

Answer 7

It really depends on the boxes you are running the code, how big the data is and the availability to work with the process and other factors, plus you have to think sending data through the wire that it's expensive. You have to balance what you gonna do with that and if it's better to spend more time processing things before and let the resources free for the heavy stuff, and playing sending back and forth data.

Increase

Answer 8

There is not an specific answer. It depends on the power of your client and the size of the computation. Is it a smart watch, a smart phone? If you can't guarantee the power of your client, I would leave the computation to the server.

Kassey