A re-introduction to JavaScript

The reason this is mentioned (and things like the part about caching array length in your for loop) is that this tutorial was mostly written back in 2006, when things were obviously a bit different with JavaScript.

The article has gotten updates since then (check the history), but not many and not to the extent it probably needs. Not sure why it keeps getting linked.

There's definitely no point to avoid them for IE. The point as I see it is that it should be avoided for every browser.

Indeed IE's users are having terrible experience anyway, but let's just don't push FF and Chrome to their memory limits, just because we don't care with our code.

One of the best parts when I develop client-side web-apps is the debugging and looking close what the garbage collector is doing. For example : I usually don't use `delete` keyword, since I know it might create a node that GC's can't clear.

It was very important for IE <=6. Early AJAX web apps like GMail ~2004 were quite hard to get right - avoid most memory JS leaks or the memory consumption got out of hand too fast. That was in the days of 512 MB memory and WinXP.

I was stunned when I read the part about hooking the "this page is done now, let's go to another" event to manually clean up memory. (Old) IE worse than failure, indeed.

I like JavaScript but that did make me laugh.

What could be more fun than a language that says the result of dividing by 0 is "Infinity"? It's a hoot!!

Yeah and not a big fan of them saying you can do for...in on an array while casually mentioning the limitation of doing such. I would consider it far better practice to NEVER iterating over an array with for...in.

Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away.

Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I've personally never seen it in the wild.

Also seems weird that they don't mention `forEach`.

(Sure, IE<9 is a caveat, but all the Array iteration methods are the easiest things to shim and if you're targeting below IE9 chances are pretty good it's not the first shim you'd be using.)

I improved the wording:

“A nicer-looking but limited idiom is:”

MDN documentation is on a wiki. You can just edit the page.

These are all roughly a year apart and it's a very interesting article. I don't really see a big problem with reposts that far apart to catch newcomers' eye.

I think 99% of the problems people have with Javascript are not actually types, but `this`.

It's the most confusing part about Javascript. This context, var foo scope, what? Why is this value not updating? undefined? What???

If you use a double NOT ~~"foo" you will always get a finite int32 value... which is useful when you can use 0 as a "default" representation. For that matter, all bitwise operations will coerce a value to an int32 representation. Which is something to be aware of, if you want larger integer values (< 2^53 - 1 and > -2^53 + 1).

Number() also converts to NaN if it's not a number though I would still avoid the + operator here because it is code smell (looks like you forgot your variable to concat).

Number automatically accepts exponent notation and auto-converts to hex (ignoring octal). parseInt() auto-converts hex and octal unless a radix is specified, but it also ignores the remaining non-number characters at the end of the string.

There isn't a single method that does whatever you want.

the String function is also a nice way to cast a value to a string (using .toString() is unsafe because it may not exist, such as with undefined and null): String(42) === "42".

An other thing that could maybe be covered is this specifity:

    typeof "42" === "string"
    typeof String(42) === "string"
    typeof new String(42) === "object"

Another way to cast to a Number is the bitwise-or operator. It has the useful property of always yielding a number.

    '42' | 0;      // 42
    NaN | 0;       // 0
    null | 0;      // 0
    undefined | 0; // 0
    false | 0;     // 0
    true | 0;      // 1

Correct me if I'm wrong, but I thought that the unary operator and the Number constructor yield equivalent results?

Since calling constructor functions without `new` is generally an error, I'd rather use `parseFloat`.

Yes, that's a good suggestion. Boolean works as well, for coercing to boolean of course.

Because Number(...) uses more bytes on the wire.

I think if you simply accept that there is no spoon, and that any utensil can be coerced and used as a spoon you will be much happier.

In general, the only niggle is when you want a discrete integer value, where zero is an acceptable input, or a string that represents a number coerced into a number.. but anything else to be null. You have to single out falsy values that aren't zero in this case.

Other than that one niggle in practice, I've come to truly appreciate the expressive nature that JS actually offers in practice. The additional concepts added in terms of ES6 and ES7 are pretty welcome. Though in practice, I've moved very far away from trying to apply many OO patterns of classes, inheritance, etc in favor of basic object instances, and functions that can be combined/composed.

It's pretty nifty all around.

This is not a huge problem as if you are outputting the floating point number, you would probably want to round it anyways. The biggest 'gotcha' is when doing equality comparisons between these numbers.

Consider the following:

    .1 + .2 == .3 // false

Anyways, all you have to do is check if the absolute difference of the numbers is less than the epsilon:

    var a = .1 + .2, b = .3, epsilon = .00001;
    console.log(Math.abs(a-b)<epsilon); // true

Floating point numbers in any language are inaccurate, if you're performing say, financial calculations then you can use fixed point numbers by using scaled integers. For example:

    var SCALE = 100; // 0.01
    
    var a = 0+1 * SCALE;  // e.g. 2.5 would be 2+5 * SCALE
    var b = 0+2 * SCALE;
    
    if (a + b == 0+3 * SCALE) {
      // this will work...
    }

    console.log(a / SCALE);

Is not a JS only thing, investigate how floating point values work.

See if there is a fixed precision arithmetic library for JS? (similar to BigDecimal in Java / Groovy)

Homework: 1) Google for such; 2) see which one doesn't suck.

There is no "int" or "float" (mostly[1]) — there is only Number, which is an IEEE floating point. A literal `1` is a floating point that happens to be precisely representing an integer. "53 bits" happens to be the limit of consecutive integers that you can store in an IEEE double.

[1]: 32-bit integers show up under the hood, in expressions such as `5000000000|0`. Both 0 and 5000000000 are precisely represented in JS's Number type, but you cannot (correctly) take a binary OR of the two.

As far as I know 53-bit integers are a bit haphazard in JavaScript - it's best to stick to 32-bit unless you really know what you're doing.