How fast is client side javascript versus server side Java?

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.

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.

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.