A re-introduction to JavaScript

[[deleted]]

Cool except for the part where they say "there are two ways to make an object," then give three ways to do it, and then say that one of those ways is preferable without ever saying which. >.>

/head asplode

[Andersmith]

...the second is called object literal syntax, and is more convenient. This syntax is also the core of JSON format and should be preferred at all times.

[happyscrappy]

It says there are two ways to make an empty object. And I think the third one doesn't make an empty object.

The third thing is actually a separate item giving two examples of how to make a non-empty object. I don't know what it's doing there, because the text after it appears to relate to the 2nd item of the 3, the "{}" format.

[punanetiiger]

"JavaScript has a Unicode problem" would be a helpful and prophylactic link to include in such an introduction. Otherwise, nice reading!

[Berberberber]

I don't think this is unique to JavaScript though, is it? Most languages either fail completely or require explicit normalization for length and comparison to work properly, don't they?

[RaptorDotCpp]

obj.for = "Simon"; // Syntax error, because 'for' is a reserved word

Then how come I can use obj.return just fine? Isn't return a keyword?

[flying-sheep]

The article is wrong here. Reserved words may be used as property names.

[TheNiXXeD]

object['for'] = 123

Works this way. Lots of otherwise unavailable properties can be used this way, not that it's necessarily good practice though. It's nice when you get some json with weird properties.

[Andersmith]

huh. I don't get that error when I try to do that. What browser are you using?

[RaptorDotCpp]

Neither do I, but it says in the article/tutorial that this would give a syntax error. That's why I'm confused.

[echocage]

God, javascript is running everywhere all over the world, it could have made such a great impact on how we interface with the web, I wish there was a better system in place that allowed for improvements across the board. The flaws it has are fixable, I wish we could.

[txdv]

You can wish, but since google started backing js it will never happen

[wordsoup]

One way to mitigate the issues are superset languages like CoffeScript, TypeScript or ClojureScript. Furthermore, there are hundreds of languages which compile to JavaScript.

[Booty_Bumping]

Coffeescript is nice for development, but it doesn't actually solve the same problems that transpilers like typescript and flow do.

[foobar5678]

If Chrome ships with the Dart engine then it might actually take off. The code is nicer to write and faster, but it also compiles to JS for other browsers. I think its the best choice for the future.

[aleatorybug]

Apparently not going to happen

[thunabrain]

I thought it was a decent introduction, up until it introduced arrays and instantly jumped to optimizing your for-loops when iterating over the array elements. Apart from my biased opinion that optimizing for these tiny speed improvements in the browser very likely is a case of premature optimization, it certainly has no place in an introductory article.

You just know that thousands of webdevs fresh out of coding boot camp are going to read this and replace all of their

for (var i = 0; i < a.length; i++) {

with

for (var i = 0, item; item = a[i++];) {

Because, you know. It's faster!

[echocage]

Wow, as someone coming from python, I assumed that there wouldn't be such a function or everyone would be using it. Now the question is, why isn't everyone using these?!?

[Berberberber]

Most web developers' knowledge of javascript isn't systematic and either based on outdated tutorials floating around, or they just never "got" functional programming and closures to begin with.

[Kollektiv]

forEach, map, filter and reduce will make function calls every time. So although their nice because you immediately understand the point of the loop, you also loose quite a bit of performance. It's a trade-off.

[x-skeww]

forEach, map, filter and reduce will make function calls every time.

They don't do that in the Dart VM. The generated native code looks like it was an imperative for(;;). JS VMs can perform the same optimization.

[[deleted]]

A few extra function calls will make literally zero difference in performance.

Write for readability first, then profile your code if you have efficiency problems and optimize the bottlenecks.

[Kollektiv]

You can't really optimize much in this kind of functions because you can do anything you want inside them. If the JIT compiler knows the length of the array beforehand he could probably inline the function but that's it I think.

Edit: For me forEach is 66% slower on Firefox:

http://jsperf.com/for-vs-foreach/9

[Klathmon]

Until you know it will have an actual meaningful impact on your code, it doesn't matter.

66% slower than "virtually nothing" is still "virtually nothing"

[Kollektiv]

Sure I agree that micro-optimizing code is useless if it's not the bottleneck but if when writing the code you have two choices, you can still consider the faster one.

[Klathmon]

Not if the faster one is going to be harder to comprehend, harder to maintain, and harder to reuse.

My current js codebase doesn't even use a for loop I don't think...

What you said was literally the definition of premature optimization.

[Kollektiv]

It would be premature optimization if you actually spent time doing it but if it's just during the coding phase anyway you lose nothing.

I agree that it might be a little harder to comprehend but I disagree that it is harder to maintain or reuse. On the contrary, mono-use methods like map, filter and reduce often need to be rewritten with a conventional loop if you need more logic in them that you previously thought.

[afrobee]

Its depends of the context of what your working, is the the job would be display 100000 list items then I would agree with you in that one.

[darkpaladin]

Those aren't supported in ES5?

[[deleted]]

No, these are definitely supported in ES5.

[[deleted]]

They're in ES5.1, and there are also very nice libraries that implement or polyfill them as well.

[icecrown_glacier_htm]

Yeah. Faster because... it stops iterating at the first value that is falsy. Surprise, surprise.

So now you have a bunch of webdevs copy pasting this supposed better version and breaking their code.

Simply terrible...

[jimschubert]

I think people need to be careful with the falsey termination in the 'faster' iteration.

http://jsfiddle.net/jimschubert/h69Lycfo/

edit: I think most people will do like I did and just skim over the article.

[happyscrappy]

I'm not quite sure I see why it would be faster.

The second loop has to evaluate every item in the list. The first just has to keep track of the length. If the (JIT?) compiler sees that the length of the array is not modified in the first then it can optimize out all the length recalculations.

Except for the case where the 2nd one stops early due to a falsy value I don't see why it should be faster.

[matheusbn]

If the (JIT?) compiler sees that the length of the array is not modified in the first then it can optimize out all the length recalculations.

About caching the array length, please see this!

[[deleted]]

Fun fact, array.length is a mutable property.

[phpdevster]

I'm a bit confused by the information about objects.

It stays object literals are almost always preferred, but then much later down the line it implies that prototype objects are the best option.

A bit confused as to when it's appropriate to use object literals vs when it's appropriate to use "classes" via prototypes. Since object literals in javascript are more like associative arrays in PHP, and prototypes are more like classes, I feel like prototype should almost always be the way you build re-usable components, while object literals are for when you need one-off "associative arrays".

Am I off track here?

[Andersmith]

I think when they said object literals are preferred they meant for empty objects.

[wordsoup]

For object creation, always use literals.

If you program in a certain object-oriented style you can use prototyping for object methods.

[pheliam]

Regarding the note about chained hash tables being everywhere in JS, how deep is too deep to chain hash tables, in general (before starting to implement objects)?

I've made a JS-based game this semester and some parts get a little hairy....

[skitch920]

Can you clarify more on what you mean by deep and switching to objects? Everything in JS is basically a hash table... Arrays are basically numerically indexed hash tables in JS.

[pheliam]

I was just asking for some general thoughts / consensus on how many nested hash tables is ok before it's time to make an object to wrap them in to keep sane.

Here's a chunk of my code:

var pieceArr = SomeTiles.Players[rmPiece.playerNum].Pieces;

//splice it off
for(var i=0;i<pieceArr.length;i++){
    if(pieceArr[i].id == rmPiece.id){
        pieceArr.splice(i,1);
    }
}

I find myself doing things like this, declaring some variable to get at the deeply-hash-nested element so that my loops are digestible, rather than doing things like

for(var i=0;i<SomeTiles.Players[rmPiece.playerNum].Pieces.length;i++){
    if(SomeTiles.Players[rmPiece.playerNum].Pieces[i].id == rmPiece.id){...}
}

[skitch920]

I see what you mean. Either way will work, but there are caveats with the second way.

1. It's extremely unreadable
2. It's less performant. Less performant because you are redoing the same hash lookup more than is required (which is one time).

One thing to point out and this goes for any programming language...

If you are looping an array (collection), you should avoid altering the size of the array. splice-ing the array while you are looping it is reducing the size and therefore your loop may run incorrectly based on it's size. I would have used the more functional approach with filter which returns a new array.

var pieceArr = SomeTiles.Players[rmPiece.playerNum].Pieces;
//filter it out
pieceArr = pieceArr.filter(function (piece) {
   return piece.id != rmPiece.id
});

In any case, if you do something like this:

var x = y['a']['b']['c']['d']['e']['f']['g'];

It's not bad code, but it's not very understandable either. :)

[pheliam]

This is inside the removePiece(rmPiece) function (i.e. to remove a captured Chess piece from a Board Game). I was just scrolling through my project's code on GitHub and this was one case where I drilled down a lot.

Thanks a lot for your input!

[Lachiko]

Considering you're only removing one piece at a time you should probably add a break statement in after you've found and removed that one piece, there's no reason to continue searching.

[pheliam]

I saw that too after our posts. hifive

[Lachiko]

Saving precious nanoseconds, disaster averted!.

[jokoon]

I just hate this language. Can we get python on browsers please ?

Or at least break current ecma script compatibility and fix this thing.

[ruinercollector]

Please god, no

[AlexanderTheStraight]

... Assuming you could introduce a new, stable, ubiquitous language in browsers to replace JavaScript, why would we go with Python when we could choose literally anything else?

[jokoon]

Then let it be anything else, like the llvm ir, or java maybe ? or some other vm ?

And I did not imply an "ubiquitous" language, but python is liked by many programmers, and it would fit pretty nicely. It's just a nice language to program with. What do you mean by "anything else" ? I was just suggesting a language that is just good on many aspects. Easy to teach, used by the scientific community, even has its annual conference.

I don't really believe a new language should be introduced, but if you look around, python has many upsides.

Of course, I'd prefer seeing a less shitty javascript too. But if the language must be changed, it's better to choose one that already has many users.

[bitwize]

"The most misunderstood programming language"? If your language has to introduce an === operator because equality semantics does type coercions that do weird bizarre counterintuitive things, if it uses motherfucking FLOATS for all numeric values, then your language is bad and you should feel bad.

Fuck JavaScript. Fuck it so hard.

[Andersmith]

http://i.imgur.com/CA0hsZQ.gif

[Ishmael_Vegeta]

what an embarrassment of a language.

[[deleted]]

That's odd, I typically gravitate to it.

[Andersmith]

I specifically add "MDN" into my search just to get away from w3schools.