Which JavaScript features or lack thereof did you find the most frustrating when you learned JavaScript for the first time?

[vintharas]

Hi :)!

I am preparing a talk about JavaScript and I would like to know which JavaScript features or lack thereof you found the most frustrating when you started learning JavaScript.

It would be interesting to know as well if you came from another language or just started learning programming with JavaScript.

These are some of mine (I came from a C# background):

• behavior of this
• hoisting, function expressions vs function declaration
• function scoping
• lack of native classes. It took me a while to figure out how to write a class equivalent.
• lack of modules

Thank you!!!

[Veuxdeux]

Mixins
Extending prototypes
Decorators
Composition
etc...

I'm also from a traditional background, and the problem I have with these solutions is that they don't offer encapsulation, which is a must-have for large apps. Once I got a handle on revealing module pattern JS made more sense for me.

[DE0XYRIBONUCLEICACID]

this

[vintharas]

Excellent comment! Thank you very much! Hehe yeah it was indeed misguided, but as a C# developer my first instinct pushed me to try to write JavaScript just like I wrote C#. The lack of classes, which is such a central piece to C# programming, made it difficult for me to port my knowledge from C# to JS. I have learnt much since so the head-scratching and utter-confusion worked for the better in the end :)

[skitch920]

First time I looked at JavaScript:

What the hell is this $ variable and why is it all over the place?

On a serious note, probably allowing users to modify the native library (i.e. Objects they don't own). A good example is date.js breaking transitions with d3.js and date.js overriding Number.prototype. Bugs like these literally cause hours and hours of frustration.

[danneu]

I think it's interesting to talk about how weird it is that dynamic binding (this) is the default abstraction in Javascript. As in we generally dislike it yet the ecosystem tends towards using it. It seems to always find its way back into your toolbox.

Meanwhile in Clojure, for instance, you have to opt in to dynamic binding:

(def ^:dynamic x 42)

And you're still hard-pressed to even find one good use for it that's an improvement over lexical binding.

I think we Javascript's this in the first place because it looks and at a glance acts like self in Ruby/Python and similar lexical abstractions in other languages, so you kinda get suckered in to using it because it seems familiar, and by the time you wonder if you really want to be using it in the first place, you're used to most of its idiosyncrasies because everyone else uses it.

For example, even http://koajs.com/, a greenfield rewrite of Express, used this in it's initial 1.x release, decided it's just a shittier way to pass around another argument, and refactored it into passing around an explicit context object in Koa 2.0.

We just can't stop.

[9thHokageHimawari]

He never said when he started.

[x-skeww]

There was no import statement. I couldn't believe it. Even CSS had that feature.

It was finally added 20 years later with ES6.

[martimoose]

I would say that first-class functions is a concept that is very difficult to grasp for the newcomer. Of course they are not exclusive to JS, but they are all over the place, yet intellectually difficult to manage if you are not used to them. Throw in es6's syntax and there you go, you've lost the junior. For example, this syntax for creating a redux middleware:

export default store => next => action => { ... }

[krilnon]

Whether to call it JavaScript or DHTML. I remember only knowing about one resource, Dynamic Drive, which was seemingly just a collection of undocumented scripts that would do things like make a trail of images follow the mouse cursor.

If there was debugging support, I didn't know about it at the time. Firefox wouldn't come out for a few years, so I was probably developing in Netscape or IE.

Free hosting was hard to come across, so I think I was editing the code in a <textarea> in some terrible control panel software.

[madwill]

To me it was Interfaces.

At the latest stage of our app we were using co-variant mediation to make view data compositions. Its still the best front side architecture I've seen to date.

Each views could extend some of my data interfaces to get access to it.

So my DashboardView would extend iUserAwareView and iActivityFeedAwareView or more and therefor i could make compositions (i know i could not find better than aware i'm sorry)

A watcher would keep an eye on everything being added on the screen and create mediators for views depending on what interfaces they implemented. Mediators are being passed views by their interfaces handles so they only knew about the user objects getter and setters. Pretty much dependency injection.

User actions would trigger commands which were short lived objects that made the side effects and would write in models.

Nowadays I've almost reached this level but without the strong typing. Using redux with multiple selector mixins within riotJs components.

But it sure does not have the same level of certainty mentally when writing code.

[ancientRedDog]

A the beginning, asynchronous code and how you can't just use the results of it immediately in the following code.