A re-introduction to JavaScript

https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript

by hikz • 11 years ago

290 105 11 years ago

developer.mozilla.org

jongdubois• 11 years ago

I think there's no point trying to avoid memory leaks in older versions of IE. Circular references due to closures are too common and it's not worth messing with your code.

IE users are probably used to getting a horrible user experience anyway. I'm sure they can cope with a few browser freezes/crashes every once in a while - They know how to take a beating :p

drinchev• 11 years ago

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.

xtrumanx• 11 years ago

Can you expand on what you said about the `delete` keyword implications with the GC? I've never heard of that issue.

magicalist2• 11 years ago

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.

golergka• 11 years ago

Since you seem to have an understanding of what is wrong with it, care to tell about everything you know that should be updated?

frik• 11 years ago

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.

tracker17• 11 years ago

I worked on an extjs app for a company where most of the users at the time where IE6 corporate wide (this was several months after IE8 was available. That said, there were such horrible memory leaks with references just in the nature of the application under IE (component<->JS ties wouldn't unwind/gc) it would quickly eat up memory after about half a day of work would need to restart the browser...

In the end a lot of people using the application would either have to restart during the day, use portable Firefox, which many actually did. Of course, there are/where many worse things in practice dealing with supporting IE<9 for relatively modern web applications. I'd still rather deal with that, than the v4 browser days.

Roboprog3• 11 years ago

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.

efbbbf• 11 years ago

https://news.ycombinator.com/item?id=7169513

https://news.ycombinator.com/item?id=3569893

https://news.ycombinator.com/item?id=1524450

https://news.ycombinator.com/item?id=601967

Roodgorf• 11 years ago

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.

andrewpe• 11 years ago

I've only been here for a couple of months and this was nice to see.

serve_yay9• 11 years ago

Very nice to see it starts off with a (correct) discussion of JS types! JS devs mostly don't know the actual types in JS, which is pretty crazy if you think about it.

sergiotapia2• 11 years ago

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???

csandreasen• 11 years ago

I actually found the Javascript 'this' keyword more understandable after working with Python.

  >>> class foo():
  ...   def test(this, x):
  ...     print this, x
  ... 
  >>> x = foo()
  >>> x
  <__main__.foo instance at 0xb71928ac>
  >>> x.test(1)
  <__main__.foo instance at 0xb71928ac> 1
  >>> y = foo.test
  >>> y(1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unbound method test() must be called with foo instance as first argument (got int instance instead)
  >>> y(x,1)
  <__main__.foo instance at 0xb71928ac> 1

In Python, the reference to the current object is an explicitly declared parameter in the method definition, but the parameter is passed implicitly - the value of "this" is whatever is comes before the period when the method is called. If you call it in any other manner, it throws an unbound method error. Javascript is the same way, but instead of throwing an error it will instead pass 'window' implicitly. The equivalent code in Javascript:

  function foo() { }
  foo.prototype.test = function(x) {
    console.log(this, x);
  }
  var x = new foo();
  x.test(1); // prints VM1061:4 foo {test: function} 1
  var y = x.test;
  y(1); // prints VM1061:4 Window {top: Window, window: Window, …} 1

chris_wot9• 11 years ago

Especially when you need to do something like:

  var that = this;

serve_yay9• 11 years ago

I agree, `this` is a disaster. But, I just can't hardly think of another language where the people working in it mostly don't know the types. (Well, OK, PHP devs probably mostly don't)

And I don't just mean run-of-the-mill blub programmers who dabble in jQuery, I mean some of the best devs I've ever seen in any language. I had a self-proclaimed JS expert tell me that JS has integers and floats as distinct types. Even the people I work with every day who are fantastic did not know that function and array are not types.

Of course, things like `typeof` don't help the situation, so I don't put the blame squarely on programmers' shoulders. And obviously you can get a lot done without knowing that, technically, functions are just objects that can be called. But it still strikes me as kinda crazy.

buckbova• 11 years ago

http://bjorn.tipling.com/all-this

Good stuff here.

yulaow• 11 years ago

and 99% of those 99% problems can easily be solved with the correct use of .bind() or .apply().

lewisl9029• 11 years ago

Using jspm, SystemJS and Babel for my latest project, and simply using let universally over var and arrow functions over anonymous functions has made this aspect of JavaScript behave like any sane language would.

I simply don't ever need to think about it anymore.

PhineasRex• 11 years ago

"While often derided as a toy"

Javascript is not a toy; toys are fun.

serve_yay9• 11 years ago

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

ahoge3• 11 years ago

That's from IEEE 754 (a standard for floating-point arithmetic). `NaN` and -0 exist for the same reason.

yarrel• 11 years ago

I like JavaScript but that did make me laugh.

gildas• 11 years ago

You can also use the unary + operator to convert values to numbers:

    + "42"; // 42

> [...] However the "+" operator simply converts the string to NaN if there is any invalid character in it.

Being a bit pedantic here, why not recommending the Number function which may be less obscure for beginners?

    Number("42"); // 42

arcatek• 11 years ago

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"

Native constructors are ... fun beasts, to say the least.

serve_yay9• 11 years ago

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

ahoge3• 11 years ago

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

serve_yay9• 11 years ago

Since calling constructor functions without `new` is generally an error

The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new. In fact, in the case of String/Boolean/Number, calling them with new will often do something you don't expect. (Calling them with new gives you a Number/String/Boolean object, not primitive, which can cause trouble when you try to compare them with ===, unless you remember to use their `valueOf` method)

Also, as noted below, it's possible for objects to not have a `toString` method, so attempting to call it to get the object's value as a string could blow up. So it's actually safer to coerce to string by adding an empty string or passing to String().

bluesnowmonkey• 11 years ago

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

eddyb• 11 years ago

Bitwise operations don't produce Numbers (f64), but signed integers (i32).

Touche2• 11 years ago

It always yields an integer, so it's useful if you know you want an integer.

Bahamut• 11 years ago

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

amelius• 11 years ago

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

hajile• 11 years ago

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.

tracker17• 11 years ago

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).

kremlin2• 11 years ago

The article mentions an idiom for iterating over an array. It says 'an even nicer idiom is...' and then it shows it.

I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations

serve_yay9• 11 years ago

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.

kremlin2• 11 years ago

the problem with using it even when you don't have falsy values is that, eventually, you're going to forget that you can't use it when you do have falsy values. You're going to get too comfortable with it, and it's not general-purpose enough.

Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops

pluma3• 11 years ago

I think nearly every JS engine now optimizes `for (...;i < arr.length;...)` -- I'm nearly 100% sure V8 does and fairly certain Firefox's and ModernIE's do as well.

In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).

jaredsohn2• 11 years ago

old canard about caching the length of an array when iterating over it

I think there are still places where you need to do this (please correct me if wrong, or mention some other cases):

- when iterating over DOM nodelists in JS (why doesn't the browser cache this as well?)

- if using strlen in C/C++ (for the latter, you should use string.length() instead).

BinaryIdiot2• 11 years ago

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.

TazeTSchnitzel• 11 years ago

Is there even any guarantee it would be iterated in the correct order?

wwweston• 11 years ago

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.)

roryokane2• 11 years ago

I improved the wording:

“A nicer-looking but limited idiom is:”

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

snorrah• 11 years ago

The article says to watch out for 0.1 + 0.2 not exactly equalling 0.3 , so as a complete newbie to JavaScript, how do you work around this ?

Scarbutt2• 11 years ago

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

MichaelGG• 11 years ago

Well other languages often offer decimal, or higher precision floats, right?

EpicDavi• 11 years ago

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

The way to 'get around' this is to have a value (usually called an epsilon) that is relative in magnitude to the numbers being compared. In this example, a value like .00001 as epsilon should work fine.

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

In short, try to not put yourself in a situation where you have to compare equality with doubles.

jahewson2• 11 years ago

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);

Roboprog3• 11 years ago

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.

vorg• 11 years ago

Groovy is a heavily marketed programming language that uses BigDecimal, just like its sister dynamic languages Clojure, Rhino/Nashorn, and Xtend also do. Only Java actually ships BigDecimal.

kelvin0• 11 years ago

Rediscover Javascript, by using :TypeScript, CoffeeScript or Node.js and a gazillion of slightly incompatible web frameworks ... I wish DART had been there in the beginning.

ffn• 11 years ago

Whoa, the closure-based circular reference memory leak thing, is that just an IE issue or is that a language level (anti) feature? I need to know because I've very often done something like:

el$ = $('#whatever'); el$.click( function() { el$.find("a").css("color", "red"); } );

z3t4• 11 years ago

I think it's much easier to forget about "types" and think of objects instead. Trying to divide JavaScript objects into "types" will surely get you frustrated. If you absolutely want to check what "type" an object is, for example a sanity check for arguments passed to a function, you should make your own isMyType(obj) function and not rely on typeof or toString.

tracker17• 11 years ago

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.

Nican• 11 years ago

For the second example on the memory leak section (https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re...), wouldn't just changing "el.style" to "this.style" fix the memory leak?

ww520• 11 years ago

One caveat not mentioned is that while float is 64 bit floating point number, int is only 53 bit integer, unlike having 64 bit int in most other languages. Yeah, I've got bitten by this before causing a nasty bug.

thomasfoster962• 11 years ago

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.

tracker17• 11 years ago

The biggest gotchas with whole numbers in JS (IEE754 64-bit floats) is that in JS all bitwise operations are performed on a 32-bit integer under the hood... in practice this means you can do a bitwise operation on anything and it will be coerced into a 32-bit integer, either first via the parseInt(X,10) path, or becomes an empty 0 value.

It really isn't unique to JS, and there are several bignum libraries that can/will help.

deathanatos• 11 years ago

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.

dorfsmay• 11 years ago

This is a really good overview.

Along the same line but more in depth, I really like Cody Lindley's JavaScript Enlightenment:

http://www.javascriptenlightenment.com/

anon3_• 11 years ago

Cool. Did Brendan Eich write it? What's he doing these days?

Keep up the good work Mozilla.

edit: I see MANY people contributed! You can too! https://developer.mozilla.org/en-US/docs/Mozilla/Connect. It still would be cool if Eich could act as an "editor" to JS related articles!

philbo• 11 years ago

"JavaScript is an object oriented..."

No it isn't. It has support for OO and you can choose to write code object-oriented if you wish. But equally you can disregard the OO bit quite happily and compose behaviour using closures instead.

None of my favourite JS libs are OO, it's a poor abstraction imho.

totony• 11 years ago

I wish there were more tutorials of this style, for people who are already familiar with programming and just want to know how a language works.

A re-introduction to JavaScript

Related Stories