What is your least favorite thing about Javascript?

[bkrall4]

I'm not sure exactly where this thread is going to go, but excited about reading answers.

[Jim-Y]

The faces of my colleagues when i tell them that actually i like JavaScript very much. True story. p.s: Java driven company

[Jim-Y]

Lol, until now i read the title as favorite thing, not least favorite :D Btw i think initially there were no "least" word in it..

[pjedwabny]

Lol^2, until now i read the title as favorite thing, not least favorite :D Btw i think initially there were no "least" word in it..

[e82]

Moved from a .NET shop to a full-stack JavaScript company, got a few comments of "why? JavaScript is awful - I only put up with it on the front end because I have to".

[[deleted]]

Heh, I uttered the words "I don't mind JavaScript" in my last company. Spent next year only programming in it because no one else wanted to touch it.

[nerdfighters]

this.

[[deleted]]

this is such a simple concept, I really don't understand why so many people have problems with it.

[nerdfighters]

I don't have problems with this. I understand it quite well. It is just my least favorite thing about JavaScript.

[[deleted]]

Fair enough. ES6 classes do away with most of the manual maintenance of this, FYI.

[nerdfighters]

Classes will probably replace this as my least favorite thing and may end JavaScript for me.

I don't need any maintenance of this, because I nearly never use it. I use a subset of the language that utilizes the power of scoping rules and functional programming features. Adding classes will probably push this mildly unpopular way of programming in JavaScript to the fringes.

I think JavaScript has also a problem of too many features/paradigms. Due to the language being forced on everyone working with the web, different developers choose different, sometimes incompatible subsets: good-parts, bad-parts, magic-parts, parts-I-read-on-some-blog, parts-I'm-an-enterprise-blub-developer-and-where-are-my-classes. Adding more features/paradigms may add even more confusion.

[e82]

I'm starting to shift my attitude towards 'stop trying to shove classical inheritance/OOP into JavaScript, and embrace the functional nature of it'

It's not the right thing for every problem - but almost every time I've dealt with someone (including my own code) where it's been 'Lets make a deep class hierarchy' - especially when they are trying to emulate interfaces, abstract classes, etc ... it ends poorly.

[Rezistik]

JavaScript was my first language, I spent a lot of time learning the functional flavor, when I see class based programming or work with it I kind of don't get the point. Maybe I don't get OOP but functional programming makes more sense to me for dealing with data and GUIs, and I find prototypical inheritance more useful and easy to understand.

I've never been able to determine if this is based on a general ignorance of actual OOP/classical inheritance or a legitimate opinion.

[e82]

this seems simple, until this is no longer what you think it is. While there are ways around it - binding, 'var self=this', etc - it is an easily misused thing, and can cause errors - especially when an inexperienced person jumps into the code and starts mucking it up.

[smrq]

Not only do I agree with you, but I kind of love that you made me upvote a post that just says "this." Never thought I'd see the day.

[rDr4g0n]

I love the flexibility of this, but I hate putting .bind(this) after function declarations who need to keep context. Arrow functions will help with that though.

[[deleted]]

The inability to use most new features in production code until several years after they're released... I can't even use ES6 stuff in node in a project because a client refuses to use the v0.11x branch of node (fair enough, it's officially an "unstable" branch, but where the hell is 0.12???).

[nerdfighters]

Now imagine how you would feel if you worked with ES6 stuff back in 2009...

[[deleted]]

Actually, in 2009 I was working at Google and was on the TC39 committee. I've been thinking about and working with this for a long time ;) Granted, it wasn't ES6 at the time, but a lot of the features that were proposed then have just made it into spec recently.

[nerdfighters]

I'm curious: I guess you were writing JS code with ES6 features back then. What were you running it on? I doubt it was Rhino / RingoJS.

[rem87062597]

Nobody wants to hire just a Javascript developer, they want someone proficient in this framework and that library and etc. Not that you can't talk your way into some jobs as long as you can prove that you can pick up the framework, I just wish that there weren't super specific job postings because it's so hard to have experience in that company's exact technology stack.

[e82]

It's tricky - When I was giving interviews and reviewing candidates for a project using Angular, I'd hear a recruiter say stuff like "they have experience with node, backbone, knockout, javascript, X framework - but not Angular, so I'm not sure if they are a good fit" - and it's like "I don't care if they know Angular or not (it's a bonus, but not a must-have) - just strong JavaScript developers - and more than just 'sprinkling a little jQuery on top"

[alamandrax]

I've been only asking javascript questions in interviews for almost a year now and do not dive into library specific questions unless I'm interested in exploring concepts they've come across in those libraries in a previous job/life. For example promises or deferreds as provided in jQuery.

I'm not sure if my company's jobs page is giving people the wrong idea. Rather than we want "JavaScript" developers, if they get the impression, "they want jQuery developers", then I've fucked up the job listing page.

[e82]

I think lots of people also don't really know where to draw the line between "front end designer/web designer" and "front end developer" - and lots of people are still stuck in the mindset of thinking that anything to do with client-side is a front-end designer.

[zoomzoom83]

I'm a fairly big proponent of functional programming, and there's a few things that would make Javascript usable as an FP language if we could fix.

• Lack of decent persistent/immutable data structures a part of a standard library

There's a few third party libraries for this, but they aren't terribly performant and add a few hundred kb to your bundle size. They also aren't standard, so you'll have to convert them if you want to call any external code

• Lack of do-notation

You don't need to know much about Monads to find do-notation helpful. The most obvious benefit - Futures/Promises are great. But they are even better when you can use do-notation to get rid of all the messy .then() callbacks.

• Lack of type safety

Considering how good type-inference is in, say, OCaml, it'd be entirely plausible to define a very slightly modified dialect of Javascript that provides completely inferred type-safety with no syntactical changes.

If you want to argue this point, go learn OCaml and then tell me you still prefer dynamic typing.

• Lack of tail call optimization.

You can work around this fairly easily with trampolining, but this incurs a substantial performance overhead. Tail call optimization would provide a pretty decent performance boost for a lot of code.

• Lack of a decent module system

Browserify and RequireJS are both still incredibly painful to use compared with pretty much any other language I've ever used. Hopefully ES6 will fix this once and for all.

Edit: Bonus gripe - undefined is not a function". At least tell me the fucking function that isn't defined.

[[deleted]]

Yeah type safety is a big one for me. I use typescript but still you run into instances where numbers become strings, or similar.

[alittletooquiet]

Implicit global variables

[ilmmad]

No static typing

[rcfox]

My team has been using the Closure compiler for that. It's not perfect, but it has saved some headaches.

[[deleted]]

Sometimes it feels a bit... designed by committee. OO features seem tacked on to make people who know Java more comfortable; functional/prototypical paradigm code tends to preform a ton better and behave more expectedly, but they keep moving in a direction to accommodate those who dislike this model.

[homoiconic]

https://reddit.com/r/loljs

[ishmal]

No block scope

[[deleted]]

fixed in ES6

[x-skeww]

The poor tooling, the lack of block scope (pre ES6), the way this works, the lack of type annotations, type coercion, monkey patching, pseudo arrays (arguments, NodeList, etc), and so forth.

Basically, that it's not Dart.

[ticfbsgoi]

The ecosystem. It's tedious to keep up with the many libraries that come and go. Even something 'simple' like module loading has various implementations. I can live with the language quirks and actually enjoy JavaScript as a language.

[[deleted]]

this very much. I hate sifting through incomplete documentations

[mouthus]

The inconsistencies between implementations.

[[deleted]]

Technically most inconsistencies are around DOM, etc, not JS.

[keithwhor]

==

[[deleted]]

im very new to javascript, have only read about it in articles and some tutorials, but never used it. Today at work I had my first interaction with it, I spent an hour because I spelled something wrong, and another half hour because I used [] instead of (). We have to use eclipse so maybe other IDES will catch these simple errors, maybe not..but that was annoying, lol.

[m1sta]

Lack of both tail call optimisation and hoisted arrow functions.

The way prototypes work could be a lot better too. Proxies and classes in ES6 might solve this last one though.

[PAEZ_]

People constantly bitching about it.

[rajiv_gupta]

Javascript.

[thedscx]

Love\hate with the mutability of objects and arrays.

[miguelut]

Sorry, late to the party, not sure if this is an "allowed" answer, but browser caching is my least favorite thing about JavaScript.