JS has some issues. But the examples in your articles mostly mean that you need to spend more time understanding the language. It seems as if you were expecting it to behave like C#.

    myRide = new Car("BMW");
    letsDrive = myRide.drive;

    letsDrive(); // alerts "You are driving a undefined"

The 'this' pointer refers to the object on which you wrote the 'dot' to invoke the function. If you wrote a.b(), then inside b() 'this' will be 'a'. In your example, you used a function pointer directly without the 'dot' and got undefined. That is not a bug or a "mine", that's how JS works.

From the last article (why CoffeeScript isn't the answer) in the series:

  eat food for food in foods when food isn't 'chocolate'

> The declaration of what food is occurs in the middle of the line and doesn’t even look like a variable declaration. That code could easily be worse if "unless eat is undefined" was added to the end, making the whole line conditional.

You'd probably have issues with Python too for it's comprehensions. You should see beyond elementary syntax if you want to make arguments about languages. These details aren't even a preference; you get used to it in no time.

Summary for people jumping into JS from other languages, buy some good books because JS is somewhat different. Also, the "minefield" isn't that big a deal in practice.

> Also, the "minefield" isn't that big a deal in practice.

I completely agree. The vast majority of complaints about JS have to do with not knowing what the language is designed to do. I previously cursed JS until I spent the time to read/reread enough JS books to know what it should do. If I get unexpected behavior now, I know it's an error in my code, or I don't understand what should happen (thus time for me to read and learn).

As you pointed out, the examples yield the expected behavior.

myRide.drive();

// outputs 'BMW' b/c `this` is pointing to the instance

letsDrive = myRide.drive;

letsDrive();

// model should be undefined b/c myRide.drive is a function that is assigned to the letsDrive variable. Thus, `this` points to letsDrive, which of course does not have a `model` property.

To get letsDrive() to output a value other than undefined, we can simply create a `model` property and assign it a value.

letsDrive.model = 'Mercedes';

letsDrive();

// outputs 'Mercedes' b/c letsDrive now has a model property.

Lastly, the `delayed` method returns an anonymous function which in turn returns this.model. As JavaScript has function scope, the `this` inside the anonymous function points to the anonymous function itself. As the anonymous function does not have an attribute named `model`, undefined is returned (as expected).

Your example is wrong. You can't attach object properties to a function.

Javascript context is pretty simple. The keyword 'this' by default points at the object that the method belongs to. When you invoke this function :

myRide.drive();

the myride object owns the drive function, so any keyword 'this' inside of the drive function will be referring to the myride object.

when you do this:

letsDrive = myRide.drive;

letsdrive is now a function that belongs to the global object (window) since we did not declare an object for it. So 'this' is reffering to the window object.To get the output in your example, you would say

window.model = 'Mercedes';

And invoking letsdrive() will now return the expected result

Functions are objects, and you can attach properties to them.

  function foo() {}
  foo.bar = 7;
  console.log(foo.bar); // prints 7

I stand corrected on not being able to attach properties to a function, but what I said still holds true. The keyword this refers to the object that owns the method. The original commenter was saying that it was the method itself that was what this points at.

letsdrive = myRide.drive window.model = 'mercedes'; letsdrive.model = 'bmw';

letsdrive(); // outputs mercedes

I also don't like how the author implies that these "solutions" are all mutually exclusive. CoffeeScript with a Grunt-watch setup featuring CoffeeLint and Jasmine will catch more-or-less all of the issues that could possibly arise due to JS quirks.

Furthermore, the author's CoffeeScript example includes a syntax error -- `isnt` doesn't have an apostrophe in it.

I would love to see a nicer language replace JavaScript as much as the next guy, but it seems rather unlikely especially given the changes that ECMA has approved in the past.

I am really hoping that some day, we will be able to do front-end devwork that isn't just an abstraction of JS/HTML/CSS.

Out of curiosity, what pieces do you believe are missing from your dream of front-end development work? You can already get a WebGL context from languages like C or C++ (compiled to asm.js), which should provide all the necessary building blocks to largely duplicate the front-end development toolkits that you find in native environments.

I mean you're still hinging on some incarnation of Javascript to act as the virtual machine, and you need HTML to setup the basic environment, but those seems like minor implementation details. Nothing that should impact your creativity in any major way. But perhaps I'm just not thinking big enough?

Linting is not THE answer, but it's surely a useful tool that catches a lot of potential mistakes, and has the nice side effect of enforcing some sort of house rules.

The problem is with the linters themselves. JSLint is coded by Crockford, probably the most opinionated sw engineer on earth. It checks what he thinks is right, and mixes formatting checks with syntax checks.

JSHint is a small improvement, it allows you to switch off rules that Crockford doesn't even want to talk about, but apart from that it's not a great step forward. Plus, for no good reason at all they decided to rename some of the rules from JSLint, and switch some of the flags, so that sometimes "true" means enforce something, something it means refuse it. It's rather confusing.

Neither allow you to add your own rules easily.

The new kid on the block is ESLint. It has a pluggable architecture, different warning levels, and make no assumptions whatsoever. With its open architecture and access to the syntax tree it should be possible to create a plugin to check just about anything you care about. It is just coming out of alpha, their first step is to duplicate JSHint's functionality and then move forward from there.

It looks very promising.

This is an area I think IntelliJ really shines. The built in JSHint/JSLint makes developing and finding problems a lot better. It is still a dynamic language at the end of the day, but it makes itmore bearable.

> but it makes itmore bearable.

not when you have a huge codebase and you have to remember what function takes what kind of argument and returns what kind of result.

People might hate java,but i rarely have to learn any api by heart in java.it might be more verbose but it's just easier to write on large scale(and to discover without opening any library doc). Can developpers learn the new version of express without viewing the source code or having the doc opened on their second screen?

i thought about the problem, and I like the typescript "header" system for quick documentation(instead of jsdoc or closure comments ) , maybe there is something that can be adapted to js here...

then you have ternjs that helps a little but it's far from perfect.

yet yes,linters are just MANDATORY for js development,and fortunatly are supported by most editors,even vim.

Great article. Love to hear how other devs run their linter of choice during their workflow.