JavaScript: The Good Parts

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

His whole lecture series is great. Required watching for any JavaScript coder: http://yuiblog.com/crockford/

👍︎︎ 5 👤︎︎ u/lazyduke 📅︎︎ Mar 30 2013 🗫︎ replies

Programming beginner here, What is lambda?

The things I find say anonymous functions, but I don't want to accept that in case it's an over-simplification.

👍︎︎ 1 👤︎︎ u/deliciousnaga 📅︎︎ Mar 30 2013 🗫︎ replies
Captions
Souders: All right, welcome, everyone. It's great to see a big crowd here. My name's Steve Souders. I work here at Google on latency. And I wanted to do a couple plugs for these talks. I'm trying to see about starting up a series of tech speakers coming in. So a couple weeks ago we had John Resig come in and you can see that talk up on the Google developer channel up on Google code. And next Thursday at 11:00 A.M. right here is Rob Campbell who works at Mozilla and he's one of the people leading the Firebug effort. And he's gonna do a talk next Thursday at 11:00 right here on Firebug and the new releases that are coming out and some of the new features. And-- But today-- So today we have Doug Crockford. Um, I worked with Doug at Yahoo. That's where I met him. And I remember the first time I met him and he told me his name, I said, "I know that name somewhere. I know that name somewhere. Oh, yeah, I've been using the stuff on your website a lot." And so I was really excited to meet him. And he's a really nice guy. I enjoyed working with him at Yahoo. Um, I-- I, uh, have a little bit of hesitation because when my book came out, it did pretty well. And then Doug's book came out and just kicked my book's butt. And so I just checked. And I'm, like, at 6,000 and you're at, like, 4,000 on Amazon sales rank, Doug. So that's really good. And I believe that this talk is largely based on his book, "JavaScript: The Good Parts." And so we'll run for about an hour and have time for Q and A. So without any further ado, please help me welcome Doug Crockford. [applause] I forgot. Here's your Google tech talk goodie bag. Crockford: This is what makes it all worthwhile, right here. [laughter] So, thank you, everybody. I'm Doug Crockford from the Yahoo. And I'm here today to talk about the good parts. Now when I first started talking about JavaScript, there were a lot of people who just could not accept the fact that JavaScript has good parts. But, in fact, it does. But it's not well understood. Even now. JavaScript has become probably the most important programming language in the world. There's more JavaScript processors on more computers than anything else by a very large factor. But despite that, JavaScript is not held in very good esteem, even within its own programming community. For example, the C# community loves Anders. And the Java community loves Gosling. And the PHP community loves Rasmus. But in the JavaScript community, there is no love. And there should be. And I think it indicates a lack of understanding. That's why JavaScript is still the world's most misunderstood programming language. It's the only language that I'm aware of that people feel that they don't need to learn it before they start using it. [laughter] It kinda looks familiar and yeah, yeah, yeah, yeah. I've seen this before. I know how this works. In fact, it works in a really radically different way. It just looks very similar. And then when people misuse it as inevitably they do because they don't know how it works, they get angry at it, and misunderstand it. Which is a shame because there's actually good stuff in this language. And because it's everywhere, JavaScript is now becoming the virtual machine for the world, which is a really odd mission for this little misunderstood language. You know, you're doing it here at Google with the GUID. And there are lots of other examples of the same kinda crazy thing. You know, it amazes me the lengths that people will go to to avoid having to learn JavaScript. But it's learnable and you can actually write good programs in it. And like everything else, knowing what you're doing, you know, makes a difference. And so I'm here to enlighten the world about JavaScript. JavaScript is a language of many contrasts. It contains some of the best ideas ever put into a programming language. And it contains some of the worst ideas ever put into a programming language. And a lot in between. There's no other language which has this amazing range of the ridiculous and the sublime. Um, if you look at the community of people who use JavaScript, it has the broadest range of programmer skills of any programming language. We've got people at the very high-end doing computer science in this language, which it does really well 'cause it's basically a scheme with C syntax. And we've got cut-n-pasters who don't even know that they're programming, who are putting stuff together and making it happen. If you gave those kids Java compilers, they would never get "Hello World" running, but they can work with JavaScript. So the language has amazing expressive power and it supports everybody in between. I contend there is no other programming language that can support this really broad audience of users. And I'll offer that as further evidence that this language is getting something right. Which again, may be surprising to the people who think this language didn't get anything right. One of the reasons people think that is that they have a lot of complaints about it. And I think these complaints are all valid and I'd like to go through them one at a time. The first one is that JavaScript is not a language I know. If you're programming in any environment-- the desktop or embedded systems or the server-- generally, you get to pick what language you're going to use. But if you're writing in the browser or if you're writing in one of the applications that has embedded JavaScript in it, you don't get a choice. You have to use JavaScript. And a lot of people get resentful about that. You know, "Why should I have to learn this stupid language? "I already know lots of other good languages. Why can't I use one of those?" You can't. Um, and so they... try to write without learning the language, which I think is really a bad thing to do. My advice is man up and learn the language. If you need to be writing in JavaScript, there's nothing like knowing what you're doing. Second complaint. The browser programming experience is awful, which is absolutely true. But that's not JavaScript's fault. I contend it's the DOM's fault. The DOM is one of the worst APIs ever imagined and that's what you have to use when you're using the browser. Fortunately, there are a lot of Ajax libraries available now which all do an amazing job at correcting the DOM model and turning it into something that you can actually write good applications in. So, uh, there is a solution to that. I'm hoping eventually we can push that solution back into the browser. But for now, the Ajax libraries work really well. YEY, I'll mention that one. Comes out of Yahoo. It's actually very, very good. I think maybe the best of them. There are lots of others that are also very good. There's a complaint that it's not fast enough. And in the browser, that's mainly because of the DOM again. If you look at the fraction of time that your program spends running, a tiny fraction of that is actually running in the JavaScript interpreter. Most of the rest of it is wasting time in the DOM interface. So if you could somehow make your programs go infinitely fast, most web applications are gonna look about the same. There are other applications for which having a faster language would actually be a benefit. And so I'm happy to see that mainly, I think, because of leadership from Google, we're now starting to see higher performance JavaScript entrants, which I think is really, really cool and very much to be encouraged. Although, practically, I don't think it's gonna make much difference to web applications for a long time. Then finally, there's a complaint that the language is just a big pile of mistakes. And I contend, no, it's not just a big pile of mistakes. [laughter] That hidden under a huge steaming pile of good intentions and blunders, there is an elegant, expressive programming language because JavaScript has good parts. And if you can recognize those parts and use those parts exclusively and avoid the bad parts, you can actually write good programs in this language. And I'll offer again, as evidence of that, that JavaScript is succeeding very well in an environment where Java was a total failure. I don't know if anyone here remember Java applets. How they're gonna change the world? Didn't happen. Crap. Java turned out to be an okay language and found a niche in the server where it's doing pretty well. But it was absolutely awful as a client programming language. JavaScript is doing really, really well there. The influences on JavaScript were Self, from which it borrows prototypal inheritance of dynamic objects. Dynamic objects are a really clever thing and they worked really well in this language. From Scheme, it gets lambda, which is maybe the best idea in the history of programming languages and loose typing, which is pretty controversial. The style of most languages today calls for strict typing. The theory being that strict typing allows for the compiler to check a large class of errors at compilation time avoiding-- Catching any error early reduces the cost of the errors. So that's a good thing. And JavaScript doesn't have that. So in JavaScript, any variable or any parameter can contain a value of any type. And that's really frightening to someone who's coming from a strongly-typed tradition. Like, "How can I have any confidence that anything's gonna work right?" It turns out that strong-typing doesn't absolve you of the need to test. You still have to test everything, 'cause there's an even larger class of mistakes that type checking doesn't find for you. And I found in my own practice that the amount of testing that I have to do, writing in Java or writing in JavaScript, is about the same. That those type errors get found really quickly anyway, so they're not really a problem. The areas that are a problem, the ones that keep me up at night, um, type safety wouldn't have helped me there. The benefit of having loose typing is you don't have to mess with the type system. And so that turns out to be liberating. Your programs tend to be a lot smaller and a lot simpler. So which one do you like? Well, it doesn't matter. If you're working in JavaScript, it's gonna be loosely typed and that's just the way it works. From Java we get syntax, which is a source of a lot of problems because it's basically the C family of syntax, which we've all learned to deal with. We've gotten so good at it that we don't even recognize anymore how defective it is. But because JavaScript is used by beginners, those problems are intensified. And then finally, from Perle, JavaScript gets a really horrendous regular expression notation. So before we get to the good parts, let me tantalize you with some of the bad parts. The worst part by far, global variables. JavaScript doesn't have a linker. So the way compilation units get bound together is they all get tossed in a common global namespace where all the variable names can collide and interfere with each other. It has terrible reliability problems. It has even worse security problems. You've all heard of cross-site scripting attacks. Those attacks are fundamentally enabled by JavaScript's use of global variables. JavaScript uses + to both add and concatenate. It got that little bit of overloading from Java. In Java, it wasn't too bad because it's strongly typed and so you could predict which one it's going to do. In JavaScript you can't. So this is a very common source of errors. Semicolon insertion was something intended to make the C syntax easier for beginners. C syntax, the rules for where a semicolon goes are kind of complicated. You really have to understand the syntax of the whole language in order to understand where to put them. So to make it easier for them, JavaScript says, "We'll put them in for you so you don't have to use them." The way it did that was when the compiler gets an error, it backs up, looks around for a line feed, turns it into a semicolon, and then tries again. That should freak you out. [laughter] It sometimes puts them in the wrong place. Sometimes doesn't put them in places where you'd expect. My advice? Figure out where the semicolons go. Put 'em in the right place. You'll be much better off. JavaScript has a typeof operator which allows you to determine if the typeof a value is a string or a number or something like that, which is really good. If you ask it what the typeof an object is, it says it's an object. Great. If you ask what the typeof an array is, it says it's an object, which isn't very helpful. If you ask what the typeof null is, it says it's an object, which is wrong. It has a with statement, which was well-intentioned but doesn't work right. I highly recommend you avoid it. Simply by being in the language, it causes programs to be a lot slower than necessary whether you use it or not. And similarly, eval is the most mis-- most misused feature in the language. If you ever find yourself needing to use eval, you're probably thinking about things in a really wrong way. So step away from the computer, read my book, and then take another run at it. [laughter] JavaScript has phony arrays. In most languages, you've got an array, which is a linear sequence of memory, which is divided into regularly spaced buckets, so you can do address computation and very quickly get to an element. JavaScript doesn't have anything like that. In JavaScript, arrays are essentially hash tables, in which the keys are turned into strings and then hashed to locate the buckets. This has a terrible performance penalty. But it has an advantage in that it makes the programming model quite a bit easier, 'cause you don't ever have to dimension an array. Dimensions don't exist in this language. It has a equality operator that does type coercion, which turns out to be problematic. I'll show you an example in a moment. And it has too many bottom values, which is a problem because beginners tend to get confused by having all these things which almost mean the same thing but are slightly different in their meaning. So these are some of the consequences of type coercion on the quality operator. There are rules that govern this. This isn't random behavior. But it's certainly surprising behavior. And the rules are not memorable, so this all looks very mysterious. Fortunately, the language has a triple equal operator, which does not do type coercion, so it would answer false to all these cases, which is the right thing. So I highly recommend-- Always use a triple equal operator. Never use the double equal operator. Just don't use it. So one of the nice things about the dynamic objects in this language-- If you ask an object for a property that it doesn't have, you don't get an error, it doesn't throw. It just returns to the undefined value, which is really nice. So you can, you know-- Reflection is just automatic on things like that. So if you then ask if the thing is undefined, then you can do something about it. But because a lot of beginners don't understand the difference between null and undefined, they use null and they use the wrong comparison operator, which often works. It's the case of two errors that cancel each other out. That's not a good way to write programs. So the right way to write this program would be to use the proper equality operator on the proper value and now it'll work for all cases. Here's another case where good features interact badly in this language and I'll give you an example. Objects can inherit from other objects, which is good. One of the interesting things about this language is you don't have classes inheriting from classes. Objects inherit directly from other objects, which is really powerful, it turns out. Objects can be members-- Functions can be members of objects, which is good. That's how methods are created in this language. And we have a for..in statement that mixes inherited functions with the desired data members, which is not useful at all and is a common source of errors. So how did that happen? There was a design question in the making of the language. Should the for...in statement, which iterates through all of the members of an object, do a shallow skim of the object's own properties, or should it do a deep dredge going through its inheritance chain? The decision was to do the deep dredge. And I think the thinking was that if we do the shallow one and what people really want is the deep one, we're screwed. They just can't get at that stuff. Whereas if we do the deep one and what they wanted was the shallow one, they can do the filtering themselves. Except that they didn't tell anybody that that's why they did it and that's how it works. And so as a consequence, there's a lotta confusion about how to use for...in and how to attach methods to prototypes. I think a better decision would have been to not release the language until they had enough experience with the language to know what the right answer was. But to put it into historical context, at Netscape, getting it right was not an option. Which is why there's no longer Netscape. Um, yes? man: Isn't the real issue that people are using objects as hash tables and they really aren't hash tables because when you said they were, like, two strings who get things you don't expect? Crockford: Um, no, but we can get to that in the Q and A. Um, so these are things which are wrong with JavaScript, which are really wrong going all the way back to B actually. But I'll talk about them here 'cause we're talking about JavaScript. We have the option of using blockless statements, which is a bad practice. It creates code which is more likely to get damaged under maintenance. So I recommend always putting the curly braces in. It allows for expression statements in which it can just have the name of a variable or a simple expression and do nothing. I think the reason for that was it made the specification of the syntax a tiny bit easier. They were able to save a production or two. But as we're gonna see, it just messes things up. The most often reported error in the language is that 0.1 + 0.2 !== 0.3. And this is not really a problem with JavaScript. It's a problem with IEEE floating point. That floating point is the only number type in the language. Having just one number type in the language turns out to be really nice, particularly for a language that beginners use, because there's a whole lot of compatibility problems that just go away. Everything is the same type. But unfortunately, they picked the wrong type. That you tend to do a lot of computations involving money in this language and the sums come out wrong. And generally when you're adding people's money, people have an expectation that the results gotta be right. And it's hard to do in this language. Unnecessarily hard. It has the increment and decrement operators, which are very convenient but have been implicated in buffer overruns and other security hazards. I found in my own practice that when I use them, I would tend to write code which was too tricky. And code which is too tricky is too often wrong. So in my own practice, I don't use them anymore at all, ever. Just part of my discipline. Finally, it has the switch statement. The switch statement was modeled after the FORTRAN computed goto. It has the property that one case can fall through into the next case. I'm gonna tell you later about a program I wrote called JSLint which is a quality-- code quality tool for JavaScript. One day someone wrote to me and said, "You know, the language has switch statements "and sometimes you can have one case fall through "into another case and it's really difficult to see that "when reading the code, you know? "So could you have JSLint generate a warning anytime that happened?" And I thought about it deeply and I wrote back to him and I said, "Well, there are cases "where it's actually beneficial to have that falling through." And you could have a code indicating, you know, whether you intended that or not but, you know, that doesn't really work. You know, so on balance, I think maybe it's better just to leave it alone. That it's actually a good thing to have in the language. Next day, the same guy sent me a bug report that I had something that JSLint was misclassifying. So I threw it in the debugger and it turned out I had a switch statement that was falling through. [laughter] So in that moment, I achieved enlightenment. There are these moments in your programming career where you actually learn something. Learning turns out to be really hard. And in this case, I actually learned my lesson. And so I now never intentionally fall through in a switch statement. And because of that I can now much more easily detect when I accidentally fall through in a switch statement. So as a consequence, I think my use of that statement has improved significantly. So you've been waiting for the good parts. Here they are. It's a short list but it's a good list. At the top of the list is Lambda. This came out of Scheme, which came out of Carl Hewitt's work on the Actor model. I think this is the best thing ever to go into a programming language. It's powerful, it's safe, it's smart, it's good, it's flexible. Great stuff. JavaScript has dynamic objects, which means you can take any object and at any time, you can add a new property to it or remove a property from it. You don't have to go to some class and make another derived class in order to have an object which is slightly different than the one you've got. That turns out to be amazingly powerful. Makes this language especially easy to use. It's got the loose typing in it, which some people look at as a severe disadvantage. I think it's actually an advantage. This language is better off, I think, for having loose typing. And it has object literals. Object literals are a very nice notation for describing objects. JavaScript's object literals were the inspiration for the JSON data interchange format. Um, there-- Inheritance is object-oriented code reuse. And there are two schools of thought for how to do that. There's the classical school, which is represented by almost all present-day languages. And there's the prototypal school, which is represented pretty much just by JavaScript. There are no other languages in broad use which have this property. Turns out the prototypal inheritance is amazingly powerful but it's not well understood. It's so powerful that you can program as though it is classical and it mostly works. You can't do the opposite. You can't go to a classical language and program as though it's prototypal. So in prototypal inheritance, it's class-free. There are no classes. Objects inherit directly from other objects. And in this language, an object contains a hidden link to another object from which it inherits stuff in a process called delegation. Sometimes called differential inheritance. So each object contains only what makes it different from the object it inherits from, and that allows for objects to be much smaller. For a long time, the language was ambivalent about its prototypal nature, so never included an operator for actually making new objects which inherit from other objects. We're correcting that oversight in the next edition of the language with object.create, which will make a new object which inherits from an old one. Um, it's not in the current browsers, but it's easily implemented. Until it becomes standard equipment, you can realize it in this way. What JavaScript has instead of this operator currently is a weird trio of constructor functions, prototype members, and a new operator, which were intended to provide a friendly object-- or friendly classical-like notation for dealing with prototypes. But it didn't work. The Java community smelled this immediately and said, "That's alien. That's clearly not something we like." And so what it really did was confuse what the language was actually doing. Uh, so in-- As part of that sugar for trying to look classical, JavaScript has a new operator, which is absolutely required when you're calling a constructor function. If you call a constructor function without the new operator, instead of creating a new object and initializing it, your constructor will clobber the global object, which is a very, very bad thing. There is no compile-time warning and there's no run-time warning for this. So for this reason, I don't use "new" anymore. I think it's just too dangerous. So it's time to look at some code. Here I'm gonna make a simple little function called digit_name, which I'll pass it a number and it will return a string which is the name of the digit. So I've got an array of strings, which I create using an array literal. Very nice. And then the function returns looking up the argument in the array. So everybody understand how this works? All right. Problem with this is names is a global variable. So if there's anything else in my application called names, either it's going to fail or my program's gonna fail or we're both gonna fail, which is really bad. Particularly as pages become really dynamic, I may be linking with libraries I've never seen, will never get a chance to test with. I may be having to run with ads which I will never see, which could interfere with my program. So I want to--I have really good reasons to try to avoid the global variables. And the language gives us a couple of options for doing that. One approach would be I could define the array of names as a private variable of the function. And that works just fine. So we have function scope in this language. We don't have block scope, so you need to understand the difference and do it right. But having that, this will work. So names is no longer a global variable, so I avoid that hazard. The problem with this is that every time this function gets called, we're going to reinitialize the names array. Now in theory, an optimizing compiler could detect this case and factor that out. But today, nobody does that. So I might want to write this function in a different way to avoid that. So one way I could do that would be to put it in a closure. So here I've got a function which is going to return another function and the outer function gets executed immediately. Okay? The inner function has access to the properties of the outer function or to the variables of the outer function. It will continue to enjoy access to them even after the outer function has returned. So this allows me to have-- So when it returns, the function goes into digit_name and that function will have names bound to the original array and will continue to have it for as long as it lives. This is an amazingly powerful thing that this language does very, very nicely. And we can generalize this into a constructor pattern. So if you think of an application or any kind of singleton, we don't have to make a class in this language to make a singleton. We can just make it. And the proper-- The methods that that singleton has, can enjoy private shared access to stuff. We don't have to put it in global variables. So I can-- Again, I've got a function which I'll execute immediately and return an object literal which contains some methods which will do useful stuff. And those methods will have access to the private material that the outer function provides for them. We can take this and turn it into a constructor, which is a very nice way, an alternate way, in this language for making objects. So here's the recipe. Step one, you make an object. And there are four ways we can make an object. We can use an object literal. We could use "new." I don't do that but you might. We could use object.create to beget something from an existing object. Or we could call another of these power constructors, which gives us another inheritance model. Step two, we define some variables and functions. These will become the private members of the object that we're making. Step three, we augment the object with privileged methods. Privileged methods have unique access to the stuff defining step two. Then step four, we return the object. So pretty simple recipe. Let me turn the recipe into a template. So step one, I'm gonna make a new object. I'm gonna put it in a variable called "that." "That" because it's reminiscent of "this." And I can't call it "this" because "this" is a reserved word. Step two, I'll define a variable that will be secret, be private, shared by these guys. Step three, I'll create a privileged method, which is a function which will have access to the state of the outer function. And step four, I return that, and that's it. Really easy way to make objects which can hide their stuff and be private. So the reason this works is because we have closure in this language, which means that a function object contains the function itself, which has a name and parameters and a body and it has a reference to the environment in which it was created or the context. You know, which-- In this case is the stuff that was in the outer function. This is a very good thing. This is one of the best parts of this language. Now concerning style, if you get any two programmers together, they could argue all day about matters of style. Like should the curly brace be on the left or on the right? And they may get really emotional about which way it goes. We feel very strongly about this stuff even though we don't know why. You know, we can agree that whichever we do, we should be consistent. But it's hard to find agreement on should it be on the left or the right. It's sort of like, "What side of the road should we drive on?" There's not a compelling reason for why we should drive on the left or right. As long as we all drive on the same side. If we don't, then bad things will happen. And we have a similar thing here. So if you look at why people get emotional about that stuff, where did the idea of leftness or rightness come from? You know, you could trace it down to where they went to school or what they learned on their first job or are deeply impressed somebody early in their career. They may give you a lot of reasons for why the left side or right side is better than the other. But they don't fundamentally know. They just get really emotional about it. Well, it turns out having them on the right side is the right way and the left side is the wrong way in JavaScript. I can't testify for any other language. But it is absolutely true for this language. And I'll show you an example why. So here we have a return statement which is returning an object literal. We saw an example of that in the earlier construction pattern. The one on the right works right. And the one on the left, "silent error." It doesn't return an object. It returns nothing. It returns undefined, which is deeply surprising and wrong. You don't get a compile time error. You don't get a runtime error. You don't get nothing in the log. This is really bad. So how does this happen? Because the two statements look like they should be equivalent. So let's zoom in on a little bit. Look at what's going on. All right, you remember I told you about semicolon insertion? How we'll sometimes put semicolons where they shouldn't go? This is one of those times, so it puts a semicolon in there. So a return statement with no value after it and no expression after it, will return undefined in most contexts. Occasionally, it'll return these. So but there's a lot of other junk here. That should cause some sort of syntax error or something. Give us some sort of warning. Well, no, because it turns out that curly brace can mean "start an object literal", or it could mean a block. Now it turns out, in this language, we don't have block scope. So having an empty block is not useful. We have one. The syntax prefers a block to a literal in this notation, so that's what we get. Okay, so "ok" doesn't look like a statement. Well, actually it does. It looks like a statement label. Well, "false" doesn't look like any kind of a statement. But, remember, we have those useless expression statements that we inherited from C. So we'll evaluate "false" and go, "Yep, that's false.", and ignore it. But it doesn't have a semicolon after it. Well, that's not a problem, because semicolon insertion comes in, repairs that one. Now we've got an extra semicolon at the bottom there. That should trigger an error. No, 'cause from C we also get the empty statement, which allows you to have as many semicolons as you want. So all these things tend to work together to mask errors. Then, finally, we've got some unreachable code here. But JavaScript doesn't care. So there's nothing in the language, in the grammar, that says there's any problem with unreachable code. So here's a case where bad style produces a very bad result. You've got code which you think means that which means that. That's one of the worst things a language can do to you. Now you might be looking at this and you might be wondering, "How did this ever become a standard?" And you might be wondering, "Why am I betting my career on this piece of crap?" [laughter] Um, getting back to the question about standards, this shouldn't have become a standard. There was nobody paying attention and this stuff went through and JavaScript became the world's biggest programming language completely independent of its merits. Given the process by which all of that happened, we deserve a language which is far, far worse than JavaScript. In fact, given its amazing success despite some of these obvious shortcomings, I think we got lucky. There's actually enough goodness, smartness, built into the language that if you can just avoid the bad parts, the good parts are really good and are worthwhile. So I call that "working with the grain." I spent a lot of time struggling with this language trying to figure out how to make it work right, how to make it do good things. 'Cause all the examples that were published by Netscape at the time and that you could see coming out of Dreamweaver, all told you to do really awful stuff. And it took a long time to figure out what this was about. I remember one day I had an epiphany. "Wait, this is scheme." You know, I-- There was no documentation which said how functions worked and the properties of it. It wasn't accidental. Brendan Eich, the designer of the language, always intended to implement a scheme language. His bosses at Netscape wouldn't let him do a scheme language because it was too weird looking. They told him, "Make it more like Java or Visual Basic or something." So he did this to it. So it's not accidental that the good stuff is in the language. He put it there intentionally. So he very quickly put together a prototype, uh, uh, in an amazingly short time and presented it to management and it seemed to work. And they said, "It seems to work." He said, "Yeah." So they shipped it. [laughter] Then Microsoft observed it and decided to knock it off, and they reverse engineered it to amazing fidelity. They found all the errors that were in that first implementation and copied them exactly. [laughter] And when it went to standardization, all that stuff got locked into the standard. So this bit I showed you before, this amazingly silly bit of silliness, that's not due to errors and implementations. It's required behavior by the standard. In fact, all the browsers implement it exactly that way. So when JavaScript was first introduced late in 1995, it was intentionally mispositioned by Sun and Netscape. They decided they needed to join together against Microsoft. And there was some confusion about why they needed two languages. 'Cause it was clearly that Java was going to be the language that was going to rule in the future. Netscape didn't want to give up on this language, which was called JavaScript at the time. And their alliance almost broke down until Marc Andreessen, perhaps as a joke, suggested that they call it JavaScript and that way Sun wouldn't have to hate it. [man speaking indistinctly] Crockford: I'm sorry? man: It was LiveScript. Crockford: It was LiveScript. Um... So, um, I looked at the first version of the language and like all of you, I said, "Well, this is incompetent crap. I'm not gonna waste any time on this." I had an occasion several years later to take another look. And between that time and the next, some goodness had been added to the language that was missing from the first release. My company was approached by Turner Broadcasting to do a website for children based on Cartoon Network. And we had a chat system that we had that they wanted to adapt to this online children's community. So I went down to Atlanta and learned about the requirements and it was pretty clear our chat system wasn't going to be good enough to do this. And I didn't wanna give the money back because this was, like, the biggest contract in the history of the company, and I really wanted to do this. So I don't know where it came from, but I got this really silly idea. Maybe we could do it in the web browser just as it is? So I wrote up a little prototype and it ran on IE 4, I think, at the time and on Netscape 4. And I sent it to Atlanta and they liked it. You could drag and drop little cartoon guys. They'd never seen anything like that in a browser before. And they liked that it wasn't a big installation. It was just a little thing that ran in their browsers, so it was something they could ask kids to do. So that was really good. So I went to my team. And my team, I had some of the best Java developers in the world. We'd been together for a long time. We had a lot of experience at doing this stuff. And I said, "Okay, this is how we're going to do it. We're gonna write the client in the browser in JavaScript." And they all said, and you may remember, "That's great. What's plan B? [laughter] "In fact, we should start plan B right now because there's no way this is going to work." And I said, "No, we're not gonna do plan B. "We're going to do plan A, and it is going to work. So who wants to do the JavaScript?" And everybody took a step backward. So it was, like, I have to do this or I'm gonna have to give the money back. And I really didn't wanna give the money back. So I had to do JavaScript. And like everybody else, I started doing it without learning it and was hating it the whole time. [mild growl] And it wasn't until I had the scheme epiphany, which came late, that I understood what it was about. And it was like, "Oh, okay. This isn't so bad." There's actually goodness in it and discovering the goodness-- It's like, "There's JSON in it!" JSON came about it from my experience using the language and recognizing, "Hey, this little bit of a language could be used for doing data interchange." And it was great. It was already there. It was free. And it was well done. So JSON, just as a consequence of my recognizing it, has become a world standard. The JSON story-- In 2001, Chip Morningstar and I were at State Software and we had an early AJAX platform. Really amazing stuff. I think it's still better than what's out there today. And we used JSON for the data exchange. And we went to potential customers and we explained how it worked. And they said, "Well, where's the XML?" We said, "Oh, we don't need XML. We're doing this. It's really so much easier and faster." They'd go, "Oh, we just committed to XML. I'm sorry. We can't use it." Or they'd say, "It's not a standard." I'd say, "Well, yeah, it's a standard. It's in JavaScript." "It's not a standard. We can't use it." So I declared it's a standard. So I bought json.org and put it up. One-pager that described it because it's really simple and it's all the description it needed. Few years later, I also wrote an RFC that described it a little bit more formally. And it's become a world standard. Basically, I am a standards body. [laughter] It became a standard just on my say-so. So anyway, getting back to the electric community story. So we-- That JavaScript program, we finished, we shipped it, we got paid. All that stuff is great. Unfortunately, while I was making the money, the other half of the company was spending the money. So by the time it all got done, the board fired the CEO and the COO and made me CEO again and I had about two week's cash. Anyway, when you're going through a bankruptcy, you get a lotta spare time. [laughter] And so I remembered a paper that Vaughan Pratt had written years ago at the first POPL conference about top-down operator precedents. Which was this amazingly clever, elegant, lightweight way of writing parsers. And he used it for putting an ALGOL-like syntax onto Lisp. But it turned out the Lisp community has never wanted syntax. But the JavaScript community likes syntax. And so it occurred to me that I could write a JavaScript parser in the language, and I did. And it turned out really well. And then I had this JavaScript interpreter-- or JavaScript parser, and what do I do with it? So I turned it into a code quality tool for JavaScript called JSLint. And so what JSLint does is it parses your program and analyzes it for the sorts of weaknesses that I've been showing you. Identifies the bad parts. And if you can get it to stop complaining about your program, then your program probably just contains good parts and it's more likely to be a good program. So it imposes a programming discipline that makes me much more confident in being in this very dynamic, very loosely typed environment. The sort of confidence that strict typing gives you, JSLint gives me in this silly little language. And it's free. If you're writing in JavaScript, you need to be using JSLint. So go on the web and get it. If you're evaluating other people's JavaScript, it's good at that too. So, say if you're comparing AJAX libraries, you don't know which one to use. Run it through JSLint. See which one is coded well. It'll tell you very clearly. One bit of warning. JSLint will hurt your feelings. [laughter] It'll hurt them really bad. It stings. From time to time, people write to me and say, "Hey, here's another thing you could test." And if it makes sense, I'll put it in and then I'll run all of my old programs against it. Then you realize, "Well, I really suck." You know, even though I wrote it, even though I know what all the rules are, it still hurts when I run into this stuff. And so I can imagine your pain when you go through this stuff. I do feel it. Despite that, I recommend do everything it says, because it's right. And even though you've been programming and you've got a good career and you really know what you're doing, it's smarter about JavaScript than you are. It's certainly smarter than I am. I highly recommend you use JSLint. One of the things that makes it hurt is that unlearning is really hard. I get letters from people all the time saying, "JSLint said my shit stinks. What's up with that?" And they always use the words "perfectly fine." "I did this thing and it was perfectly fine." Well, I think "perfectly fine" is double equal to "faulty." [laughter] And there arguing with me. "Why should I have to fix that?" I don't care if you fix it. It's not, you know-- Nothing to do with me. You're not even paying me for this. I'm just putting it out there free. If you want your programs to be good, make 'em good. But, you know, we get really invested in this stuff. And ultimately it's because unlearning this stuff-- When you learn something wrong it's really hard to get it right. In JavaScript, if you're a professional programmer, you're coming to the language with baggage from other languages. And because it looks like Java but works completely different than Java, it's really easy to get stuff wrong unless you're paying attention to what you're doing. Or if you're a beginner, you probably started by reading view-source on crap that ultimately traces all the way back to Dreamweaver. And it's awful and that's the way people learn. And once that stuff gets in your head, it's really hard to get it out, but you need to do it. Josh Billings said, "It's not ignorance "does so much damage; it's knowin' so derned much that ain't so." And ain't that the truth? So maybe the best part about this language is its stability. There have been no new design errors since 1999. [laughter] And this is a consequence of-- That's the last time the language spec was revised was in 1999. But I think it's a good idea to, every ten years or so, revisit the specifications. So we're about to lose this best part. We're about to come out with a new edition which is codenamed ES3.1, which will probably be labeled Fourth Edition. There's a weird story you might ask me about later for why it's called and not JavaScript. This new edition will contain a lot of corrections. Both corrections to the specification and some corrections to the language. It turns out there are cases where, um, all the browser makers did something different than the standard and they all got it right. So we're recognizing that and making the standard better. There are also places where we saw three out of four of the browser makers were doing one thing and Microsoft was doing another. We're fixing that now too. The next version of JScript coming out of Microsoft will be in much closer alliance to the common language than everybody else. So one of the key benefits from this language is that cross-browser compatibility will be significantly improved. Now it turns out JavaScript is already, I think, one of the best languages in the world in terms of compatibility with multiple implementations. You know, two JavaScript engines are much more likely to be compatible at a really deep level than, say, two C engines. JavaScript gets knocked pretty hard about cross-browser compatibility. But most of those problems are due to the DOM. The language itself tends to be pretty good. It's gonna get even better. We're providing support for object hardening. So objects right now are maybe too dynamic, where everything in them is completely malleable all the time. So we can now make objects immutable, where you can lock down individual properties or lock the whole object down. This will be particularly good as we start looking someday towards secure mashups, where you can have a hardened object which you can give to other code and know that it cannot be compromised. We'll also have a new strict mode for reliability. So there are a lot of things in the language which are just intolerable. But the biggest problem with the bad parts in this language isn't that they are useless. They actually are occasionally useful. And so the web has found uses for all of the really bad parts of the language. So we were very greatly constrained in what we could take out. And we've tried to be respectful for existing code and tried to minimize the breakage that the new language will cause. But there's some stuff in the language which really has to be fixed. So we now have an opt-in mode. You can say "strict mode" and put it in the top of your program or in the top of your function and that says, "I don't want the crappy behavior. I want the rational behavior." I recommend you not put the strict mode tag into your program unless you understand what it does and what it means and that's the language you want to be writing in. But I recommend that's the language that you want to be writing in. So right now we're waiting on implementations. The specification's just about done. Microsoft and Mozilla both committed to public testing. If the testing goes well, then the standards should go to the ECMA general assembly in December and I'm hoping that it will pass. And then we'll probably see it up here in web browsers even before that. If you could hold it to the end. We're almost there. Something that's not coming soon is a competing project called ES4. That project has been cancelled. There were some good ideas in that project though and they've been resurrected in a follow-on to 3.1 called Harmony. So far, the project doesn't have any defined goals or rules, so it's a little vague as to what it's gonna turn out to be. We'll keep an eye on that. There's been some real interesting work lately in secure subsets. JavaScript is not a secure programming language but it's not far off from one. If you correct--get rid of the global object and make a few other changes-- hold much closer to its scheme nature, there's the kernel of a secure language in there. We've seen some experiments like FBJS out of Facebook, Caja & Cajita from the Google, and ADsafe, which is my own work. ADsafe is intended to make advertising safe. Currently it's not, and we can talk about that another time. These subsets will be informing the design of a new language which will ultimately replace JavaScript. And there's some exploration going on now at ECMA for such a language. So to review the good parts, this is maybe the best part of all. Your JavaScript application has the potential to reach an audience of billions. There is no other programming platform that has anywhere near that kind of reach. And, you know, just that, I think, should be enough to encourage you to wanna be on this platform. If you avoid the bad parts, JavaScript works really well. There's even brilliance in this language. There should be love in the JavaScript community for this language and its designer, 'cause there is goodness here. And it is possible to write good programs in JavaScript. There are a lotta people who thought it's not possible to write good programs, so you shouldn't even try. My message is it is possible and it is necessary to write good programs. If you don't wanna write good programs, I recommend you find another line of work. Um, then finally, um, here's the commercial plug. I wrote this cranky little pamphlet called "JavaScript: The Good Parts." So if you wanna know more about this silly language, that's where to go. So that's it. That's all I got for you today. Thank you. [applause] So how do we do questions here? Is there a mic or do I repeat or what? [man speaking indistinctly] Crockford: Okay, yes? man: So strict mode in 3.1, does that actually change behavior or does it just pick things out? Crockford: Strict mode, does it change behavior or does it take things out? It actually changes some behavior. So one of-- It does take some things out. Like, you can't have a "with" statement in strict mode. So it does take some features out of the language. It changes the way some features work. Like, it greatly constrains how eval works and reduces its ability to do harm to the state. It also changes some air behavior. For example, currently in the language, if you do an assignment to a read-only property of an object, you get a silent failure. Which is a bad thing. In strict mode, you will now get an exception, which is a better thing. Any other questions? man: I've heard you and some other people I know talk about ideas for projects to fix the DOM problem. Can you give us a update on what's going on there? Crockford: Question is what are we doing about the DOM problem? One bit of difficulty about that is there are two independent standards bodies that control two parts of this system. ECMA controls the programming language and W3C controls the API. And these two organizations, as far as I can tell, do not cooperate with each other. They don't talk, they don't share plans. That's a problem. And so there's much in the DOM-- Fixing the language will not solve any of our security problems if the DOM is left the way it is because it is also hopelessly insecure. So I'm hoping that we can put ECMA and W3C together and do a more collaborative approach to revising the DOM. I see work going on on HTML 5 and the web API stuff and it's really alarming to me. I think they're going off in very, very bad direction. I think it's way too complicated. I don't think it's addressing our real problems. It just seems more like a standard maker's holiday to me. So I'm hoping that we can do a reset there, start over with a better set of goals that we can go into the future together. I'm optimistic about it because of what I've seen in the AJAX libraries. You know, the DOM model is just really awful. There was originally the Netscape model, which was even worse. Microsoft improved it. Microsoft gets beaten up a lot for making the DOM so bad. I think the thing they did wrong was they stopped too soon. But it is bad. But the AJAX libraries are all very thin. Just, you know, a little bit of code, you know, generally on the order of 20 to 40k, which makes it so much better, you know? So eventually I'd like to take a look at the lessons that we got from the AJAX libraries, and then refactor the DOM based on that, push it down, and that becomes the new API. Yeah? man: What about Lambdasoft? Lambda is good. I like Lambda. You had lots of praise for it. But Lambda's more than closures. How do you spell Lambda in JavaScript? Crockford: How do you spell Lambda in JavaScript function? So you don't get everything that you get in scheme. You know, so we don't have continuations. We don't have tail recursion optimization. There's a lot of stuff that's missing. But the basic notion of helixical scoping is there and functions as first-class values. Yes? man: You mentioned the worst mistake in JavaScript was the use of global variables for linkage. What's your preferred way of solving that problem? Crockford: So I said the worst problem in JavaScript was its use of global variables for linkage. How would I solve that? I'd like to have some... discovery pattern in which each of the compilation units is initially completely isolated, but is given a capability which allows it to introduce itself to some other capability manager. So they can make introductions to each other and form a network. Uh, uh, yeah? man: You said that there is no issues with using objects as though they were hash tables. Remind me what key you would use [indistinct]. Crockford: Okay, so Waldemar is getting after me about-- JavaScript objects are not strictly hash tables, or are defective hash tables, I think is maybe more correct. In that there are some names which will cause collisions. And, in fact, some of the stuff we came up with in 3.1 is a little odd in the way it's put together and that was in order to not worsen that problem. So, yeah, it's not perfect. Like so much in this language, it's not perfect. Yes? man: You were saying that you think that web apps and HTML 5 is going in the wrong direction. What things do you think that we're doing wrong? Is it just that we're not solving the problems, or is it are we actually adding to them? Crockford: What do I think is wrong with HTML 5? man: And the web apps. Crockford: And the web apps? I think it's doing too much. You can look at any individual thing and say, "Oh, that looks nice." But there are way too many of those things. I would like to see a more disciplined approach. I'd like to see a more minimalist approach. You know, so if you look at the two proposals that were competing for the fourth edition, ES3.1 and ES4. I preferred ES3.1. It was less ambitious but it was less likely to cause problems. And it was moving more toward minimalism. Which I think is something which is way underrated, Particularly in standards. My view of minimalism, particularly after the JSON standard, is that the less we have to agree on in order to work together, the better. And so I would like to look at a way of re-engineering HTML and all the stuff that goes around it to be much smaller and work better. And, you know, I see HTML 5 and the web apps going in the other direction, which is just the emperor's old clothes approach, where you just keep piling more stuff and more stuff and more stuff. It just gets too big. It's easy to make things bigger. It's harder to make things better. Okay. Yeah? man: How did it come about that JSON and, uh, ECMAscript have the same syntax, but almost--but not quite? Crockford: Yeah, so how'd it come about that JSON and JavaScript have almost the same syntax? I think it's just in the two line-ending characters. Yeah? Yeah. It's because I missed that line in the standard when I was putting it together. When I specified what the whitespace characters were, carriage return, line feed, tab, and space. And I missed that-- What-- PS and? man: And LS? Crockford: And LS. Were also recognized as whitespace. We tried to fix that in the ECMAscript standard and we couldn't. So we're stuck with that little bit of difference. As far as I can tell, nobody's ever used PS and NLS in this context, so... [man speaking indistinctly] Crockford: Yeah, but I've never seen anybody use them. So it hasn't been a problem yet. There's a potential security hazard in that the two systems view it differently. Particularly when-- But we never identified an exploit that came from that. And now that there's an explicit JSON parser built in to JavaScript--that's one of the new good parts, by the way. That problem goes away completely. Yes? man: So the first time I was using JSON, the first problem I ran into, like, first object I tried to parse with the JSON parser, it wouldn't parse and it was because I didn't put quotes around my property names. Is there a reason for why that is not allowed? Crockford: Yeah, so why does JSON require quotes around the property names? There are three reasons. One of the reasons is that I wanted to align it with Python. In Python, the quotes are required. Another reason was it makes the grammar of the standard much easier to specify and I like simplicity. But the real reason, the true reason, is that JavaScript has a-- okay, I'll say it-- a stupid reserved word policy. And there are certain words that you cannot use in the key position of an object literal. Many of those names are not even used in the language. They're reserved unnecessarily and there's just no reason for it. And at the time that I put JSON together, it wasn't like I was riding on JavaScript's coattails, because nobody was using JavaScript at that time and everybody hated JavaScript. So it wasn't like I was basking in JavaScript's glow. So in order to not have quotes but still use it in JavaScript, I was going to have to have an appendix of the JSON spec, which was gonna be at least as big as all the rest of the spec describing how the reserve words worked. Basically what it said, "This is something that's really stupid in JavaScript." You know, need to point it out. And at that point, I didn't wanna make JavaScript look stupider. So I said, "Okay, we'll just quote the keys and then we don't have to tell anybody about this shameful thing." One bit of good news. We fixed that in the next language. Reserved words are now allowed in key position and also in dot position in the language. So that's better. But that took a long time. Uh, one more question? Yeah? All right, one more. Yes? man: Are there any prospects for adding concurrency to the language? Crockford: Are there any prospects for adding concurrency to the language? It depends on what you mean by "concurrency." Brendan Eich is pretty adamant and I completely agree with him. We should not put threads in this language. I would like to see some sort of messaging model. I don't know that it belongs in this language. More likely, it belongs in some layer beside the language. We would definitely benefit from that. man: There is--Firefox 3.1 is gonna have support for APIs that allow you to create separate threads that can send messages to each other. Crockford: Yeah, I like that model a lot. Okay, that's all I got for you today. Thanks. [applause] Souders: That was an amazing talk, Doug. Thank you very much.
Info
Channel: Google TechTalks
Views: 571,260
Rating: undefined out of 5
Keywords: google, techtalks, techtalk, engedu, talk, talks, googletechtalks, education, Crockford, web, exponents
Id: hQVTIJBZook
Channel Id: undefined
Length: 63min 47sec (3827 seconds)
Published: Fri Feb 27 2009
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.