[Tloewald]

Replace article with link to Crockford and John Resig's advanced JavaScript tutorial.

http://ejohn.org/apps/learn/

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.

[PommeDeTerre]

Nobody is suggesting that other programming languages don't have oddities or problems. But very few, aside from perhaps PHP, are riddled with the huge number of senseless, if not outright stupid, issues we see with JavaScript.

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.

[jeswin]

Have you actually used non-trivial Javascript in any project? You repeat the exact same thing in _every_ JS thread here, and most of it seems to come not from any real experience in JS.

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.

[PommeDeTerre]

I must admit, I do have a great deal of experience with many programming languages, many frameworks and libraries, many operating systems, and many platforms. Some of this experience predates the web.

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.

[stevekwan]

I love JavaScript, but there's no denying that large aspects of the language are somewhat ill-conceived. Crockford himself says this.

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."

[Tloewald]

"crockford himself" has done great things fo Javascript but he's also not the last word on it. He himself admits that some of his ideas about JavaScript were wrong and resulted from his pre Javacript baggage. E.g. The model he suggests for conventional inheritance in "The Good Parts" does not, iirc, actually work as advertised and in any event isn't needed.

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.

[stevekwan]

I'm not disagreeing with you in any way, shape or form. JavaScript is an AWESOME language for both productivity and results. But I think we're doing ourselves a disservice if we assume that anyone jumping right into the language is going to immediately understand it.

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.

[manish_gill]

> If those trivial issues can't be overcome, that person will have problems programming in any language.

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.

[andrewvc]

Yes, it's all doable, but working around JS's kinks is terrible. Why? A programming language has one job, and that is to be a good programming 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.

[blub]

What you don't understand is that good JS is very hard. It's hard because this language was never designed for application development, it was designed to edit the DOM. Not only is it unhelpful when trying to do things like splitting your code into smaller pieces, do encapsulation, refactoring, write performant code, but it actually HINDERS the programmer when trying to do the above.

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).

[Tloewald]

Depends on your definition of "core functionality". Some things stop being core because they're recognised as antifeatures and avoided. This includes huge swathes of many languages that don't get off-handedly derided as often as Javascript.

[JasonFruit]

I don't doubt you're right — it makes me think of some of the legacy portions of Object Pascal — but can you give an example or two of what you are referring to?

[Tloewald]

* case sensitive symbols in C and its derivatives -- thank goodness I can declare int Int.

* 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.

[mattmanser]

Javascript is off-handedly derided because it's got so many basic things wrong that never got fixed. If they'd have iterated fast with it by now it would be fine, but it's stuck in the glacial committees. And personally I think they needed to abandon prototypical behaviour which is just confusing and too verbose.

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.

[mudetroit]

I find some of these thoughts to be be a bit off in their basic premise. For example, "A function is a function. A class is a function. An anonymous method is a function."

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.

[mattmanser]

The relative simplicity is what I mean about really enjoying writing javascript.

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

Visually they are very different. In javascript they all look pretty much the same and have exactly the same syntax.

[joshuacc]

Nor does one have to when using JavaScript. Crockford's recommendations are a good starting point for new JS developers, but they're not the word of God on the subject.

[wuest]

> list of gotchas that omits discussion of falsiness

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.