JavaScript the Good Parts Using JSLint

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas Crockford: So the JSLint style was driven by the need to automatically detect errors. I started by going on comp.lint.javascript and there was a constant stream of people saying, hey, my program doesn't work. Can someone tell me what's wrong. So I'd take their code and I throw it out in JSLint.

[00:00:20] And sometimes it would say there is a problem boom. And sometimes it couldn't, and then go okay so what do I need to do to JSLint in order to help it find it. And in some cases I discovered that there were things in the language that if I allowed their use, those things could mask other errors.

[00:00:43] So, the comma operator for example. You can write all sort of clever stuff with that. But, it's more likely to be, or sometimes can be a bug and you can't discover the bug if you assume that comma is an okay thing to use. So, okay we're not gonna do that with the statement similar thing.

[00:01:00] So I started removing things from the language, which turned out not to be necessary because there were easier alternatives to all of them. But simply by removing them from the language made it easier to find other defects. So if a form could be used to hide defects, I consider that itself to be a defect.

[00:01:19] It took me a long time to figure this out. So I didn't write JSLint with an intention of imposing my ideas of style on the world. It was a tool for me and JSLint told me what good style was. So the approach I took was Language Subsetting. That, yeah it's been said only a mad man would use all of C++ because it's such a grotesquely huge language.

[00:01:47] It's also been said only a mad man would use C++ but that's for another time.
>> Speaker 2: [LAUGH]
>> Douglas Crockford: But so every language designer makes mistakes. So generally they'll start with some good ideas and inspiration from some other languages. And maybe some insight that if I combine that with that and put them together I can do some interesting things.

[00:02:10] And they might come up with some new ideas of their own and put them on there. And all of this is done with good intentions. And if they do a good job, they are going to have a new language and it's going to have remarkable features and its great.

[00:02:23] But invariably they'll make a mistake. They'll put some things together and go, that turned out not to be a good idea. But if the language becomes popular, they can't take it back. Cuz the problem with these bad features isn't that they're useless. It's that they're dangerous. And clever people will always find a use for it, for anything.

[00:02:47] And once it gets out there, once it gets used, you can't take it back. So the errors in the language design are locked there forever. Now if you're lucky as a language designer, no one will use your language. In that case you continue to have freedom to do whatever you want with it.

[00:03:03] You can go yeah that was wrong and fix it. But if it becomes popular, in the case of JavaScript it's one of the world's most popular programming languages now, you're stuck. You can't fix it. But you can, as the user of the language. You can look at each of those features and decide which are beneficial for you and which are more likely to increase your error rate.

[00:03:24] And make choices as to what subset of language you want to use. So you have a power that the language designer does not have. So the argument that if it's in the language, it's there for you to use doesn't make sense. That you have a higher responsibility, a higher freedom than that.

[00:03:43] You don't have to use that stuff. I'd like to say a few things about performance. Performance sometimes works, or concerns about performance sometimes work directly against programming style. Now performance specific code or optimized code tends to be crafty. Lot of the generality gets removed from the code. More special casing gets hardcoded in to the code which makes the code likely to be more buggy and makes it less agile.

[00:04:14] Makes it harder to modify that code going forward or harder to reuse for other purposes. So you don't want to optimize until you know you have to. Clean code is much easier to reason about. So if you are having performance problems, it's much easier to resolve them from clean code than from code that has already been optimized.

[00:04:37] Donald Knuth of Stanford said that premature optimization is the root of all evil. And the sense is that is, you should not begin optimizing until you know specifically where the optimizations need to occur. Most of the code has a negligible impact on performance. So if you're optimizing the negligible code, you're corrupting your code, which is going to increase errors and increase the cost of maintenance without actually providing any benefit.

[00:05:08] You only want to optimize the code that is taking up a lot of time, and that will generally be the innermost loops, if you're doing a lot of loopage. Now also it turns out that fiddling with innermost loops is probably gonna be ineffective. Cause if you have deeply layered loops then you're probably gonna have n squared or maybe worst performance profiles.

[00:05:32] Which means that code fiddling is gonna be completely useless. That the only way out is to find better algorithms so you can get out of n-squared well maybe into analog n world or better. So if you're dealing with very crufty code those sorts of algorithm changes are even more difficult to make.

[00:05:58] So there's this prevailing idea that every nanosecond you can squeeze out of the program is going to be beneficial, that is absolutely not true. That you only want to squeeze stuff out of the places that you know are slow. And in the case of web applications, it turns out that the majority of the time is spent on the DOM.

[00:06:20] The DOM API is this horribly inefficient thing, constantly marshaling, doing layout, doing rendering. That stuff is really expensive. The amount of time spent running JavaScript tends to be small number of percentages. So if you could somehow miraculously reduce the cost of all your JavaScript to zero, most users will not observe any difference.

[00:06:47] So fiddling with your JavaScript is just a waste of time. Now, when it is time to do optimization of your programming, and sometimes it is necessary. You only want to be doing the optimization, in places where you gonna get the benefit. Optimizing everywhere hoping for a benefit, is a waste of time.

[00:07:06] We only have limited resources for you to do your optimizing. So you need to optimize your optimizing. All right, so there will be bugs, I'm not promising that by having a better style that there will be no bugs. There will always be bugs, but what you can do is shave the odds in your favor.

[00:07:27] Anytime you can avoid being in the abyss, is going to make you more productive. So that's the end of part one. That was like an hour and 20 minutes. That was pretty good. So let's take a 15-minute break.
>> Speaker 3: Yeah, sounds good.
>> Douglas Crockford: Okay.
>> Speaker 3: And we have fresh coffee back there.

[00:07:45]
>> Douglas Crockford: Before we break, there is one question.
>> Speaker 3: Yeah, so I read a lot of JavaScript, which I like. And, but one of the things I like to take advantage of is truthy and falsey values, which we're all acquainted with, I'm sure. But now, watching your talk this morning, I'm thinking, well, yeah, that makes sense to me.

[00:08:04] But to someone who may come in as a maintainer later, they're gonna be unsure. Is that what he intended? What are your thoughts on-
>> Douglas Crockford: I think we have to demand that everybody level up on the language. So you don't want to assume that the people you're working with are going to be under-educated.

[00:08:29] So that's partly why we're here, right? So we're going to spend most of the day talking about functions. And a lot of that stuff is a new way of thinking. But I highly recommend people get into that kind of thinking because that's where the expressive power is. And we should do that even though other people may not understand how that works.

[00:08:50] Eventually we need to get everybody to level up on the good parts. And I think that the truthy, the Boolish values is actually one of the good parts of JavaScript. That was a really good question.
>> Speaker 3: I like it a lot, I guess I was more curious, especially when you advocate for the use of triple equals versus the double.

[00:09:08] And I know there's type coersion involved there, but that's essentially what you're getting with the truthy value. Truthy falsy values as well [INAUDIBLE] take into boolean sets.
>> Douglas Crockford: Yeah, but it's different. So, great. So let's break and we'll come back in 15 minutes.