Common JavaScript Gotchas
github.com
github.com
It wasn't that long ago when all JS did was put snowflakes on a page, or trails of fire behind your cursor, or annoying sequences of alerts and prompts. And it was called DHTML.
Were it possible - in the 90s - to anticipate the recent surge in popularity of JS, maybe we would have had a totally different language.
That said, these 'gotchas' are just part of learning the language. Same with PHP really. With a sufficient level of experience you tend to forget they actually exist.
there is little effort into changing this
It does not get to the core of the problems with JavaScript. It does not make the breaking changes necessary to truly fix the situation. It gives a false sense of improvement, at best.
This is rather political - everyone want to have controls over the next language of the web, and nobody would want to adapt one made by others.
What even worse is that we all know it's almost impossible to create a good language without some dictatorship at the beginning.
The entire project is open, the VM, the dart2js compiler, the libraries, the package manager.
As for a performance hit when integrating with the browser, what re you talking about? Any references?
The performance hit is that inherent of having to have multiple GCs given the multiple VMs. This is part of the reason why support for non-JS VMs didn't get into WebKit proper: <https://lists.webkit.org/pipermail/webkit-dev/2011-December/.... Various citations to research around there are listed in that email.
I'm not sure any such overhead would always occur, or would only happen if both VMs were in use and there were cross-heap references. It'd doesn't seem likely that cross-heap GC would have such an impact with only one heap.
But, in the case of JS, there's one major practical constraints: Introducing a new language must not regress performance of JS. (Why? There's an absolute ton of JS on the web. Getting 1% of the web using a new language able to be quicker doesn't matter if you regress 99% of the web.)
You may think, "Sure, that's easy. You just add a second VM, entirely disjoint from JS!". Unfortunately, it's not that easy: if you allow the languages to coexist in the same page, you then need to GC across both languages (as some objects are shared between the two runtimes, primarily those relating to the DOM), and cross-VM GC is an active research area, where nothing has been shown without at least a 10% performance hit to both GC impls.
Well, then, how about having a "generic" VM that runs JS within it? You're going to have an uphill battle to get performance equal to current JS VMs, because their bytecode (ignoring V8 for now!) encodes a lot of high-level semantics of JS, which means any new language, to have good performance, would have to share a lot of semantics with JS. This inevitably puts massive limitations on what any new language can be like, and restricts it to being "JS-esque".
So what can we do? There are two basic options: subset JS, though inevitably this doesn't sort out things like `==` v. `===`, but you can get to something where you can statically check you're using a sane subset (e.g., not using `==`, not using any undefined variables, etc.); or, write some language not overly dissimilar to JS and compile down to JS (the "not overly dissimilar" restriction is a practical necessity as you can't really afford to send large language runtimes and standard libraries over the wire). In both cases, JS is ultimately the target thus it's important to keep on fixing what can be fixed with JS (e.g., the lack of a module system, the lack of memory-efficient data structures), but both can improve the situation over unrestricted JS as it is today.
HTML -> XHTML might happen once IE < 9 becomes irrelevant, but I doubt it
> if you allow the languages to coexist in the same page
What if we didn't? Perhaps each site could decide whether to use the JS VM OR the "new" VM; it's not ideal, but this could work. You know, much like what one would (usually) do server side: choose a language, stick to it.
and it worked really well! at no point did i hear anyone say "i wish javascript wasn't so limited". it's just a vary playable language that's easy to learn and quick to use to hack things (or create entire frameworks out of). it's no coincidence that it's still so popular.
Any list of gotchas that omits discussion of falsiness, objects vs arrays, array-like things that aren't arrays, the array sort function...
And the throwaway comment about JavaScript being poorly designed is facile and annoying Every language anyone uses has warts.
It's pretty telling that Crockford's "JavaScript: The Good Parts", which is the most widely-recommended book by the JavaScript community, essentially says to not use huge parts of the language. One doesn't have to intentionally avoid so much core functionality when using most other programming languages.
* C declarations (experts can get into flamewars discussing good ways of reading C declarations)
* C (and worse C++) keyword overloading
* C strings
* Most of C++ (i.e. most of C++ - C)
* Most Java libraries
* Objective C's declarations (which at least have gotten markedly better recently)
* Perl's variable prefixes and subroutine declarations (even if you don't mind Perl's other quirks)
* semantic whitespace in languages with semantic whitespace
* PHP -- which I find useful and perfectly capable of supporting large projects -- is hilariously awful.
The object declaration is painful, it has variable hoisting and doesn't have proper block scope leading to all sorts of weird bugs, it doesn't have simple namespacing, it didn't have a foreach, it didn't have get/setters until recently and even now the syntax is bad because they wanted to maintain backward compatibility.
Oh and everything's a bloody function. A function is a function. A class is a function. An anonymous method is a function. It can get really hard to read and pick out what a bit of code is actually doing on first pass.
And that's just the big, really simple but important, every day stuff that a normal coder needs to do their job in even the slightest complexity scenario.
I sometimes wonder if the 'other' language that netscape was going to use was really as frustrating as javascript is when you start working on more complex code.
What it did have which most languages didn't have is treating functions as first-class objects and closures. They're brilliant.
Unfortunately almost all other modern languages now have these and javascript still doesn't have all the other goodies so that's one of the many reasons it gets so much hate.
So now compared to any other language it looks so dated and archaic.
I really enjoy writing javascript at times, but as the code gets complex I despise it. And I hate coming back to my old javascript code.
Well There are no classes in javascript at all. A constructor is a function in most OO languages. The difference here is the underlying OO implementation.
Anonymous methods are by nature functions as well. Could there be a more succinct syntax for them? Perhaps, but of all of the complaints about javascript this is a relatively minor one.
I would never say that there are not things about JS that don't drive me nuts. But the relatively simplicity of thinking of just about everything being treated equally from a language standpoint gives you a flexibility to work that can be really refreshing.
The everything is a function is because at least in other languages it's clear what a constructor is, what a function is and what an anonymous method is. They all look distinctly different and have different keywords or declaration syntax. Generally speaking something like:
class Thing
Thing() { } //constructor
function Thing() {} //function
(p) => {} //anonymous method
It could be true writing good JS is a little harder than good Java, especially on the server. This is a consequence of the callback oriented nature of JS frameworks and APIs. Once you get used to it, it wouldn't really matter and there are real performance benefits that come out of it.
As for the many warts people bring up, how hard is it to follow a few good practices? If those trivial issues can't be overcome, that person will have problems programming in any language.
Whether I can write a useful program in it is uninteresting, because that's a property of almost all languages, good or bad. The question is whether its a pain.
No. I've written non-trivial JS code and the amount of possible mistakes that a person writing JS can make is a lot more than say, Python or Ruby. You have to be really really careful and simple things that you shouldn't even have to think about become tedious.
Not to turn this into a JS hate thread, but I'd rather write C code that doesn't pretend to be safe, than write JS code that does, and screws up anyway.
I have indeed worked on multiple large JavaScript code bases. Some of this work was in the late 1990s (using Netscape Enterprise Server's support for server-side JavaScript, unfortunately), and some of it within the past few years.
Having worked on large JavaScript-based systems, in addition to ones written in languages like C, C++, Java, C#, Fortran, COBOL, PHP, Erlang and several proprietary languages/platforms, the problems with JavaScript become excruciatingly clear. The wider your experience, the more obvious it becomes how terrible JavaScript is.
The problems with JavaScript, especially for any sizable development projects, run far deeper than merely needing to stick to some "good practices". It just doesn't provide the infrastructure needed for anything but small-scale development. Its many flaws render it further inadequate for any serious use.
Now, that won't stop some people from trying to push it far beyond what it's capable of. The results are never good, however, and generally inferior to what could be obtained when using other technologies.
Once you know which pitfalls to avoid it's possible to write some really elegant code, but the mere presence of those pitfalls causes a ton of problems when you bring in engineers from other programming languages.
I find it kind of concerning that when someone criticizes JavaScript, everyone's first response is, "he must not have any experience with the language." That's an unfounded personal attack and ignores the crux of the argument.
Look, we love JavaScript, but it doesn't do us any good to pretend it's perfect. It'd be much easier to ramp up new engineers on the language if we admitted its flaws and made efforts to educate "the right way."
The interesting thing to me about JavaScript is that insofar as it lacks "crucial" language features it turns out to provide the necessary tools to build them yourself. Exactly gow do you want inheritance or modules or whatever to work? E.g. While JavaScript doesn't impose a module structure it's very easy to come up with one, and because you build it yourself you can tweak it to deal with your exact needs rather than adhering mindlessly to "patterns" developed for working around the shortcomings of more tightly defined languages (Java, cough)
Java programmers moving to JavaScript seem to write horrible code because the freedom to actually just do stuff rather than build boxes with tiny weird-shaped holes cut in them to package pieces of functionality is so alien.
I wish Python, with its (fewer) warts were as ubiquitous and useful as JavaScript, but it's not, and Javascript is pretty darn good.
Like you said, bad code is somewhat inevitable when you drop a classically-trained OOP programming into JavaScript. And that specifically is not a fault of the language. But I think we can all do a better job of pointing newbies in the right direction.
This is an anti-programmer programming language. The fact that so many people love it is a bit of a mystery to me and I've actually used it for both DOM manipulation a long time ago and for mobile apps more recently. I will say that it's quite good at being a scripting language for an app UI (QML).
This was something I picked up pretty easily (blame perl, I guess? I blame perl for lots of things.) The weird way in which coersion would interplay with {truth,fals}iness, however, took much longer and involved much weeping and gnashing of teeth.
> And the throwaway comment about JavaScript being poorly designed is facile and annoying Every language anyone uses has warts.
Agreed. The post was helpful (and the link to Crockford's book is arguably the single most helpful thing in the list) but the off-hand comment about ES being poorly designed didn't add anything to the discussion.
Really, he should've used a different title, say "JavaScript Rant"
The author complains about the was language is designed, and says "might", "in some cases", "this is wrong" etc. without showing real examples. And he's also dead wrong on a few facts (like JS being a pure functional language).
Looks like "let's bake something in 5 minutes" and post it to HN to get 57 points for nothing.
An example of my last sentence: have look at how Titanium SDK (v2.1.x) folks designed their "parasitic inheritance" architecture following Crockford's book. A terrible, unusable, instable, un-hackable (wrong) use of JavaScript.
EDIT: I don't know if Steve Kwan is actually a _noob_ or not, but it looks like. Eg:
identifier = function () {};
// As expression, in an assignement or as argument.
(function () { /*...*/ });
// As expression, but with a name given to it.
(function $identifier$ () { /*...*/ });
// As a declaration, which gets HOISTED!!
function $identifier$ () { /*...*/ } var someObject = new Object();
Regarding variable hoisting, I am trying to keep this article short, concise, and focused on the big offenders when it comes to gotchas. The only reason I didn't discuss hoisting is because I felt it would introduce too many concepts at once. To me, hoisting is kind of "level 2," whereas understanding why var is required is "level 1."
And on a side note, I appreciate all the feedback you're providing here - I really do. That's why it's on GitHub and not some blog somewhere. But I would suggest that we separate personal attacks from code criticisms. If you don't like my approach with this article or you find something that's flat-out incorrect, by all means tell me. As a human I am prone to make mistakes - maybe moreso than others. :)
But please avoid making value judgments about a person you don't even know, such as calling them an ignorant. It's bad enough when people behave this way on the internet, but if that kind of mentality starts to seep into your "real world" life too, it'll start having serious effects on team relations and employability.
At the same time you could make a "level 1" article a lot more adherent to reality. For example, you could completely jump over that "function creation" section entirely, and simply do a clear explanation of what an expression is in JavaScript, and how to spot them.
Again, thank you for your personal advices, and thank you for your politeness (as opposed to my manners).
No error:
<script>
myFunction();
function myFunction() {};
</script>
<script>
myFunction();
var myFunction = function() {};
</script>
In the second, the var myFunction gets hoisted to the top but not the function definition, which is why calling it produces an error. In the first, the whole function gets hoisted to the top.
All variables are hoisted to the top of a function, where they are defined as 'undefined'. This is confusing, I know - there is actually a difference between an undefined variable (accessing it will cause a ReferenceError) and a variable defined as 'undefined', which is in many cases identical to null, except in object syntax.
An example you can run in your inspector:
function foo(){
console.log(a);
var a = "string";
}
function bar(){
console.log(a);
}
foo(); // logs 'undefined'
bar(); // throws ReferenceError
Well, this is because of the variable hoisting. Before running a function, the interpreter scans for any var definitions and 'hoists' them to the top of the function, where they are set to undefined. This leads to the strange situation where defining a variable after it's been accessed (as in foo()) actually prevents an exception.
The same is true of functions defined with the 'function name(){}' syntax. As opposed to the 'var name = function(){}' syntax, the entire function (including the definition of the function!) is hoisted to the top of the containing function. So this will work:
function foo(){
bar();
function bar(){
console.log("works!");
}
}
foo();
// old version
function longFunction(){
// 50 lines of code
// awful, messy
}
function refactoredLongFunction(){
doFirstThing();
doSecondThing();
doThirdThing();
function doFirstThing(){
// ...
}
// other function definitions
}
If you'd like to know more about function and variable hoisting, this is a good read: http://www.adequatelygood.com/2010/2/JavaScript-Scoping-and-...
A little off topic, and completely trivial and petty, but it kinda bugs me when people talk about it as if the interpreter is moving variables around.
Moving variables around like that seems like a completely nutty thing to do, because it is. You can't give someone an explanation of the trade-offs as to why Javascript does it, because it doesn't. So hoisting is just presented as another thing Javascript does that makes it weird.
Really it's not actually moving anything, it's just an artefact of the same scoping rules used in lots of languages, compounded by allowing variables to be referenced before they're assigned.
Variables aren't moved, they behave as if they were moved.
I would prefer Ben Alman, Douglas Crockford, John Resig, Paul Irish, or one of the many talented people writing about javascript if you were actually interested in understanding the gotcha's on this list.
Also, I wish authors would be careful to distinguish js from jQuery. Yes it's standard now, but preferences change with time.
Truth be told, if someone wants an explanation of some of JS's weirdness, there are far better articles out there they can Google to meet that need. :)
function myFunction(arg1, arg2) {}; // This is OK, but...
var myFunction = function(arg1, arg2) {}; // This is best!
What problems? How does assigning the function to a variable help avoid needing to make a closure for this?
EDIT: To clarify:
All variable declarations in Javascript do indeed get hoisted to the top of the scope, but with function declarations even the function value itself gets hoisted. So for instance, this returns 'two':
function foo() {
function one() { return 'one'; }
return one();
function one() { return 'two'; }
}
foo();
function foo() {
var one = function one() { return 'one'; }
return one();
var one = function one() { return 'two'; }
}
foo();Some people think its better to ditch named functions completely rather than learn exactly when its problematic and when it's not... which I'm not sure I completely agree with, but its probably a good advice to give to a new JavaScript programmer, as it basically behaves the same minus those issues.
CoffeeScript ended up removing named functions [2] [3] (with the exception of being used for "class" declarations, where its known they're safe) for that reason.
[1] http://kangax.github.com/nfe/#jscript-memory-management
[2] https://github.com/jashkenas/coffee-script/issues/366#issuec...
[3] https://github.com/jashkenas/coffee-script/wiki/FAQ - "Q: Is there any way to name functions, for reflection and recursion?"
edit: formatting
So no, I disagree that that's good advice to give to a new programmer.
To address your other points - you can get a recursive reference by simply assigning your function to a variable, `var f = function(){ f(); }`. There's no need for named functions for that.
As for call stacks and debug messages - that was true some time ago, but modern debugging tools can figure out the function name pretty good even if it isn't a named function. I work with CoffeeScript code(who doesn't have named functions) and stack traces are fine.
I think its a better practice to avoid named function expressions on client-side code. Non-expression named functions are fine, but considering that named function doesn't actually have any benefit (I don't consider hoisting a benefit - I prefer to have my functions declared before they're used), I can see why some people would decide to just avoid them altogether.
edit: spelling
> (I don't consider hoisting a benefit - I prefer to have my functions declared before they're used)
> As for call stacks and debug messages - that was true some time ago, but modern debugging tools can figure out the function name pretty good even if it isn't a named function.
All of these ignore the fact that functions are not simply declared once in Javascript and then used later, like in C. It's a dynamic language with first-class functions and function literals. You could assign to a variable in this case, but that's needlessly restricting:
asyncFunc(function cb(result) { print(result); });
> All of these ignore the fact that functions are not simply declared once in Javascript and then used later, like in C. It's a dynamic language with first-class functions and function literals. You could assign to a variable in this case, but that's needlessly restricting:
>
> asyncFunc(function cb(result) { print(result); });
var cb;
asyncFunc(cb = function(result) { print(result); })
Other than hoisting and leaking memory, nameless function expressions can be used to anything that can be done with named functions.
It is quite amazing how much effort people putting in to designing the "perfect" language, and yet we continue to see highly flawed languages get popular.
I wonder if we'll ever see a replacement for JS in the browser? Maybe just a JS-strict with all the gunk and strangeness removed (and maybe the libraries cleaned up a LOT).
If you discovered that the answer was one or the other, would it make you a better developer in any way? Would it help solve any problems the world has?
Perhaps you should look more into why the "Gresham's Law of Programming Languages" exists. Maybe the have better documentation, a more friendly user community. Maybe they fix more real-world problems and spend less time mentally masturbating over programmer porn.
http://bonsaiden.github.com/JavaScript-Garden/
It's long but not THAT long. There is a strict set of JS with some of the gunk removed. I don't think they went far enough but such is life. I'm not expecting a replacement for JS in the browser. AFAICT the browser vendors aren't interested in getting a replacement language standardized. I do expect compile-to-js options becoming more popular.
There are a couple other problems that make building web applications hard but are not the fault of the language:
What I generally find is that people who think JS sucks don't actually know JS. They know Java or C# or something and can, without learning anything, put together something that runs and generally does what they want. Their success (no obvious failures) and comfort with the syntax (except for those damn unexplainable JS bugs) causes an overestimation of their capability.
Overestimation is a problem because their experience in programing allows them to write a complex chunk of code that has the wrong abstractions/organization. It's absolutely awful. The worst 20-150k sloc codebases I've run across were ALL written by Java programmers who tell me JS sucks. The problem was that they're doing it wrong. Applying the right patterns has led to a 50%+ line count reduction in all cases. JS is its own language. The architectural patterns that work come from functional languages and not classy languages. Classy patterns can work but you need to go all-in and add type checking a la Google Closure oriented code and that's rare in the wild. Finally, small modules as in the node.js community generally seem to be working.
On the other end, JS suffers (along with PHP) the part timers. This would be fine except that easy but wrong patterns become standard practice. I fought against the jQuery spaghetti pattern for years only to find people migrating to Backbone, which is better but also flawed–events don't provide state isolation and the simple idempotent view.render() falls apart in larger apps and the workarounds are nuanced or complex. Use Ember or Angular. They are NOT more complex than you'll need unless you're only making brochureware sites.
The third problem is that the DOM sucks. The API is bad and has cross browser issues but jQuery basically won that battle. The remaining and more subtle problem is that it's a mutable global variable that you must interact with. There are a variety of mitigation strategies with the most accessible being two way bindings.
Someone bringing up PHP when it's fairly unrelated? Check
Maybe focusing on the issue at hand would be something to keep in mind?
Err.. since when did JavaScript become pure functional?
Every language has quirks. In the case if js, the things your complaining about like var and function declaration are features of the language.
So please don't interpret my calling these issues out as whining. Just trying to make new people aware that they are there. :)
If, on the other hand, I am legitimately WHINING and not realizing it, also feel free to tell me where so I can fix it. Thanks!
1) Newly added elements will not respond unless events are bound to them. One solution (thinking in jQuery here) is to bind events higher up the DOM.
2) Each line in code may not simply execute in sequence. For example, asynchronous ajax calls require subsequent calls to be nested in callbacks.
There are a ton of comments down below with a ton of criticisms and suggestions. I will attempt to summarize and respond to the key ones here:
#1: The list is missing a lot of very well-known JavaScript gotchas.
That's intended. My goal here is not to provide a complete, comprehensive list of all known quirks with the language - those exist in far better fashion on the web already. Rather, my goal is to create a simple list of issues that I KNOW will trip up newbies out of the gate.
Oddness with truthiness, undefined and arrays is definitely irksome, but from my experience people tend not to run into those problems until they've already written a good chunk of JS. On the other hand, issues like var, confusion over closures, and the this keyword come up very quickly - almost immediately.
#2: The list seems very negative and biased against JavaScript.
My apologies, as that was not the intent at all. JS is great. But it is also extremely flawed and there are some things flat-out wrong with the language. I'm definitely not the only person who says this, either. :)
It's a great language to work in and you can do some wonderful things with it once you grok it, but if we're going to be completely objective, we have to admit that it has some definite problems that make it hard to learn.
#3: This seems full of preferences, not hard-and fast rules.
That's definitely by design as well. I circulate this list out to my team and so it has my fingerprints all over it.
If this is a real sticking point with you guys and you feel it would be better having that stuff removed, please send me some pull requests and I'll be happy to review.
#4: The author comes across as snarky and unhelpful.
That's just a personality flaw and I apologize for it. :) I didn't want this piece to be dry and I injected a bit of voice. If you feel it's actually detracting from the article, please feel free to shoot me some examples and I'll clean it up.
I see a few of you already have, so thanks!
http://inimino.org/~inimino/blog/javascript_semicolons
Sure, its best to always explicitly use semicolons but its not as dangerous to forget them as most make it sound.
There's no justifiable reason for it to exist. The drawbacks should have been clear from the moment the concept arose, and it should have been scrapped before ever having been implemented. That's the only sensible response to it, after even a minimal amount of analysis.
A missing semicolon should be treated as an error, causing the execution of the script to be immediately halted, and the programmer notified of it. It is as simple as that.
I actually find little quick explanations like this extremely pragmatic and useful. I don't do a whole lot of JS, but I certainly need to dive in occasionally. Having quick references like this one readily available is preferable to finding my Crockford book and flipping through the pages. If you need to develop a client-side app or do heavy JS coding, maybe read the Crockford book...but if all you need to do is get some shit working real quick links like this one are invaluable.
At some point just like Monads you just get the javascript type system and don't worry about it anymore. It is what is. No amount of gotchas will get you over the hump; you have to actually understand it. At least it isn't syntax like C++ where you find out in a WTF moment that the parser is doing something insane.
40% of it just keeps droning on about how noobs will fall for these traps, and saying things like "If you are new to JavaScript, I suggest avoiding the this keyword".. as if these concepts are so mind blowing noobs minds will melt.
it does bring up a few good points but it could have been a lot shorter.. and how is closure a common js gotcha? the list includes 4 javascript constructs veiled into a rant.
But from my experience, someone who is coming into JS for the first time is probably not setting up a complicated object hierarchy - they're probably just trying to figure out how to bind some events to a DOM element and get some basic UI functionality. And they probably don't need to use the this keyword as much as they think they have to.
I completely agree that this could be a bad decision on my part, or at least a very controversial one. But I'd rather have truly new JavaScript developers focus on things like encapsulation and closures before they get too far into the this keyword and constructor/prototype.