ActionScript 2 & 3 have a bunch of features being proposed for future versions of JavaScript: constants, parameter defaults, rest params, proxies, weak maps, binary data, private/protected/internal access modifiers. Also has an optional type annotation system (types are an actual part of the language in AS3), automatically-bound functions (AS3), and a Class system. Prototypes and closures are still present in the language (I still use them a lot, but many AS3 programmers do not). (It sounds like parent is familiar with AS (and the question may have been rhetorical), but I included the above list for those who are interested in the differences.)

Having said all that, I don't believe those features are what the author prefers about the Flash environment. It seems Mr. Eckel is: * lamenting the loss of `packages` (AS3; AS2 had namespaces for Classes) as I surmised from the closures section (closures as a way of creating private members) * in need of a good framework for building GUIs (he stated he liked Flex [a framework for AS]; though many good GUI frameworks exist for JS) * has bought into the popular opinion that JavaScript is a broken and bad language (though many of the same issues plague AS; in fact, despite what the article may imply, AS and JS share the same way of creating a scope [via functions, not by blocks])

I agree that Mr. Eckel did not succeed in making any clear points. Writing this comment was especially difficult because the article was unfocused. It was not the usual quality I expect from a front page HN post.

I'd say that's classic Eckle.

Take pity on the man, he's coming to terms with his irrelevance. I read his books, they were rubbish. You don't teach programmers Java by starting off with polymorphism. You don't offensively pepper example code with unit tests to make sure the code in your book works.

Tripe such as that he has written here is the kind of talk that had poor old JavaScript derided for years. Correct me if I'm wrong, but JavaScript always had closures, it always had anonymous functions, it always had objects and its for in loop, and functions were always objects! The fact it has a 'new' keyword is because of Java bozos completely missing all the points of JavaScript's features and demanded some familiarity.

The fact something such as CoffeeScript can generate running, valid JavaScript is a testament to it's flexibility.

The truth is that there's an awful lot of complexity left to capitalise on, and I'm not sure why he's complaining. He's been capitalising on it for years.

So while some people will still listen to him and avoid these new hipster technologies, other developers are busy paving the new way and building cool things. The tech we have ain't that bad.

I beg to differ. It is a good article, and it makes me want to buy and read Javascript: The Good Part.

Other people have recommended me the book before, but they were just hipsters who just follow whatever technology that is regarded by other hipsters as cool.

If you read some pages and go "WTF?! This JavaScript is a helluva bad language. WTH is the good part?", the hipsters will just come back with "Dude, you just don't get it".

By opting for "Hell yeah, the language is super bad", Bruce Eckle presented a strong case why the book is a required reading.

"JavaScript: The Good Parts" : The Good Parts:

1) Explaining the language syntax and structure.

2) Exposing all the little gotchas in the language.

"JavaScript: The Good Parts" : The Bad Parts:

It's too opinionated. Crockford has this style of presenting multiple ways of doing things, e.g. inheritance, culminating with his cute little way.

I'm not surprised a Java developer would love the book, because Crockford evaluates the merit of the strategies he presents by how close they come to implementing Java in JavaScript.

I've written my first large JS application over the past year and by far, my biggest struggles have been with performance, documentation, and catching nasty syntax errors. Private variables and information hiding? Not so much.

What's helped me the most is dumping all of Crockford's opinionated suggestions, and using the Closure Compiler. I get great static code checking for errors, and their JSDocs are top notch. JSDoc won't work with functional inheritance, only prototypical, but the tradeoff is totally worth it, because I get beautifully formatted HTML docs for all my code.

Re: closure compiler, not to mention dead code removal, type checking, conditional compilation via @define, function inlining, and a configurable flood of useful warning and error messages. I, too, dumped Crockford for Closure on a large web app and have been thrilled.

> The fact something such as CoffeeScript can generate running, valid JavaScript is a testament to it's flexibility.

s/Javascript/Brainfuck

It's not all bad, but even overlooking Standards and DOM issues, the language itself has some not insignificant, bug causing issues, as brought up in some other comments. Compiling into a strict subset of an interpreted language shouldn't be considered a sufficient alternative to a real VM, or a language without those flaws.

ActionScript has changed a lot. ActionScript 3 shares a core with JavaScript, and it still supports closures and prototype-based inheritance. If you insist. But the thing is, nobody uses those features anymore. Class-based inheritance and encapsulation are so much nicer to use. Most modern ActionScript 3 code looks like Java.