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