Poor Design
Every script is executed in a single global namespace that is accessible in browsers with the window object.
Camel case sucks:
XMLHttpRequest
HTMLHRElement
Automatic type conversion between strings and numbers, combined with '+' overloaded to mean concatenation and addition. This creates very counterintuitive effects if you accidentally convert a number to a string:
var i = 1;
// some code
i = i + ""; // oops!
// some more code
i + 1; // evaluates to the String '11'
i - 1; // evaluates to the Number 0
The automatic type conversion of the + function also leads to the intuitive effect that += 1 is different then the ++ operator:
var j = "1";
j++; // j becomes 2
var k = "1";
k += 1; // k becomes "11"
The var statement uses function scope rather than block scope, which is a completely unintuitive behavior. You may want to use let instead.
Type System
JavaScript puts the world into a neat prototype hierarchy with Object at the top. In reality values do not fit into a neat hierarchy.
It is costly to navigate through __proto__, so prototypal inheritance is problematic.
You can't inherit from Array or other builtin objects very easily. The syntax for prototypal inheritance also tends to be very cryptic and unusual.
In JavaScript, prototype-based inheritance sucks: functions set in the prototype cannot access arguments and local variables in the constructor, which means that those "public methods" cannot access "private fields". There is little or no reason for a function to be a method if it can't access private fields.
JavaScript doesn't support hashes or dictionaries. You can treat objects like them, however, Objects inherit properties from __proto__ which causes problems.
JavaScript doesn't have real arrays. Instead JavaScript just has objects.
typeof [1, 2, 3, 4, 5] === "object"
Arguments is not an Array. You can convert it to one with slice:
var args = Array.prototype.slice.call(arguments);
The number type has precision problems.
0.1 + 0.2 === 0.30000000000000004;
(However, the problem is not the result, which is expected, but the choice of using floating point number to represent numbers, and this is a lazy language designer choice. See
http://www.math.umd.edu/~jkolesar/mait613/floating_point_math.pdf ).
NaN stands for not a number, yet it is a number.
typeof NaN === "number"
// To make matters worse NaN doesn't equal itself
NaN != NaN
NaN !== NaN
// This checks if x is NaN
x !== x
(Which is as it should be, as per IEEE754. Again, the problem is the indiscriminate choice of IEEE754 by the language designer or implementor.)
Bad Features
(You can bypass many of these bad features by using
http://www.jslint.com/)
JavaScript inherits many bad features from C, including switch fallthrough, the use of = for both assignment and equality, and the position sensitive ++ and -- operators. See C sucks below.
JavaScript inherits a cryptic and problematic regular expression syntax from Perl.
Semi colon insertion
// This doesn't work properly
return
{
"a": 5
};
Implied globals:
function bar() {
// Oops I left off the var keyword, now I have a global variable
foo = 5;
}
The == operator sucks
0 == ""
0 == "0"
0 == " \t\r\n "
"0" == false
null == undefined
"" != "0"
false != "false"
false != undefined
false != null
The bitwise operators (& | ^ ~ << >> >>>) are inefficient because they convert their operands to floating point and then back.
Typed wrappers suck:
new Function("x", "y", "return x + y");
new Array(1, 2, 3, 4, 5);
new Object({"a": 5});
new Boolean(true);
parseInt has a really weird default behavior so you are generally forced into adding that you want your radix to be 10:
parseInt("72", 10);
The with statement sucks because it is error-prone.
with (obj) {
foo = 1;
bar = 2;
}
The for in statement loops through members inherited through the prototype chain, so you generally have to wrap it in a long call to object.hasOwnProperty(name).
for (var name in object) {
if (object.hasOwnProperty(name)) {
/* ... */
}
}
There aren't numeric arrays, only objects with properties, and those properties are named with text strings; as a consequence, the for-in loop sucks when done on pseudo-numeric arrays because the iterating variable is actually a string, not a number (this makes integer additions difficult as you have to manually parseInt the iterating variable at each iteration).
var n = 0;
for (var i in [3, 'hello world', false, 1.5]) {
i = parseInt(i); // output is wrong without this cumbersome line
alert(i + n);
}
There are also many deprecated features (see
https://developer.mozilla.org/en/JavaScript/Reference/Deprecated_Features) such as getYear and setYear on Date objects.
Missing Features
There should be some means of enforcing immutability. Your best bet is the const statement which is non-standard, non-cross browser, and specific to Mozilla. This statement, also doesn't work for JavaScript's most important datatype: objects.
// It works okay for numbers and strings
const pi = 3.14159265358;
const msg = "Hello World";
// It doesn't work for objects
const bar = {"a": 5, "b": 6};
const foo = [1, 2, 3, 4, 5];
// You also can't easily make your parameters constant
const func = function() {
const x = arguments[0], y = arguments[1];
return x + y;
};
There should be a more convenient means of writing functions that includes implicit return, especially when you are using functional programming features such as map, filter, and reduce.
// JavaScript 1.8 introduces a somewhat nicer function syntax with implicit return:
function(x) x * x
There is still no particularly good means of looping, so you continue to see staments like these:
for (var i = 0, l = arr.length; i < l; i++) {}
You still have to manually perform type checking:
function substr(str, start, end) {
if (arguments.length !== 3) {
throw new Error();
}
if (typeof str !== "string" || typeof start !== "number" || typeof end !== "number") {
throw new TypeError();
}
}
Considering the importance of exponentiation in mathematics, Math.pow should really be an infix operator such as ** rather than a function.
Math.pow(7, 2); // 49
no Math.sign or Math.signum function.
DOM
Browser incompatibilities between Firefox, Internet Explorer, Opera, Google Chrome, Safari, Konqueror, etc make dealing with the DOM a pain.
If you have an event handler that calls alert(), it always cancels the event, regardless of whether you want to cancel the event or not
// This event handler lets the event propagate
function doNothingWithEvent(event) {
return true;
}
// This event handler cancels propagation
function doNothingWithEvent(event) {
alert('screwing everything up');
return true;
}