Great post, it's just annoying to hear people ranting about JS over and over again. The most annoying fact is, most of these people don't know how to write anything useful in JS besides copy&pasting a few lines a jQuery code. (I have doubts whether it's possible with this knowledge to understand how modern webapps are working.)
In the recent time I've often read posts about people suggesting: learn language X to a reasonable proficiency before you criticize.
In my experience, those who criticize JavaScript the most have often used it for many years, and know it extremely well.
These people also usually have many years of experience with other, far more sensible programming languages, too. I'm not talking about PHP or Ruby, either. Rather, these people know one or more of languages like C, C++, Objective-C, Java, C#, Haskell, Erlang, OCaml, Standard ML or Python inside and out.
With such knowledge, it becomes very obvious just how bad JavaScript is. The utter stupidity of many of its flaws becomes so apparent. These people also can see how it lacks the language features necessary for large-scale, multi-developer, distributed development, and then the subsequent maintenance of such projects. They've felt the pain of its numerous other problems time and time again.
I'd say the reality is much the opposite to what you describe. The ones who advocate JavaScript most often have never used anything else. They don't realize how many of JavaScript's inherent problems, or "quirks" as they like to call them, just don't exist in most other programming languages. If they have used another language, it's usually PHP, which is arguably worse than JavaScript in many ways. While living in this bubble of ignorance, they don't see JavaScript's flaws for what they truly are.
You should perhaps focus on adding value to the discussion, than going on about people you hardly know anything about.
JS and Python offer comparable expressiveness for most programming tasks: basic imperative language features, first class functions, closures etc. If you miss list comprehensions, a better syntax for lambdas or classes, go ahead and use the favorite JS shorthand - coffeescript. It _really_ is JS. Even if you don't use coffee, having first class functions would let you write some of those missing features in a library (albeit with a slightly clunkier syntax).
Sure there are nuances, like scoping rules. On the plus side, having a single programming language on the server and client saves some time. Also, most of the libraries being async in nature helps in typical I/O heavy apps.
I draw these inferences from a medium sized JS project I have going on at http://www.poe3.com (source: https://github.com/jeswin/poetry-source). I am fairly convinced that JS did save me a lot of time. Interested in seeing how you came to your conclusions.
You're using C as an example of an "unflawed" language?
Wow.
Don't get me wrong, C is outstanding in its problem domain, but it certainly has no shortage of rope with which to hang yourself.
"These people also can see how it lacks the language features necessary for large-scale, multi-developer, distributed development, and then the subsequent maintenance of such projects."
I said "far more sensible", not "unflawed". Please don't misquote me.
And, yes, C is a far more sensible programming language than JavaScript is. C may not be perfectly defined, but at least it isn't full of stupid gotchas like JavaScript is. C doesn't bungle such basic things as equality checks, for instance. C also doesn't include idiocy like semicolon insertion.
C can be risky to use in some cases because it offers an extremely high degree of power and flexibility to the programmer.
JavaScript is risky to use in all cases because it is rife with design mistakes and other inherent flaws that make it much too difficult to write reliable, maintainable code.
You were comparing Javascript with the "utter stupidity of its many flaws" to "far more sensible" languages.
"C doesn't bungle such basic things as equality checks, for instance."
2.0 == 2?
False.
Most people would consider that a flaw. As programmers we understand that integers and floats are different in the computer, but that's not how it works in math.
"C also doesn't include idiocy like semicolon insertion."
You must really hate the languages that don't use semicolons at all. :-)
"==" implies that one can be substituted for the other at will without changing the result. In C, that's not the case for 2 and 2.0.
Compilers have gotten a lot better about warning about these situations, but they're far from perfect. In any case, "produces a compiler warning" and "doesn't produce a compiler warning" isn't "==" behavior.
We won't even go into why having a logical comparison return an integer result is questionable. Yes, it's very convenient sometimes, but it's still an example of the type of
"flaw" that he doesn't like in Javascript.
>> In the recent time I've often read posts about people suggesting: learn language X to a reasonable proficiency before you criticize.
Hard to disagree with this. That said, I think even JavaScript guru's generally agree that the language itself is actually pretty awful unless you know all of the legacy quirks and WTFs it is dragging along.
When discussing the merits of programming languages, the observation that "JavaScript is the best we have for browser-based development" or "it's possible to write really awesome things with JavaScript" just doesn't cut it for me. Either you acknowledge and accept JavaScript's deficiences and don't try to sugar-coat them, or you refrain from trying to objectively rank it against other languages at all.
My personal opinion is that you simply cannot reasonably maintain that JavaScript is a 'good programming language', for the simple fact that before can say you are proficient with it, you likely have had to deal with multiple WTF's you'll never run into with (most) other languages. Other dynamic VM-based language exist that are much better than JavaScript, but just like the QWERTY keyboard layout, we're stuck with it.
> I think even JavaScript guru's generally agree that the language itself is actually pretty awful unless you know all of the legacy quirks and WTFs it is dragging along.
Are you confusing pure JS with DOM APIs and xbrowser quirks? Pure ES5 (or 6) is actually a very lovely language to work in, and now thanks to Node, we can.
Maybe I'm just so used to the quirks that I don't see them as a problem any more.
> Maybe I'm just so used to the quirks that I don't see them as a problem any more.
To jog your memory, here's a list of questionable design decisions I can think of off the top of my head:
Automatic semicolon insertion and a broken == operator
A language shouldn't try to guess the programmer's intention, but rather fail cleanly on ambiguous cases.
Function scope and global by default
Frankly, I'm appalled by how many dynamic languages get it wrong. Lexical block scoping with mandatory declarations are by far the most sane approach I've come accross, and the only P-language (Perl, Python, PHP with Ruby and Javascript as honorary members) that gets it right is (strict-mode) Perl.
Weird object system
While actually protypal, the constructor-with-prototype-property semantics add a pseudo-class based overlay without an obvious mechanism for object extension and code reuse.
- Add semicolons, if that's what you prefer.
- If you needed type checking, use ===.
- Function scope and object system, what's wrong with it?
These things don't matter in practice, although we could go on arguing about them. If a language has basic hygiene like first class functions I can build apps with it.
I do, but others disagree. My point is that when parsing fails, insert a semicolon and try again doesn't look very appealing from my personal criteria of language design.
- If you needed type checking, use ===
Which was added to the language after it was realized that the original semantics of == might not have been that well thought out.
- Function scope and object system, what's wrong with it?
Block scoping provides a finer level of encapsulation than function scope. Do you think `let` was added to the language (JS1.7, ECMA6) just for the heck of it?
As for the object system: Instead of using one of the well-known approaches (protoypal with cloning or class-based with inheritance), JS comes with a weird hybrid system inferior to both. Of course JS allows both approaches, but does not provide syntactic support for either, which makes them clumsy to use and open to fragmentation.
It's very easy to brush all of these as "don't matter in practice" or "just use <insert sane equivalent of ...>", but if we go that route, almost any language can be considers 'good enough' to write code in.
I see 2 problems with this point of view:
1) Ever programmer sometimes makes mistakes, such as forgetting a semicolon, or writing '==' instead of '==='
2) This assumes that anyone writing JavaScript knows about all these gotcha's
We can sit here all day arguing about 'how bad' some of the things JavaScript does or does not, but that's not the point. Most other languages have none of these issues, and if tomorrow somehow all browsers on earth would magically be able to run some kind of clean alternative to JavaScript, I'm pretty sure everyone would immediately jump on it.
> Hard to disagree with this. That said, I think even JavaScript guru's generally agree that the language itself is actually pretty awful unless you know all of the legacy quirks and WTFs it is dragging along.
Sure, Crockford is probably the best example. But the same is true from many languages that became popular before 2000. C is notorious for its pointer magic and buffer overflows. C++ is notorious for being an "expert language" that takes years to master. Java is hated for being very verbose. I know someone, long term (Ex-)Rubyist, hating the language for not scaling well and being hard to debug.
Maybe I'm too pragmatic but I think in every language there is something to hate. (Haven't seriously tried C# though ;)
I think at the end of the day the libraries make up at least 50% of the overall language experience. In the recent years JS has got a number of high quality libraries like jQuery or underscore.js that transparently circumvent many behated JS features. Like awkward checks for undefined or consistent and easy DOM manipulation.
IMHO C++ is a good example for a language in which libraries can hardly make up for the deficiencies because the language is so complex. JS on the contrary does not have so many rules.
I have written multiple large JS apps as part of my day job (and I still have to) and I think while JS has some cool features, and I even enjoy using it sometimes, it is mostly a dirty hack.
When you consider the circumstances under which Javascript was created and grew up, it's nothing short of a miracle that we have a language with the functional power of JS. Sure it's warty as all hell, but prototypal inheritance plus closures give you architectural flexibility that would be the envy of many "better" languages.
In practice, we've seen its prototype-based OO functionality be a burden, rather than a benefit. In any sizable JavaScript code base, there is usually a lot of code and effort put into faking a far more sensible and practical class-based approach to OO. This often obfuscates the code significantly.
This is part of the reason why languages like CoffeeScript and TypeScript have become popular. They offer the tools that developers actually need, rather than just telling them, "you should be using prototype-based OO because it's good".
Arguably that's just because people aren't used to prototype-based OO, but in any case, it supports these custom pseudo-class-based OO constructs just fine doesn't it?
No, it's because JS doesn't expose (or at least didn't used to before ES5) it's prototype system, but instead provides a pseudo class-based overlay.
The proper way to do inheritance in JS is
// Foo extends Bar
Foo.prototype = Object.create(Bar.prototype);
function Foo() {
Bar.call(this);
}
Before the introduction of Object.create, you either had to roll your own version, assigned a dummy instance of Bar to Foo.prototype (which is horribly wrong) or transferred methods manually from Bar.prototype to Foo.prototype, which is arguably more 'in the spirit' of JS1.0.
That's not how it's done in 'real' prototypal languages like Self or Io.
No, it does an absolutely horrible job supporting anything that resembles class-based OO. That's why so much JavaScript code is utterly unmaintainable. It doesn't offer the functionality that developers want and need, so they have to fake it, and this can only be done very poorly.
I don't know if I've ever seen prototype-based OO used to produce something that dynamically-typed, class-based OO couldn't accomplish in a much more comprehensible manner.
Well devs are ranting about JS because devs dont have the choice to use javascript or not period. Programmers dont like to be forced into something yet they cant avoid javascript as it is the only language that will work in most of the browsers.
It doesnt make javascript a good language , in fact it is not. It is a poorly designed language that should not have survived the 90's, and if it would have been invented today it would have been different beast. Is there some good stuff in it ? sure, but the irony is it is used to code against the DOM which is strictly typed and made of classes and interfaces( that's the why of DHTML , because it made no sense to use that language against that API ).
Now People can rant about it all they want it wont make a difference , browser scripting = doing some javascript , wether one likes it or not.
In the recent time I've often read posts about people suggesting: learn language X to a reasonable proficiency before you criticize.