As a rule of thumb, you need to measure what s important for your application. If it s absolute precision then do it as an AJAX call because there may be rounding differences between browsers, computers and OS.

When I was developing a site for a company I was working for I had the same problem, however we manage to use the javascript part by using a clever twist by using only integer arithmetics.

Because we were dealing with currency with two digits, we multiplied everything by 10,000 and did the calculations. Rounding up to the integer and divided by 10,000 truncating the result to two decimal places.

That make the round-trips nicely and consistently between the browser and the server side.

Per the comp.lang.javascript FAQ, Javascript uses IEEE-754 and so it has a precision of 15-16 digits when doing floating point math. This should be enough for monetary operations, provided that you use the same rounding in Javascript that you do on the server side.

But if you need to be absolutely sure that it s correct on any and all browsers, an Ajax call would be the safest course of action.

If you re accepting orders, I would recommend that you always do the calculations on the server side before confirming the order to avoid someone maliciously tampering with data being sent from the client. That said, you could do the dynamic updating using JavaScript with some suitably worded disclaimer around the accuracy and then present the user with your server-side calculation before they confirm the order.

you should do it on the client side (I assume you have your client side validators in place) so that the user can see the total (I would hate if we make round trip calls to server to just see the total) and also do it on the server side .Reading off of the values from POST would not be a very good idea as someone with a HTTPProxy could change these values if you are picking it up from your HTTP POST.

TamperIE a tool to tamper with HTTP GET and POST and a sandbox where you can play around with

Edit: Yes, you can do the calculation in the server by making an AJAX call, but you would need to validate the total anyways (against the number of products + tax) when the user submits the order

Javascript isn t the best language to do math with. You ll find some math expressions that are true but return false in Javascript. Can t remember them exactly but I found out when I did a calculator once.

You can find out about the good and bad parts of Javascript here: http://www.crockford.com/

You should be using the back-end, in your case being Java, to do your strict calculations for there is no guarantee that the data won t be tampered by the end-user to their benefit. And once you have sent them a confirmation of the tampered price, you are in essence bound by the terms of your purchase contract, even if you know they ve tampered with the total price. There s no easy way you can prove they ve tampered with your code or calculations, and in-turn will be at a loss. Use the back-end, you ve got full control of that environment, any bugs or miscalculations from that angle can be blamed squarely on you.

Even though this is not a SO question (exchange is better place I guess), I would not use it in arithmetic calculations unless there is really requirement. If the decimals points are getting involved, the sirens are alarmed...

For instance, did you know that :

0.1 + 0.2 = 0.30000000000000004 

so if you actually check as 0.1 + 0.2 === 0.3 it will be false

Or here is the better one:

• typeof NaN is number NaN != NaN is true. BUT NaN !== NaN also true

And here is my favorite:

var i = 1;
i = i + ""; 
i + 1 //output will be "11" :) 
console.log(i);//output will be 1 
i - 1 = 0; // this part is the golden shot 

Even though I do not agree 100% with the following article, I would definitely suggest to read:

The Top 10 Things Wrong with JavaScript

It has really nice points.