It does not however, preclude the possibility that the tool is in fact a bad tool, and that the tool is bizarrely the only tool we have.
They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter how skilled I am.
I for one am hoping for a replacement for JS (that isn't Dart, which feels like JS Patched). I have more than just a hairy experience with JS lately.
Seriously your analogy is absurd. JS has a few rough edges that any decent editor will warn you about and that you automatically know to avoid after doing a lot of it for even a couple months.
This complaining that JS is unusable is just BS and whining by people who are simply shying away from something they don't know.
There are bigger things that can bite even experienced developers like memory leaks and bloat but that has little to do with JS since you can fall into those pitfalls in any language.
I'm not attached to JS and have pretty much switched to CoffeeScript. I like CS better but that doesn't mean JS is anywhere near as bad as you make it out to be.
Coding JS is 95% of my day job and I'm 100% sure that it is the worst language I have ever used. All languages have flaws but JS's are serious, inexcusable and onerous.
But JS isn't just a tool. No programming language is.
JS is more a workshop that happens to contain, amongst its stations, a less-than-safe circular saw. And you can absolutely, productively use the shop without using the saw, or by using the saw, if necessary, with additional safety precautions.
And because some people use the saw willy-nilly, you're saying we should throw out the whole shop?
I agree that it's a bad tool in many ways, but even if the language (and environments) were beautiful, the problem at hand is often the way that people use it.
In this case, a poor craftsman uses his tools to do the things that the browser already does for you.
I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.
If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.
Fortunately, JS is not the only tool we have. JS is a relatively fine compile target, and with asm.js, a pretty fast one.
So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM.
Let a compiler take care of all the numerous rough edges raw JS has.
I have never really understood this. JavaScript it is a a programming language and the only reason people built languages that compile to it is because they felt the needed something better, but this has always seemed incredibly hacky to me.
And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a strictly defined ASCII-encoded bytecode that happens to be representable using a subset of valid JavaScript.
At which point, one must ask, what bizzaro-world engineering justification do we have for using a JavaScript subset as a first-order bytecode format? Why couldn't the silly JS bytecode format be a second-tier target for legacy browsers that don't support a proper format?
On top of which, why are we willing to throw away 2x+ performance (in the best case)? Is the iOS/Mac App Store not successful enough for us, such that we absolutely refuse to try something other than adding more JavaScript to every problem we face with web app deployment?
asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.
The 2x performance numbers for OdinMonkey are not "best case": they include compilation time and will certainly improve (they are better now already).
Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.
> asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.
No, it's a strictly defined text-encoded bytecode that happens to be representable using a subset of valid JavaScript. If you deviate from the standard using valid JavaScript, you lose the gains.
Calling it "JavaScript" is just a semantic game. You can't output arbitrary but fully 100% standards-compliant JavaScript from a compiler and expect asm.js to do anything meaningful.
> Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.
The irony is that these things fail because of the people who wish to maintain the status quo, and then those same people point to the failure as justification for maintaining the status quo.
It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.
> If you deviate from the standard using valid JavaScript, you lose the gains.
That's true for lots of JavaScript optimizations. JS optimization is all about speculation that the more dynamic features won't be used. Try adding calls to "eval" within a JavaScript function in any modern JS engine and watch its performance drop by an order of magnitude. Does that make functions that don't use "eval" no longer JavaScript? After all, adding a call to the standardized function "eval" negates the performance benefits of "eval"-less JS.
asm.js is just this principle writ large.
> Calling it "JavaScript" is just a semantic game.
No, it means that asm.js is backwards compatible. That is not a game; that is the entire point. That is why asm.js worked in Chrome (with good performance even!) from day one.
> It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.
Because PNaCl is not a good idea for Web content. People have this idea that Mozilla knows PNaCl is "better" than asm.js, but Mozilla wants to stick to JS out of some sort of pride or NIH syndrome. This is not the case. Backwards compatibility is the main advantage of asm.js, of course. But there are also many others: LLVM IR is a compiler IR and was not designed for this; asm.js is smaller when gzipped than LLVM bitcode; asm.js compiles faster than PNaCl; asm.js can reuse the JavaScript infrastructure, leading to a smaller, simpler browser; asm.js does not have the Pepper API which reimplements all of the Web APIs in underspecified ways.
Maybe it's time to go back to the HotJava[1] approach and use Java bytecode as the canonical "bytecode for the Web".
OK, to be fair, the browser itself doesn't really need to be written in Java. But other than Javascript, (and maybe Flash, I suppose) Java bytecode probably has the most penetration as a mechanism for delivering "programs" over the web. Maybe we should just embrace it...
Here's the painful part: Douglas Crockford wrote a book called Javascript, the Good Parts.
If Javascript were limited to The Good Parts alone, it has the potential to be a beautiful well thought out language. It would be quite close to a beautiful well thought out language
What's stopping you from only using the "good parts" in your own code? How is JS a bad tool? It runs reasonably fast, works everywhere, is a small, simple language that's surprisingly powerful. What if Eich had been influenced by C instead of Lisp when creating JS?
All things considered, it could have been way worse than it is, and the truth is JavaScript lets you get in there and do good stuff. Not sure why we are still hating on this environment.
I think a lot of experienced developers are only using the good parts, it's difficult to learn but it can indeed be a very beautiful language when you use it with modules/jsLint/jsHint.
On our svn repo (team of 20 js devs) i've added jshint checking in a precommit hook. Devs who don't follow the rules literally cannot commit code. It was much less of a big deal than you would think.
Agreed... I only had to do a couple tweaks to my jshint rules (I prefer comma first, and a few other things)... but it wasn't hard to get used to at all.
Testing is another point... having JS tests can help a lot, though my opinions of TDD aren't as strong as many.
To be fair, Crockford gives his reasons [1] and the replacement is literally += 1 instead of ++. Given the very low cost of the change, and that it is an optional rule in jslint, I have no problem with it.
True, but for me the issue is that with += I have to double check that it is only adding one (and not skipping any) to understand the loop, where as ++ is something I have seen so many times that my brain reads it in a different way.
I know you are just making a point with the circular saw metaphor, but for those wondering here is some good info on how to use a circular saw as safely as possible:
Yeah JavaScript has problems, so do all programming languages. JS has some particularly egregious ones, but the abuses and problems the slide complains about are not a symptom of a defect with JavaScript. They would be the same problems with any other language being used by incompetents.
I like to think of it this way: Some languages allow you to shoot yourself in the foot easier than other languages, given the context and environment.
Abuses and problems precisely show Javascript's defects. The more easily abusable a language is, the more defective it is.
A lot can be said about familiarity with the language. Many examples in wtfjs.com boils down to (mis)understanding the language itself. Let's call this the cognitive overhead of a language - the amount of corner cases you have to store in your head about a language.
Surely a language with high cognitive overheads is more abusable than languages that have low cognitive overheads.
Incompetent python, C, or even scheme programmers wouldn't be able to shoot themselves in the foot (by shooting themselves in the foot, I mean having unexpected results - even with Undefined behaviours) as much as incompetent javascript programmers. That's my beef. I currently have no way of empirically proving that, but my gut is leaning that way.
You are 100% wrong. C allows you to shoot yourself in the foot much more easily and much worse than JavaScript. JS is a far more "safe" language to code in.
No pointers, no memory allocation. Yeah JS isn't typed but the problems that you get into with that are nothing by comparison.
And again, I'm not saying JS doesn't have problems, it does. But the problems this presentation is complaining about are not results of flaws in JS they are results of incompetent developers.
So he's complaining about the wrong thing by complaining about JS.
It should be titled "I wish incompetent people wouldn't try to do things." And we'd all agree but then consultants like him would be out of a job.
FYI, Nicholas Zakas, the person who gave this presentation (which I attended) is a well-known JavaScript expert. He's definitely not complaining about JavaScript as such, just horrible misuses of it.
That's semantics. He didn't get the "basic stuff wrong in a single paragraph" at all. Bu not having to worry about pointer or memory allocation at the the point of coding, it is entirely reasonable to say that JS the language has none. Yes, of course the interpreter does that, it goes without saying. JS is weakly typed, when writing no type declaration is needed, so it is said that JS isn't typed. Your comment is akin to that of a grammar pedant by not addressing the argument, just the manner in which the points were made.
The parent probably shouldn't have included C and Python in the same list but if you apply the principle of charity[1] and choose Python as the point of comparison rather than C, then his argument is somewhat stronger.
You speak very confidently about a language you already admitted you refuse to use. And your heuristic of "the more abusable a language is, the more defective it is" is completely nonsensical.
I don't think the article is knocking JS, it is knocking the over/miss use of JS on the client side. So, yes, any other language would have the same problem, but to take this as another "JS suckzzz" article misses the point.
Ironically, if they hadn't we'd probably be using something much nicer by now. Closures are one of those couple features that made idioms for sane JS programming possible.
They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter how skilled I am.
I for one am hoping for a replacement for JS (that isn't Dart, which feels like JS Patched). I have more than just a hairy experience with JS lately.