Placeholder Image

Subtitles section Play video

  • 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.

Souders: All right, welcome, everyone.

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it