Global variables make it harder to run independent subprograms in the same program. If the subprograms happen to have global variables that share the same names, then they will interfere with each other and likely fail, usually in difficult to diagnose ways.
* Newlines get converted into semicolons. JavaScript has a mechanism that tries to correct faulty programs by automatically inserting semicolons. It sometimes inserts semicolons in places where they are not welcome.
* Operator typeof is not very helpful. For example, "typeof null" is "object", "typeof [1,2,3]" is also "object".
* Operator + adds numbers and concatenates. The + operator can add or concatenate. Which one it does depends on the types of the parameters. If either operand is an empty string, it produces the other operand converted to a string. If both operands are numbers, it produces the sum. Otherwise, it converts both operands to strings and concatenates them. This complicated behavior is a common source of bugs. If you intend + to add, make sure that both operands are numbers.
* Operators == and != do type coercion. Use of the === and !== operators is always preferred.
* Too many falsy values. 0, Nan, '' (empty string), false, null, undefined are all false.
* for ... in operator mixes inherited functions with the desired data members (it does deep reflection).
Nice list. One of the things that CoffeeScript manages to do, with greater or lesser success, is to avoid many of these "bad parts":
* Global variables can no longer be created by accident ... you must explicitly `window.global = ...` them.
* Semicolons are gone, along with the headaches of automatic semicolon insertion.
* I'm afraid that not much can be done about `typeof` without a more invasive replacement, unfortunately.
* The + operator continues to work the same way.
* CoffeeScript does not have `==` or `!=`, only `===` and `!==` for strict equality comparisons. In the one location where `==` can be helpful, checking for either null or undefined, you may use the existential operator.
* When dealing with too many falsy values, there's an existential operator, which allows you to ask the question: Does this value exist? (Is this value not null or undefined?)
name = ""
if name?
# Exists, so this will run.
* There's a shortcut to only list the "own properties" when iterating over the keys and values of an arbitrary objects, without including members from the prototype chain:
for own key, value of object
alert key + ": " + value
Because we also do "toll-free bridging", you can ask if strings are CPStrings, numbers are CPNumbers, and arrays are CPArrays (though we don't toll free bridge null to CPNull, which we probably should).
So, we actually have this feature where we "bridge" windows: you can basically tell a CPWindow to map to an actual browser window. And we implement it as a display only thing, so all of your actual code runs in the parent browser window and just manipulates the DOM elements in the child window. It doesn't completely work in IE I think, but I haven't tried in a while (it's kind of an experimental feature, but it's been in the release for a while).
I agree with most of Crockford's recommendations (and use jslint) but it's impossible to create a controlled experiment in which JavaScript was created without globals (or globals requiring declaration and locals being implicit) and inferred end-of-statement and find out if it would have been as popular. Globals make total sense to newbies, and avoiding them is not hard if you're not a newbie.
(HyperTalk, if I recall correctly, had local variables by default and global variables explicitly, and was -- I think -- even more newbie friendly than JavaScript, so it's possible that JavaScript might have thrived.)
It's not like coding in ActionScript is noticeably more pleasant than coding in JavaScript despite being controlled by a single vendor. And the dedicated ActionScript editor in Flash is far more annoying than a simple text editor.
Anyway, "abominable" is a ridiculous word for a language that has so many broadly consistent implementations, is so approachable, and yet supports so many modern programming concepts with a compact and approachable syntax.
> (HyperTalk, if I recall correctly, had local variables by default and global variables explicitly, and was -- I think -- even more newbie friendly than JavaScript, so it's possible that JavaScript might have thrived.)
That's what Python does, it has its own severe failings (especially when the language is lexically scoped). I like dynamically typed languages, but I've come to the conclusion that scope inference is terrible, and variable scoping should always be explicit (and probably statically checked as well), trying to infer variable scope will fail silently and badly.
The problem with making scope always explicit is that you then need to explain scope to newbies. Sure, it's worth explaining, but you just lost half your audience.
Based on the success of BASIC (and indeed many, many early programming languages), global variables are easy to understand, local variables are less easy to understand. It's all very well to complain about JavaScript's lack of Important Language Feature X, but it's an easy language to learn and use for simple things and yet it's also pretty damn good for complex things (especially in combination with jslint).
Along with many other Language snobs, I used to despise JavaScript, but it's the inconsistent DOM implementation that sucks -- IE's in particular -- along with some annoyances you can work around (like truthiness) that are the real issue; once you code with JavaScript and jQuery the DOM goes away and you're left with a very nice coding environment.
Compare that to ActionScript 3 and the byzantine Flash/Flex (and constantly changing) class library and then decide which one deserves the adjective "abominable". And bear in mind AS3 completely broke compatibility with AS2 without actually becoming better organized.
> The problem with making scope always explicit is that you then need to explain scope to newbies. Sure, it's worth explaining, but you just lost half your audience.
That's a price I'm willing to pay for the pain it brings later on.
> Based on the success of BASIC (and indeed many, many early programming languages), global variables are easy to understand, local variables are less easy to understand.
It's not like explicit scoping prevents users from abusing globals...
> It's all very well to complain about JavaScript's lack of Important Language Feature X
Actually, if you read my comment instead of going off about an alternate reality comment you may notice I'm complaining about a feature of javascript I think is misguided, not about the lack of a feature.
> Along with many other Language snobs, I used to despise JavaScript
I never despised javascript. Still don't. But after a decade of development, as I've said I've come to view scope inference as a misfeature.
> Compare that to ActionScript 3 and the byzantine Flash/Flex (and constantly changing) class library and then decide which one deserves the adjective "abominable".
I don't think I have used the adjective "abominable" anywhere, and I really don't care for ActionScript under any of its forms.
The worst part about these issues is that they aren't consistent, and fail completely silently. Global variables cause heisenbugs - you'll only notice when there's a collision, such as after compressing your script. The ==/!= operators and falsy values just put you on the wrong side of an if-statement. The for...in operator sometimes just loops a few extra times. The coercion and overloaded + operator will just sometimes give you a wrong number if you forget to caste an input:
> The worst part about these issues is that they aren't consistent, and fail completely silently. Global variables cause heisenbugs - you'll only notice when there's a collision
Firefox has had the ability to warn about implicit globals for quite some time now, and strict mode will error out when encountering an implicit global being created.
> Too many falsy values. 0, Nan, '' (empty string), false, null, undefined are all false.
I disagree with that, actually. I like that many Python objects can be used in a boolean context and behave sensibly, and that this behavior is accessible to user-defined-types.
On this point, Javascript annoys me because on some things it works as Python (empty string) whereas in others it does not (empty array).
> for ... in operator mixes inherited functions with the desired data members (it does deep reflection).
It does not do any reflection, really. It just iterates on all enumerable properties of the object, inherited or not.
It's more idiomatic in python to just test for truthiness (i.e. "not x" rather than "x is False"). There aren't a lot of cases where you'd want False to be false but not None, 0, or an empty container.
True. If I'm expecting a bool and just writing is True to program defensively, what I should really be doing is assert(type(x) is bool) if I want to make sure I was given a boolean value or x = bool(x) if I want to make sure I'm outputting bool.
Actually the problem with automatic semicolon insertion (ASI) is the opposite: It sometimes doesn't insert one where you expect it. ASI only inserts a semicolon when not inserting it would give a syntax error. It's the cases where a newline was really intended to end a statement, but doesn't, the bites you.
Example ()creating a generator:
var gen = null
(function() {
var ctr = 0;
gen = function() { return ctr++; };
})();
Seems simple, but actually tries to call null as a function.
Also, the + operator doesn't treat all non-numbers as strings. It tries to treat all non-strings as numbers, if possible. Only if that fails does it try them as strings. If either argument is then a string, it does concatenation.
IMHO the worst problem with JS is too losely defined standard - typeof on array or on function on some implementations return Object, on some other something different, you often have to check for type of argument (when coding function that would be overloaded in languages that support this concept), and properly doing this is pain (checking is something is array is often done by checking if it has "length" property!).
Still, JS is perfect example of how important closures are for programming language - they make very bad language acceptable.
> typeof on array or on function on some implementations return Object, on some other something different, you often have to check for type of argument
You should not be using `typeof` on object types (and this includes functions) anyway. Use `instanceof`.
> and properly doing this is pain (checking is something is array is often done by checking if it has "length" property!).
This really checks if something is array-like (for instance the jQuery object would pass this "test", even though it's not an array. Likewise for `arguments` or a NodeList)
There's nothing useful you can do against that kind of stuff, so I'd recommend you just document your API correctly and if people want to be stupid, them's the break.
I mean nothing stops a java developer from implementing a List throwing some kind of NotImplementedException everywhere (in fact, using `java.util.Collections.unmodifiableList` would be sufficient as that's exactly what it does: throw UnsupportedOperationException on every access to a mutation method, so it's going to blow up any time it's passed to an API which wants to modify the list it's given)
Not sure I follow the logic of this article - starts with closures, moves on to somehow conditionally endorse Flex/ActionScript, references you off elsewhere without being specific, talks about closures again, then complains about standardisation with Browsers in general (W3C and CSS) included.
What's the beef here? Does ActionScript (JavaScript's ECMAscript cousin) provide something that JavaScript should have? Admittedly ActionScript does hide a lot of the nastier parts of prototypical inheritance / closures / etc from you, but you also lose a bit of power in that. From a pure language point of view the two also have a lot in common.
Part of the argument is around standardisation and varying implementations - and on the same for the APIs rather than the language - but that's another debate entirely... and probably one that has little to do with the use of closures.
Probably some valid points here, but I can't see it making any conclusion to take away.
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.
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.
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.
Disappointing post from someone who really should know better - he confuses JavaScript with the DOM and other things in several places (i mean really... is he suggesting that JavaScript should have some native capability to "include standard headers and footers on a web page"?). Maybe a better title would be "Bruce Eckel on the W3C / DOM", as that seems to be the primary target of his negativity.
Every language has bad parts. If you're going to call something an abomination, you should at least take the time to understand what you are talking about first, lest your opinion be cast aside as another uninformed rant.
He used the lack of standardized ways of inserting headers and footers as a example of the ineffectiveness of the W3C, not as part of his critique of JavaScript.
"Interestingly, the Google Apps Scripting language appears to be a (civilized) form of JavaScript, and it looks very powerful"
This doesn't really compute. Google Apps Script is a (very cool) JavaScript API to interact with Google Apps. It's not a replacement for JavaScript, it's not a language at all.
"you read it you begin to understand why it's taken so long for AJAX libraries to appear"
It did take a long time, but libraries have been around for many years now (e.g. Dojo since 2004 and jQuery since 2006).
Saying that, the article has a valid point about the language being hard to use without such libraries. The trends in the video he linked to ("Learning to Love JavaScript") will begin to address that, but it will take time. There's the risk of browser fragmentation and the large legacy base.
For a newcomer, it's clear that JavaScript's inconsistencies between browser's implementations is a real burden. I learned to love JavaScript, but I'll not ask everybody to do so.
FWIW, javascript implementations all behave very similarly surprisingly.
There are some quirks of course, like JScript not accepting trailing commas, not allowing array like access to strings and leaking out the names of named function expressions, or like some nastiness in IE behaviour with the global object and window.
Especially considering the history of javascript, it's a miracle we're having it this good.
Not so much with the DOOM.
After starting out with Ruby, I now prefer Javascript to Ruby for a number of reasons, not least performance, clarity, ubiquity, and expressive power.
Sometimes I think the detractors are more upset with their own lack of facility in Javascript relative to their proficiency in something else, than with flaws in the language itself.
A penny for every "accidental global variable" and "ugly {".
Sure, but the guy freely admits that he is not yet very experienced with Javascript. My own personal experience with it was definitely love/hate for the first 6 months or so, but once I started figuring out what idiomatic Javascript looks like, it started seducing me. My current project is a roughly 50/50 split of Javascript and C - at the start I preferred to do things in C if possible, and avoid Javascript, but now the reverse is true.
My JavaScript experience was similar. I blame it on the name, stupid as that sounds, because the first thought of a newbie is likely to be 'Oh, this is like Java'.
As JavaScript syntax is similar to Java at a glance, this leads one to try and write Java-like programs, which end up being a hideous mess, because of course JavaScript is nothing like Java. Once you get the light bulb moment when you realise 'hey, this is Lisp!' (though an extremely limited Lisp), your approach to the language changes instantly, and it actually becomes quite elegant in its own way.
Also, JQuery. JQuery, JQuery, JQuery. Removes entirely all the browser-dependent annoyances and all the DOM annoyances. Don't even think of writing JavaScript in web pages without it!
> My JavaScript experience was similar. I blame it on the name, stupid as that sounds, because the first thought of a newbie is likely to be 'Oh, this is like Java'.
Even worse, because JavaScript is one of the few languages that people think they can use without actually learning it, because it was somehow designed to be that way: an easy to use scripting language. Copying and pasting small snippets from the Web adds insult to injury, so that someone might claim to know JavaScript after working out some issue with the help of a JQuery plugin (Not that I'm against JQuery, I use it and love it, I'm talking about people not learning JavaScript at all, due to the easiness of JQuery possibly.)
The thing to realize is, as you mentioned, and as Crockford says, JavaScript is Lisp in C's clothing; I'm not sure where Eckel got the idea that JavaScript is an abomination, reading Crockford's book should make someone think that JavaScript is an elegant language.
Aren't like half of those projects designed to normalize the language? And a third of them are actually written in C, not JavaScript? I guess your comment is technically neutral, so I don't really know what point you were trying to make. But I assumed it was a refutation of the article.
Perhaps "language" was the wrong term, but "execution environment" might work. jQuery allows one to treat browsers uniformly so you're not dealing with DOM quirks all over the place. CoffeeScript is designed to basically replace JavaScript syntax. CPAN wouldn't really be a fair comparison, but boost would be.
He's not really wrong about anything, but none of this is novel or insightful. We're all set on "JaveScript[sic] is an Abomination" and "CSS -- who thought that was a good idea?" rants.
That last quote just makes him sound crotchety. I guess he wants all these dang web developers to get off his lawn.
Javascript != Java; it doesn't mean it's an abomination. I do agree that there are pitfals.. but damn, get over it as it's such a beautiful language. I love JavaScript.
I feel like the guy just read the book of Crockford and just got it all wrong.
While he did write the Java books we're all familiar with, Bruce has abandoned that language and doesn't speak kindly of it. He's largely been all-in with Python, although he recently had some kind things to say about Scala. In any event, I'm quite certain he's decidedly not looking for anything that looks like Java.
* Global variables.
Global variables make it harder to run independent subprograms in the same program. If the subprograms happen to have global variables that share the same names, then they will interfere with each other and likely fail, usually in difficult to diagnose ways.
* Newlines get converted into semicolons. JavaScript has a mechanism that tries to correct faulty programs by automatically inserting semicolons. It sometimes inserts semicolons in places where they are not welcome.
* Operator typeof is not very helpful. For example, "typeof null" is "object", "typeof [1,2,3]" is also "object".
* Operator + adds numbers and concatenates. The + operator can add or concatenate. Which one it does depends on the types of the parameters. If either operand is an empty string, it produces the other operand converted to a string. If both operands are numbers, it produces the sum. Otherwise, it converts both operands to strings and concatenates them. This complicated behavior is a common source of bugs. If you intend + to add, make sure that both operands are numbers.
* Operators == and != do type coercion. Use of the === and !== operators is always preferred.
* Too many falsy values. 0, Nan, '' (empty string), false, null, undefined are all false.
* for ... in operator mixes inherited functions with the desired data members (it does deep reflection).