var s= "11.";
var i = parseInt(s, 10);
var f = parseFloat(s);

s = (i == f ? i : f) + "";

Or maybe

s = (f % 1 ? f : s) + "";

--
if (Math.floor(parseFloat("10.5")) == parseFloat("10.5")) Math.floor
(parseFloat("10.5")).toString(); else parseFloat("10.5").toString();
"10.5"
--
if (Math.floor(parseFloat("10.")) == parseFloat("10.")) Math.floor
(parseFloat("10.")).toString(); else parseFloat("10.").toString();
"10"
--
if (Math.floor(parseFloat("10")) == parseFloat("10")) Math.floor
(parseFloat("10")).toString(); else parseFloat("10").toString();
"10"

So assuming you're starting with a numeric value written as a string, and
you want to end up with a numeric value written as a string, something
like the following might work:

x = parseFloat( myString );

if ( Math.floor( x ) == x )
        myString = Math.floor( x ).toString();
else
        myString = x.toString();

Rgds

======================

This will also replace trailing 0's in 11.02000

n = n.replace(/(\.\d*[1-9])0+/,'$1').replace(/\.0*/,'');

n = n.replace(/\.0*$/,'');

n = n.replace(/(\.\d*[1-9])0+$/,'$1').replace(/\.0*$/,'');

myNumber = +myString; // convert string to numeric value
myString = "" + myNumber; // convert numeric value back to string, if at
all necessary

myString = Number(myString);

if it needs to be a string:

myString = String(Number(myString));

window.alert(parseFloat("11."));
window.alert(parseFloat("11.0"));
window.alert(parseFloat("11.00"));
window.alert(parseFloat("11.000"));
window.alert(parseFloat("11.0000"));

"11" was always returned ie. if the decimal part of the number is "zero"
then its not preserved.

But remember that JavaScript numbers are floats, so do that after
rounding to the desired resolution.

IMHO, it is better practice to represent all numbers of a "set" with the
same number of decimal places, and never to have a decimal point which
is not surrounded by digits.

See the book described in <http://www.iupap.org/commissions/c2/redbook/>
- in my printed 1987 copy, it is section 1.3.2.

<http://fias.uni-frankfurt.de/~hees/tmp/iupap-symbols-typography.pdf>
appears to be a copy of a similar but slightly different document; but
its 1.3.2 matches.

  s = parseFloat(s) + "";

is sufficient [although I would prefer String(parseFloat(s)) or skip the
explicit conversion altogether], and you can skip the variable declarations
and initializations for `i' and `f'.

Number(myString) will return NaN if there are any non-digits and non-dots in
myString, ignoring leading whitespace.  It will parse (the value of)
`myString' as a hexadecimal number if it starts (after leading whitespace)
with `0x', and will return NaN if there are any non-hexadecimal digits in
the string (including the decimal point).  It will _not_ convert `myString'
to String if it is not one.

+myString will do the same as Number(myString).  The "Unary +" operator was
introduced in the first Edition (1997) as was `Number', but it was not
implemented before JavaScript 1.3 (1998) and JScript 3.1.3510 (1999).  
(CAVEAT: Per older, non-scientific research.  My current, overall more
complete research [not yet online] did not include those implementations
because of backwards compatibility issues; but I intend to fix that.)

parseInt(myString) will first convert `myString' to String(!) before parsing
it as a number of unspecified base.  The base is determined by the first
leading non-whitespace sequence: if it is `0x', the base is 16
(hexadecimal), in older implementations (of Edition 3 and before) if it is
`0' the base would be 8 (octal; in Ed. 2 mandatory, in Ed. 3 implementation-
dependent), otherwise 10 (decimal).  It will stop parsing before the first
character that it cannot interpret according to the determined base.  For
those reasons, parseInt() should not be called like this.

parseInt(myString, base) will first convert `myString' to String before
parsing it as a number of the specified base, while ignoring `0x' (after
leading whitespace) if base == 16.  It will only return NaN if no digits
could be found before the first non-digit (ignoring leading whitespace).

parseFloat(myString) will first convert `myString' to String before parsing
it as a decimal number, and it will return NaN if that is not possible.  
Leading whitespace will be ignored.  (The built-in parseFloat() cannot parse
non-decimal fractions; see jsx.math.parseFloat() for that.)

Therefore, parseFloat(myString) is probably the best solution here.

The forced conversion of the argument value to String is also important
because the string representation of Number values is implementation-
dependent.  Thus,

  parseFloat(n) === n

is not necessarily true for all Number values `n'.

var myString = "33a";
window.alert(Number(myString)); // alerts NaN

myString = "3 3";
window.alert(Number(myString)); // alerts NaN

myString = "33-";
window.alert(Number(myString)); // alerts NaN

myString = "  33";
window.alert(Number(myString)); // alerts 3

myString = "33  ";
window.alert(Number(myString)); // alerts 3

You have conveniently snipped the part of my posting that qualified this
statement (without marking the omission).  You really are to be pitied if
you think have to resort to such lame tricks to get attention.

However, without further qualification "digit" is commonly understood,
indeed, to be limited to those ten symbols which in Europe evolved from
Arabic writing (through Al-Khwārizmī, ca. 780-850 CE), but originated in
India (the digit and number zero in particular, probably starting from
Aryabhata ca. 476–550 CE going back to Jain mathematics ca. 400 BCE; BTW,
there was a fascinating BBC documentation about this years ago – I have
forgotten the title).

The latter is what I meant here.  (The following sentences of my posting did
expand on possible exceptions for hexadecimal digits with Number(…).)

HTH

FWIW: I've noticed a /minor/ (as it's not related to the OP's question)
omission in your explanations: all(?) of the conversion routines will
recognize a leading sign (+/-) and will ignore trailing whitespace.

Actually, Number(" -0x20 "), Number(" +0x20 "), +" -0x20 ", and +" +0x20 "
all result in NaN, while Number(" 0x20 ") and +" 0x20 " both result in 32,
parseInt(" -0x20 ", 16) returns -32, and parseInt(" +0x20 ", 16) returns 32
(with and without specified base) in Chromium 22.0.1229.94 on GNU/Linux.

That complies with ECMAScript Ed. 5.1, sections 9.3.1 and 15.1.2.2, and the
following relevant productions in the former:

| StringNumericLiteral :::
|   StrWhiteSpace_opt
|   StrWhiteSpace_opt StrNumericLiteral StrWhiteSpace_opt
|
| […]
|
| StrNumericLiteral :::
|   StrDecimalLiteral
|   HexIntegerLiteral
|
| […]
|
| HexIntegerLiteral :::
|   0x HexDigit
|   0X HexDigit
|   HexIntegerLiteral HexDigit
|
| HexDigit ::: one of
|   0 1 2 3 4 5 6 7 8 9 a b c d e f A B C D E F

As for the trailing whitespace, though, for parseInt() and parseFloat() that
is already covered by the explanation that parsing stops before the first
character that does not belong to the determined or specified numeric
literal [§15.1.2.2, 11.; §15.1.2.3, 4.].

But I must apologise; it was at least _quadruply_ untrue.

Who can list four or more distinct cases in which Number(myString) will
**NOT** return NaN although there are non-(digits or dots) in myString,
ignoring leading and trailing whitespace?

Using anything other conversion, except where necessary, is either mere
bloat or pandering to uninformed and unintelligent readers.

Newbies should note that is often unwise to use ANY of those methods on
a string directly typed in to a control without first checking the
format of the string with a Regular Expression; and that, after suitable
checking and in ordinary circumstances, any of the methods will work
well.