Google I/O 2011: Learning to Love JavaScript

Aug 15, 2023

Google I/O 2011: Learning to Love JavaScript

Alex Russell\r
\r
JavaScript remains one of the most popular and important programming languages in history. Web Developer and Chrome Engineer Alex Russell exposes the timeless strengths of the JavaScript language and why it is a vital part of the open web platform. Come hear what’s next for the JavaScript standard and how to get the most out of the new features coming soon in V8 and Chrome.

Content

3 -> Russell: Good afternoon.

4.3 -> I'm Alex Russell.

5.534 -> I'm a software engineer on the Chrome Team.

6.701 -> Thanks for tearing yourself away from lunch

8.434 -> to come hear about JavaScript.

10.2 -> So like I said, I'm an engineer on the Chrome Team,

14.501 -> and before I joined Google,

15.767 -> I spent a lot of my life working in JavaScript.

18.4 -> I joined the Chrome Team from a web development background,

21.534 -> specifically working on open source JavaScript tool kits

23.3 -> and before that,

24.567 -> working web application development and security.

26.934 -> And before my recent detour into C++,

30.934 -> I spent most of my day trying to figure out

33.033 -> how to make JavaScript do interesting things.

35.767 -> My personal history with JavaScript started in 1997,

39.033 -> I think when a lot of us started to be cognizant of the web.

42.334 -> And at the time, JavaScript was this thing

44.534 -> that was starting to become powerful

46.367 -> and somewhat standardized

47.834 -> and somewhat widely available on the back of the browser wars.

52.567 -> So I want to talk a lot about

54.868 -> how we got to where we are today with JavaScript,

56.634 -> why it's so important, why that history,

58.434 -> that long history continues

60.767 -> to figure into the sorts of things we try to do

63.167 -> with JavaScript on a day-to-day basis.

65.334 -> And I want to take you through what's really

67.667 -> inside of JavaScript.

68.701 -> What is it about JavaScript that it is,

70.767 -> that makes it so different to the languages

72.367 -> that you might be using in your day-to-day work

74.234 -> that aren't JavaScript, because there's a lot that is.

77.534 -> Exactly where are we right now?

79.067 -> Because I think this is also sort of

80.601 -> an ambiguous question, right? If you're a browser bender,

83.3 -> it's easy to say we're this fast--easy-ish.

87.467 -> If you're a web developer,

88.634 -> you can look in your deployed base

89.801 -> and understand who's got what,

91.667 -> but that doesn't necessarily tell you anything

92.767 -> about the future.

94.167 -> And I want to spend a lot of time today talking about

96.067 -> how it is that we are going to get a different future

98.467 -> for JavaScript,

99.601 -> because JavaScript, like the browsers,

100.934 -> is starting to move again,

102.367 -> and I want to tear back the veil

106.667 -> that covers each of these topics

108.033 -> and help you understand exactly what's going on

109.767 -> and how these parts relate to each other, because they do.

112.4 -> The history informs the future,

114.234 -> and the current state informs what's going to happen next.

117.901 -> So JavaScript is a functional language.

120.033 -> So how many of you write in other functional languages

122.367 -> or are familiar with functional languages?

124 -> Awesome.

125.267 -> The front of this talk is going to be something

126.767 -> that maybe just warms your heart and may not be new information.

130.367 -> So JavaScript is a functional language.

132.734 -> In the sort of the history of functional languages,

138.534 -> it supports closures.

139.834 -> Much like Scheme,

141.2 -> it's got this nice first class function system,

145.3 -> and in 1995, Brenda and I hacked it up as a little prototype

150.567 -> which made its way into Netscape 2,

152.434 -> and Netscape 2 was the first browser

154.4 -> to really have any serious scripting supported.

156.767 -> It had DOM level 0, and soon afterwards,

160.601 -> JavaScript sort of, you know,

163.3 -> once it escaped into the browser,

164.634 -> started the standards process at ECMA,

166.968 -> not inside the W3C,

168.3 -> because the W3C wasn't the place for languages.

172.367 -> And in 1997, we got the first version of JavaScript

175.501 -> as a standard.

176.767 -> In 1996, Microsoft shipped IE 3.0,

182.133 -> and that was the first version of JScript.

183.868 -> So we now had two competing,

185.801 -> mostly compatible implementations

187.4 -> of a scripting language for the web.

189.501 -> Nobody knew how big the web was going to be,

191.167 -> although, at the time,

192.334 -> it looked like things were trending up.

194.534 -> Well, we know how that story ends.

195.801 -> Today, you can't ship a credible platform

197.968 -> that doesn't have the web.

199.634 -> In 1999, ECMAScript version 3

203.901 -> was finalized at TC39, which is the technical committee

207.434 -> that is the standards body for JavaScript.

212.934 -> And from its humble roots

214.2 -> as Mocha/LiveScript/JavaScript in Netscape 2,

219.4 -> JavaScript 3, ECMAScript 262-3, the version or the standard

223.834 -> that was released in 1999 has powered us pretty much to today.

228.701 -> It has been the thing that for more than a decade

231.1 -> has been what we think of as JavaScript.

234.167 -> And JavaScript, on the back of that standard,

237 -> has gone pretty much everywhere.

238.767 -> JScript, the component that runs JavaScript inside of IE,

241.868 -> has been built in to the OS for Windows since Windows 98.

244.934 -> You can't get a copy of Windows,

246.901 -> you can't buy a copy of Windows today

248.334 -> that does not include JavaScript in the OS,

251.133 -> and every browser on the planet now includes

253.234 -> at least one implementation of JavaScript,

254.801 -> and these things are moving really, really fast.

256.4 -> I work on the Chrome Team; therefore, I'm partial to V8.

260.2 -> It goes nice and quickly,

261.701 -> but these things are all compatible

263.1 -> to a very high degree.

264.601 -> All of these implementations are separate implementations,

267.033 -> and they're competing on things that aren't,

268.634 -> "Oh, here's a new language feature."

270.033 -> We're collaborating on language features

271.968 -> in the standards committee,

273.033 -> but we're competing on performance,

276.234 -> which is a really great place to be for a language,

278 -> because it takes a lot of investment

279.467 -> to make a language a real success.

280.767 -> It takes a lot of deployment,

282.1 -> a lot of competition, and a lot of investment

283.901 -> to sort of get the really smart guys

285.234 -> that it takes to go make a VM go like hell.

287.667 -> And so JavaScript has been the beneficiary

289.801 -> of this sort of ecosystem of investment in a way

292.434 -> that only a couple of languages before it ever have.

294.667 -> And as a result, today's JavaScript runtimes

298.567 -> and today's JavaScript performance are vastly different

300.634 -> than they have been in the past, even the recent past.

303.734 -> And so every device that you get today,

307 -> including the tablets that were handed out to you yesterday

309.534 -> and the Chrome books that you'll be receiving as attendees

315.4 -> on June 15th,

317.467 -> these all have JavaScript as a core part of their runtimes

321 -> because the web is the platform.

322.367 -> The web is the way that you're going to build

324.234 -> a lot of the applications

325.4 -> that your user is going to care about,

326.601 -> and it's the way to build portably today.

328.267 -> So JavaScript is everywhere, and it's terribly misunderstood.

333.234 -> And I think what I want to do first here

336.334 -> is to talk you through the parts

338.067 -> that most people don't really have a sense of,

340.801 -> when they talk about,

342.133 -> like, what is it that makes JavaScript different?

343.901 -> Because we hear it's a dynamic language.

345.067 -> We hear it's a functional language.

346.4 -> But it looks a lot like C. It looks a lot like Java.

348.434 -> It looks a lot like C++.

349.567 -> And some folks have been doing a great job

351.067 -> in the last couple of years at sort of helping to tear back

353.534 -> the blinders that are on us,

355.868 -> as folks who come from a C or C++ background,

359 -> and help lay out what it is.

361.367 -> But I want to go through it very briefly,

362.767 -> because I think it's important to understand

364.834 -> what's actually in there,

366.267 -> because when we understand what's actually in there,

367.501 -> we'll understand how the language can evolve,

369.467 -> because you don't want necessarily separate--

371.767 -> competing ideas to be existing inside the same language.

374.501 -> You want a language to sort of have a theory of itself.

376.734 -> You want it to be coherent in ways that make it,

380.234 -> so that when you understand one part of the language,

381.734 -> you can understand the next part of it.

383.234 -> And my interest in this is coming from a background

384.767 -> as a web developer,

386.133 -> I serve as one of Google's representatives to TC39,

389 -> the standards committee for JavaScript.

391.067 -> And so I have a particular and keen interest

392.868 -> in making sure that we evolve the language in ways

394.501 -> that are reasonable and solve real world problems

398.534 -> that we've all got.

399.801 -> So JavaScript only has a couple of key languages.

403.734 -> I said earlier that JavaScript is a little functional language,

406.901 -> and JavaScript started out as a very small language entity.

409.1 -> There aren't a lot of core concepts.

410.701 -> There's no type system, per se.

412.1 -> There are types.

413.367 -> You can have a number, or an object, or an array,

417.634 -> but there's no type testing.

419.033 -> There's no way to define your own types, necessarily,

421.901 -> and have them participate at, like, function call time

425.634 -> and have the system throw an exception for you,

427.4 -> unless you do the testing yourself.

429.701 -> And JavaScript reads top to bottom.

431.868 -> JavaScript has run-to-completion semantics.

433.701 -> That means that if you start a body of code,

435.167 -> there's no multithreading in the language.

436.901 -> There's no way for you to sort of fork off some other process.

439.3 -> Anything that does that in a JavaScript environment

442.334 -> is doing it as a built-on.

443.834 -> So browsers with their set timeout and their set interval.

446.634 -> That's all happening outside of the core language semantics.

449.701 -> JavaScript reads top to bottom,

451.067 -> and the interpreter and runtimes read it exactly

453.667 -> and run it exactly that way.

455.1 -> If you see a block of JavaScript code,

456.601 -> it goes from top to bottom, and that'll become important,

459.868 -> as we see in just a minute.

462.367 -> Almost everything in JavaScript is mutable.

464.167 -> That means that you can change nearly everything,

466.367 -> and we'll talk about the several exemptions to this rule,

470.968 -> but those exemptions are very small,

472.534 -> and they're very narrow, but they wind up being powerful.

475.234 -> So that means that if you get an object back from

476.801 -> some function call,

477.968 -> you can probably change it in JavaScript.

480 -> Closure is the way we do private state, though,

481.868 -> so if I get an object,

482.901 -> and everything is mutable,

484.334 -> it means, ah, I might be able to surprise somebody else.

485.734 -> I might be able to go change some state out

487.033 -> from underneath them.

488.367 -> The thing that returned me the object might expect it

490.167 -> back in some reasonably okay state.

493.3 -> Well, the way we do data hiding in JavaScript

495.1 -> isn't through the private key order,

497.4 -> through some method that gives you some sort of a private field

500.033 -> that you can only see.

501.968 -> Instead, we invert the relationship

504.334 -> between classes and functions,

506.734 -> and we treat functions as behavior that can carry data,

510.701 -> versus classes,

511.834 -> which are data that can carry behavior.

513.601 -> And so the last key concept is, instead of having a class,

517.234 -> as you understand it in other languages,

518.534 -> we have prototypes,

520 -> which is to say we don't have this strong "is a" relationship

523.534 -> through a hierarchy of classes.

525.4 -> Instead, we say, when I don't find it here,

526.767 -> please look over there.

528.267 -> It's delegation, and it's a one-link chain delegation

532.767 -> up to a root object that everybody shares.

534.801 -> So we'll talk a lot about how exactly all this works,

537.467 -> how it fits together,

538.701 -> and hopefully you'll understand at the end

541.667 -> how it's going to inform where we can go from here.

544.167 -> I said earlier that JavaScript runs top to bottom.

547 -> That means if I see a piece of code in JavaScript,

549.4 -> one line before the next,

550.734 -> before the next--because there isn't necessarily

553.1 -> a compile cycle.

554.4 -> Most JavaScript runtimes traditionally were interpreters.

557.968 -> That means that the easiest way

559.234 -> to think about your JavaScript program

560.734 -> is as something that is going to happen in a live environment.

566.4 -> So if you had a command line,

568.167 -> and you started typing in commands,

569.434 -> JavaScript runs almost exactly the same way.

572.133 -> Top to bottom, line for line,

574.601 -> it gets evaluated in the order that it is written out

580.968 -> in the program, more or less.

582.968 -> And so statement to statement,

584.567 -> your programs--they can change in ways that are surprising

587.4 -> in other languages.

588.834 -> Where you might otherwise have compile time exceptions,

590.234 -> JavaScript just sort of merrily goes on

592.467 -> and runs the next line.

593.701 -> So whenever we read some JavaScript code,

596.367 -> it's important to think about it simply as running at the top

599.4 -> and going to the bottom.

600.534 -> It's not really some big magical machine

603.534 -> that's going to be out there doing something for you,

605.367 -> and then it's going to start running your program.

607.1 -> It's just running top to bottom.

608.501 -> So when you evaluate JavaScript code,

609.968 -> and you're trying to figure out what's going on,

611.3 -> remember that the line before it may be the thing

613.133 -> that caused the problem.

615.2 -> And JavaScript is functional and object-based.

618.367 -> It's really important to think of functions

622.434 -> as first class in JavaScript.

625.067 -> That means that they're not simply a pointer out

627.067 -> in the world that you invoke against something.

630.834 -> They are actual objects.

632.133 -> I'm going to refer to them through this talk

633.234 -> as function objects,

634.701 -> because function objects are indeed objects that you can go

637.601 -> and hang behavior off of.

638.834 -> But you don't hang behavior off of them

639.968 -> by extending their public API area.

642.701 -> You don't say, "I've got a function object.

644.601 -> I'm going to add some new property to it."

646.067 -> Most of the time, you do that by using functions as scopes.

649.534 -> The only way to create a new scope in JavaScript

651.501 -> is to invoke a function.

653.3 -> When you invoke a function, it sort of creates a new scope.

655.801 -> If statements, while statements, for-in statements--

658.601 -> those things don't create scopes.

659.834 -> Only functions do, so we have this problem of

663.1 -> how do we do beta hiding?

664.234 -> Well, these scopes are really smart,

665.734 -> because these scopes hold on to the variables

667.534 -> that have been defined above them in another scope.

670.501 -> So what we've got here is a function called get counter,

673.667 -> and get counter defines a local variable, I,

675.534 -> and it returns another function,

678.4 -> and that function references the variable I inside of it.

682.534 -> In other languages like C++ or Java,

686.734 -> you really can't do anything here,

688.2 -> because that variable I is going to go out of scope

690.234 -> in the return function.

691.467 -> We're allocating a new function here,

692.767 -> but that inner function is going to hold on to I.

695.868 -> It actually allocates private memory to store a reference

699.133 -> to I on the function object

701 -> that's returned out of this statement here.

704.1 -> It, again, inverts the relationship.

705.901 -> It's not storage with behavior.

708.667 -> It's behavior that has hidden storage.

710.968 -> And so the way we do private variables

712.4 -> and the way we do data hiding in JavaScript

716.267 -> is to use this idea of a closure, something that encloses

718.534 -> its lexical scope

719.934 -> and holds on to variables

721.601 -> as a way of passing behavior around.

723.701 -> So we can call the get counter function.

725.934 -> It hands us back a function object.

727.501 -> We can call it multiple times, and that state isn't gone.

730.1 -> We can still see the variable I from inside the outside one,

732.834 -> but it isn't referenceable.

734.367 -> We can't go and inspect some property on that function object

737.3 -> and find out which variables it's holding references to.

740.4 -> It gets GC'd just like everything else in the language.

744.367 -> So these are first class functions.

745.734 -> These are functions that are things in the system.

748.634 -> They're actually objects. You can create them.

750.767 -> You can add properties to them. It can enclose scope.

753.734 -> They're not simply inert bodies of code that get run.

757.801 -> They're participants in the object model.

759.801 -> They're participants in the storage system.

762.3 -> You can use them--I know the fundamental concept

764.4 -> that underpins a lot of the patterns

766.334 -> that we're going to see later.

768.067 -> So these functions work together

770.667 -> with a lot of other sort of functional ideas

772.934 -> about how a program language can be structured.

775.133 -> In JavaScript, we have a filter, map, reduce,

777.167 -> and for each method on the array prototype,

780.133 -> which means that every array in the system has these methods,

782.534 -> which means that instead of having an external iterator,

785.234 -> you have an internal iterator.

786.434 -> You have something that can call a function

788.4 -> across some set of arguments,

790.133 -> and so you wind up creating a stack of stuff

792.501 -> that you'd like to do in terms of behavior.

794.567 -> Instead of passing data structures around

796.534 -> and around and around, you pass in arguments to functions,

798.734 -> and that sort of unwinds the thing

800.267 -> that you were trying to get done.

801.4 -> You express your program's intent

803.501 -> in the form of nested functions

805.601 -> that are going to unwind to some result,

808.467 -> not linear code that's going to be executed

811.601 -> by passing in the same data structures

813.534 -> over and over and over again.

814.868 -> So these sorts of things are not hard and fast rules

819.3 -> about any programming language.

820.434 -> Like, you can have an endless debate about

822.567 -> what makes something a functional programming language.

824.634 -> Can it have side effects?

825.767 -> Can it not have side effects? You know--

828.567 -> How completely does it support some particular

831.067 -> set of macro languages, or hygienic macros,

833.234 -> or whatever it is?

834.601 -> Many people define functional languages differently,

837.534 -> but for the intents and purposes here,

839.334 -> we're just going to say it has closures,

840.334 -> first class functions,

841.701 -> and some concept of using those sorts of things

844.834 -> to compose behavior nicely together.

848.3 -> So another important thing to remember about JavaScript

850.501 -> is that everything is just an object.

852.734 -> So there aren't a lot of key concepts in JavaScript,

855.033 -> and so you can think of it as sort of a lazy language design.

858.067 -> It doesn't really have a lot of specialized,

860.601 -> compartmentalized things

862.2 -> to hold on to different concepts

863.2 -> that you might encounter.

864.4 -> Instead, it just relies on the same systems

865.767 -> over and over again.

867.1 -> One of those systems is this small type system,

871.234 -> where objects are objects, that first object literal there.

875 -> It's an instance of object. Arrays are objects,

877.501 -> which means that arrays are instances of objects, too.

879.834 -> And functions are also objects.

882.167 -> In this case, I've got a paren here,

885.033 -> which is going to create a new expression.

887.033 -> I've got a function, which I define inside of here.

889.133 -> It doesn't have a name. It's an anonymous function.

890.734 -> You can have anonymous functions in JavaScript.

893.334 -> And the result of this expression

894.968 -> is just going to be that function object.

897 -> And the function object also is an instance of the object type,

901.167 -> which means that nearly everything in the system

903.033 -> that you encounter is going to be an object.

905.067 -> This is really powerful, because it means,

906.434 -> as we'll see later,

907.767 -> when we compose things, and everything is mutable,

910.133 -> we can start to change the behavior

911.467 -> of large parts of the system all at once.

913.767 -> And every object in the system acts more or less like a map.

916.1 -> There's no separate map type in JavaScript.

918.033 -> So if you want a map, just take an object.

920.133 -> This is where-- sort of where JSON comes from,

922.501 -> this object literal syntax that we've got here,

924.901 -> where we're defining an object

926.1 -> with a single property and a single value.

928.234 -> It allows us to de-reference properties the same way.

930.267 -> So the data operator does almost exactly the same thing

932.868 -> as this map operator.

934.234 -> It just finds a property by its name

936.2 -> and returns it out the other side.

937.601 -> So in JavaScript, everything is an object.

940.4 -> Objects operate like maps. That's pretty cool.

943.234 -> Arrays do exactly the same thing.

944.667 -> And arrays are very confusing when you start out working

947.767 -> in JavaScript,

948.968 -> because you think array is some separate thing

951.1 -> over on the side. Arrays are not objects.

953.667 -> Arrays are this linear bag of memory

955.801 -> that you're going to access with an integer someplace.

958.367 -> And as a result of that,

960.667 -> you're not going to be surprised by some other identity.

964 -> But you are, because very often what happens is

966.067 -> you go and extend an object. You add a new property to it.

968.3 -> In this case, we're going to add this other greeting property

971.2 -> to an object dynamically, and-- or to an array dynamically.

975.3 -> And as a result, when we go into a for-in loop,

978.367 -> this is now an innumerable property on this array.

982.434 -> We might get surprised, because we see these other things

984.767 -> showing up in our object.

987.3 -> Well, that's weird.

989.1 -> I mean, we iterated over the public properties.

992.067 -> Isn't 0 just an integer index thing?

994.734 -> It's not a public property, right?

996.334 -> Well, remember that everything in JavaScript

998.434 -> just sort of falls back on these core concepts.

1000.667 -> And if you think about the array integer indexing

1004.901 -> working exactly the same way that property indexing does,

1007.834 -> it all makes sense.

1008.968 -> Yeah, in the implementation,

1010.3 -> there might be some special machinery to make arrays

1012.033 -> efficient or to pack them tightly,

1013.634 -> so that you don't wind up slowing things down

1015.968 -> unnecessarily.

1017.3 -> But in the language semantics,

1018.901 -> what happens here when I say,

1020.067 -> "Please give me item 0 out of this list,"

1022.801 -> is that it turns that 0 into a string,

1025 -> and then does a map lookup.

1026.801 -> That's all it does.

1027.968 -> So the only magical thing about arrays

1029.3 -> versus any other kind of object in the system

1031.4 -> is that, when I push onto an array

1033.033 -> or I set the length property,

1035.467 -> it actually affects which properties are visible.

1037.868 -> The length property is the only thing in an array

1039.567 -> that's actually magic.

1041.067 -> It has a little bit of syntax for defining arrays naturally;

1043.267 -> but other than that, arrays are just objects.

1045.534 -> Things get turned into strings and then de-referenced that way.

1048.067 -> The spec is pretty clear about this.

1049.534 -> So JavaScript doesn't have that many core concepts.

1053.167 -> And if you understand them, you can understand

1054.801 -> what's going on in your system.

1056.3 -> So we've got mutable objects. We've got closures,

1058.934 -> which are behavior that carries data

1060.501 -> and not data that carries behavior.

1062.767 -> We've got mutable objects,

1064.701 -> and we've got everything being an object

1066.467 -> and everything being an object also being a map.

1069.3 -> Okay, that's not a lot of concepts, so far,

1071.3 -> for a programming language.

1072.834 -> And we can use these to build some really powerful stuff.

1076.267 -> So I mentioned mutability,

1077.467 -> and I said everything is mutable.

1079.167 -> Just a really quick example, we can add new properties

1081.801 -> at runtime to every object.

1083.2 -> Remember how I said that JavaScript runs top to bottom?

1086.534 -> When you're reading a program like this,

1088.1 -> it's not like my object type somehow was extended

1090.634 -> and, therefore, every object of this type is going to have

1092.367 -> one of these properties.

1093.734 -> I'm just adding a new property to the object directly.

1097.901 -> So in this case, object.item is being replaced,

1101.667 -> and object.item2 is simply being added.

1104.767 -> These are exactly the same operations,

1106.434 -> as far as JavaScript is concerned.

1108.367 -> The dot operator just finds you the object

1110.534 -> and then assigns to it. That's all it's doing.

1112.601 -> Every object in the system is extensible.

1114.501 -> Most of them are mutable.

1116.567 -> Most of the values are mutable, and we run top to bottom.

1120.467 -> So that means that when I come down here,

1123.1 -> and I delete a property off of the object,

1124.901 -> the very next line isn't going to see it.

1126.4 -> But if I had said console.log(obj.item)

1128.334 -> one line above, it would see it there.

1130.534 -> This is not a compile time thing.

1131.934 -> It's just doing what you said, line after line,

1135.1 -> statement after statement, expression after expression.

1137.601 -> It seems really simple.

1139.067 -> It seems pretty obvious, but very few programming languages

1141.4 -> that you might be using in a compiled environment

1143.3 -> work this way.

1145.267 -> So I mentioned that closures are the other side of classes,

1147.367 -> whereas classes are sort of a nice way

1148.834 -> of saying, "Here's a structure of data.

1150.4 -> "I'm going to associate some properties with them,

1152.133 -> and maybe they'll have some type behavior as well."

1155.634 -> In this case, we're going to create something

1158.2 -> that we would call a class in JavaScript.

1159.834 -> We know it's a class,

1161.133 -> because it's got an uppercase B for the name.

1163.167 -> This is not a language enforced semantic.

1164.601 -> JavaScript doesn't necessarily have classes today.

1168.634 -> This is just a convention. And as we'll see, conventions

1170.534 -> figure large in day-to-day JavaScript programming.

1174.067 -> So remember every object is mutable.

1175.934 -> So we're going to create down here,

1178.667 -> we're going to create a new instance of our behavior class.

1182.801 -> We're going to extend the local object, this dot,

1186.534 -> with the variable that was passed in the configuration,

1188.534 -> and then we're going to extend the object again

1190.467 -> with a function called do it.

1192 -> In this case,

1193.334 -> when I call the do it method of my behavior instance,

1196.734 -> it's then going to run through,

1197.834 -> and it's going to say this.config

1199.601 -> and go grab some flag off the configuration.

1201.767 -> Okay, so we stored some property and some behavior on the object.

1205.234 -> This looks a lot like what you might expect out

1206.801 -> of another object-oriented language.

1208.2 -> The declaration syntax is a little bit funky,

1210.367 -> but you sort of understand it, right?

1211.801 -> I've added a method. I've added some data.

1214.033 -> The data operates on the local objects method.

1216.1 -> Sweet-- or other way around.

1218.3 -> Strike that, reverse it.

1220.934 -> New behavior, passing a flag, then I call it false.

1223.234 -> I get a behavior object,

1224.634 -> and now I can call a method that uses that behavior, right?

1227.934 -> So it's going to look at the local object, this,

1232.467 -> for the configuration, and it may change its behavior

1235.167 -> based on that configuration by passing some other value to it.

1238.534 -> Make sense? Cool? All right.

1241.133 -> So this is maybe a little bit more idiomatic for JavaScript.

1244.067 -> It's the flip side of that.

1246.133 -> Instead of creating a class that I created an instance of,

1249.033 -> I'm going to create a generator

1251.834 -> that's going to pass me back a function object,

1254.067 -> which is going to hold on to the state.

1255.667 -> I'm not going to go create a class for it.

1257.1 -> I'm going to create a behavior generator.

1259.4 -> You can think of them doing the same thing,

1261.2 -> just the flip side of it.

1262.334 -> So instead of saying new behavior,

1264.634 -> I'm going to say bind me a behavior,

1267 -> which when I call this,

1269.1 -> note the lack of the new keyword here,

1271.4 -> I'm going to pass into configuration.

1273.634 -> Like we saw earlier,

1274.901 -> I'm going to pass back out a function object.

1276.434 -> This is a new function object.

1277.667 -> Every time I call this method, bind behavior,

1279.734 -> it's going to pass me back out a new function object.

1282.167 -> So I'm actually having a new function object allocated here,

1286.4 -> and that function object is going to have, again,

1288.567 -> some private storage, and that private storage is

1290.701 -> going to hold on to the config variable

1292.834 -> that was passed into the outer function, right?

1294.901 -> Because each one of these is a new scope,

1296.501 -> and because scopes can hold on to the variables

1298.734 -> that they were able to see when they were defined,

1301.634 -> the function object that gets passed out of here now

1303.701 -> has a reference.

1304.868 -> It's holding on to that local state.

1307.467 -> In this case, it's going to be the object that was passed in.

1310.033 -> This might go out of scope here in every other place

1312.534 -> in my program.

1313.834 -> I may not be able to get a reference back to this object,

1315.434 -> but my behavior, the B variable that was passed back out,

1320.267 -> will have access to that data

1322.033 -> because it's being held on to internally.

1323.734 -> It's not going to be garbage collected out

1324.901 -> from underneath me.

1326.2 -> Closures are the way to invert the way you think

1328.133 -> about your programs.

1329.434 -> You don't create classes that are state with data,

1332.868 -> state with behavior attached.

1334.367 -> You create behavior that holds on to the state that it needs,

1337.267 -> and you can pass that behavior around,

1338.601 -> because functions are first class.

1342.234 -> So I mentioned earlier that the last sort of big conceit

1345.767 -> in the language is that we don't have a way of saying,

1348.434 -> hey, here's a class of stuff.

1350.868 -> Instead we say, if you don't find it here,

1353.601 -> don't look at my like chain of class inheritance.

1360.067 -> Instead, just go look at that other object.

1362.467 -> Remember how I said over and over again

1364.367 -> that JavaScript just reads top to bottom?

1367.133 -> I get some code.

1368.434 -> The thing executes front to back, top to bottom.

1372.334 -> We're going to see the exact same thing here,

1374.033 -> because what happens every time you call the .operator

1376.767 -> is exactly the same thing.

1377.901 -> I'm going to create some variable

1379.834 -> that I'm going to call my delegate.

1381.133 -> It's an object. It's got a single property.

1383.267 -> Okay, cool.

1384.767 -> There's a new ECMAScript 5 method called object.create.

1388.1 -> There's other ways to do this in older versions,

1389.534 -> but they're a little bit mind bending,

1390.534 -> and we won't go over them.

1391.834 -> But object.create-- the easiest way to think of it

1393.267 -> is that it creates a new object which will look at the object

1397.033 -> that you pass as its first property

1399.701 -> if you don't find a value with this same property name

1403.067 -> on that object.

1404.601 -> So let's say--and in this case, I'm going to create object 2

1409.534 -> and have my delegate be the delegate.

1411.667 -> And so when I reference a property out of object 2,

1414.934 -> it's going to go look it up dynamically,

1416.734 -> and if it doesn't find it on object 2 directly,

1419.2 -> it's going to go look it up off of the delegated 2 object.

1421.901 -> It's going to go, dynamically go

1423.367 -> and try and find it over there.

1425.234 -> Well, we created another object.

1427.868 -> In this case, we're setting a local property on that object,

1432.033 -> whose name is item, whose value is value.

1434.934 -> And that means that when I look it up at runtime

1436.701 -> directly top to bottom, left to right,

1438.834 -> what I see is that I don't get the value

1441 -> that was set on my delegate.

1442.133 -> I get the value that was on the local object.

1443.834 -> The .operator doesn't fail on the local lookup.

1446.367 -> It finds it on the local object.

1447.901 -> And instead of looking up the chain, it says,

1449.434 -> ah, I'll just give you this object's value right back.

1452.667 -> So JavaScript is incredibly dynamic

1454.634 -> when it comes even to looking up properties on objects.

1457.133 -> There's not some fixed list of stuff that you can do.

1459.501 -> You can change the delegation,

1460.734 -> and you can change the properties

1462 -> that are available on every object

1463.667 -> that you're delegating to, or your local object,

1466.2 -> and that changes what happens when you go

1467.634 -> and look stuff up at the very next line.

1470.1 -> So in this case,

1471.3 -> if I go and I change the value on the delegate,

1474.334 -> I change the item value on the delegate,

1475.834 -> remember that object 2 doesn't have a local property

1478.033 -> called item.

1479.1 -> If I fail on that lookup on object 2,

1481.367 -> it just goes and says, ah, okay, let's go consult my delegate,

1484.2 -> and that delegate is now going to have the new value.

1486.267 -> So the new value has been shadowed all the way

1488.234 -> through to everything else in the system

1489.634 -> that is delegating to that object.

1491.601 -> This is incredibly powerful.

1493.033 -> The dynamic nature of JavaScript means that

1495.334 -> because it reads top to bottom,

1496.634 -> because almost everything is mutable,

1498.133 -> and because I can delegate to most other objects

1500.367 -> when I create something,

1501.801 -> I wind up in a place where I can create brand-new behavior

1505.2 -> at runtime.

1506.767 -> I can compose things on the next line that didn't exist before,

1509.1 -> or I can change the behavior of other objects

1510.501 -> in the system,

1511.701 -> based on what they're delegating to.

1513.1 -> This turns out to be a great way

1515.167 -> to go build up a lot of the constructs

1517 -> that we get in other languages for ourselves,

1518.701 -> because JavaScript may not give them to us naturally.

1521.701 -> This power is the sort of thing that really drew me

1524.434 -> to JavaScript as a young programmer.

1526.968 -> I didn't really understand what I was dealing with.

1528.834 -> I remember I had a friend who told me,

1531.033 -> after I'd written some article about how to do

1534.234 -> signals and slots, some sort of aspect-oriented

1536.367 -> event style thing, he's like,

1538.834 -> "Well, why didn't you just use a closure for that?"

1540.3 -> And it took me a long time,

1541.801 -> probably six months or more after that,

1543.2 -> to sort of really understand what it was

1545.133 -> that he meant when he said, "Just use a closure for that."

1547.2 -> I didn't understand that you could hide data

1548.634 -> inside of functions.

1549.834 -> I didn't understand that JavaScript sort of

1551.033 -> ran top to bottom.

1553.234 -> But these core concepts allow you to create

1555.434 -> all sorts of really powerful stuff,

1559.367 -> assuming we understand what happens with the word "this."

1562.501 -> So the word this is really special.

1564.3 -> In order--Because we don't have classes that wire up

1566.3 -> this inheritance hierarchy,

1567.734 -> and because we're always delegating at runtime, right,

1569.734 -> every .operator sort of does the dynamic lookup

1573.234 -> on the local object--

1574.434 -> looks at its delegate, looks at its delegates.

1576.267 -> The this object is a way of saying,

1578.667 -> okay, whatever scope I'm in,

1581.501 -> execute the next lookup against the local object,

1586.334 -> which means that the this keyword in any function

1589.701 -> isn't pointing at some fixed object.

1591.834 -> It's not fixed when I necessarily say,

1594.667 -> you know, create me an object. It's promiscuous.

1596.901 -> The this keyword points at whatever object my function

1599.067 -> is being called through.

1600.901 -> Right, remember function objects are first class?

1602.667 -> They don't actually sort of carry around relationships

1606.434 -> to their class or the thing that they were defined in.

1608.767 -> They hold their own data.

1610.1 -> So the this keyword is a nice little syntactic out

1612.634 -> which lets you say, okay, whenever I look up a property,

1618.434 -> which happens to be a function,

1619.901 -> and I call it, the .operator for method calls says

1624.934 -> don't just return it.

1626.3 -> But if I evaluate it directly, use the .call property

1630.501 -> of the function object

1631.934 -> that's returned and call it in the scope of the object

1634.767 -> on the left hand side of the .operator.

1637.067 -> I know this is a little bit maybe tricky,

1638.634 -> but the easiest way to think about this is that in order to

1641.634 -> wire up this behavior correctly,

1643.1 -> so that it sort of does what you expect out of other languages,

1646.434 -> we rely on the function being first class,

1648.434 -> meaning it has its own call and apply methods.

1651.067 -> You don't say necessarily, hey, function,

1653.934 -> you're not going to work if you're not called inside

1655.167 -> of some other object.

1656.601 -> I can call any function in the scope of any other object.

1660 -> I can assign a function to any other object and then call it

1662.868 -> through that object dynamically, right?

1665.734 -> Everything is mutable.

1667.334 -> Functions are first class. Why not?

1668.834 -> So in order to get that to execute

1670.2 -> against the right object,

1671.4 -> you use the this keyword to go grab

1672.968 -> the value out of the thing

1674.567 -> that was on the left hand side of dot,

1676.367 -> which is exactly the same thing as saying

1678.234 -> please call my function,

1679.367 -> which I pulled out of that object,

1680.767 -> in the scope of the object on the left hand side.

1683.534 -> Cool?

1685.2 -> All right.

1686.701 -> Okay.

1688.567 -> So all this fits together in ways that allow us

1690.801 -> to recreate a lot of this stuff that we expected

1692.667 -> in other languages.

1693.667 -> A lot of this is convention.

1695.033 -> A lot of this isn't necessarily the sort of thing

1696.601 -> that you're going to have language level

1698.234 -> or syntactic support for,

1699.601 -> but if you understand what's going on there,

1701.467 -> those sort of core little ideas about mutability,

1706.133 -> scope, functions as first class citizens, and dynamic behavior,

1712.067 -> we can start to recreate things like classes.

1714.834 -> So here we've got an item type,

1716.868 -> which is we're going to think of as a class.

1719.701 -> It's not really called a class.

1721.501 -> It's just a function. It's got the word function.

1723.2 -> As you saw earlier,

1724.567 -> when you use the word new in front of any function,

1726.634 -> it sort of creates an object,

1728.167 -> calls that function inside the context of that object,

1730.4 -> and then returns that object back to you.

1732.3 -> That's the way to think about the new keyword.

1734.267 -> So we're just going to create a function,

1736.1 -> which we're going to call with new sometime later,

1738.934 -> and inside of it we're going to execute

1740.534 -> a couple of other functions.

1742.033 -> Now, we just saw .call, and .call calls

1744.801 -> those other functions in the scope of the object

1747.133 -> that we're being executed in or that we want to pass in.

1750.2 -> In this case, we're going to pass in the local object,

1752.868 -> and we're going to do it twice,

1754.067 -> which means that inside of tract,

1756.4 -> we're going to assign a new property to this--

1760 -> which is to say the object that was passed in--

1762.434 -> and inside of logged, we're going to assign a new method

1765.868 -> where that method is going to go dynamically look up the ID

1769.133 -> and log it out.

1771.167 -> So we call these mix-ins.

1772.467 -> These two methods up here were written in a way

1774.367 -> that they don't delegate to anything else.

1775.968 -> They don't assume anything about the behavior of their methods

1780.968 -> or the properties that they define.

1783.033 -> And instead, they just add stuff.

1784.701 -> They just add stuff dynamically

1786.067 -> when they're invoked against some other object.

1790.334 -> So I could call them in any other context,

1792.2 -> but in this case, I can use them in the item type constructor

1795.934 -> to extend the item type with some new stuff.

1799.067 -> We saw earlier how delegation allows you to

1801.968 -> create new delegate relationships between things,

1806.033 -> and functions also have this idea of a prototype.

1808.267 -> This is the exposed version of the thing we saw

1809.934 -> before with object.create,

1811.3 -> where I can say, please wire up this relationship

1813.033 -> so that this object, when you don't find it here,

1815.801 -> looks at that thing over there.

1818.1 -> So if we create a new item type,

1821.434 -> what we'll see is that it has an ID,

1823.667 -> and it has a type associated with property added to them,

1827.434 -> which is pretty good. And if we create another one,

1830.2 -> the counter is incremented,

1831.634 -> and the type is still assigned to the same value.

1835.133 -> But if we create a new sub item type,

1837 -> what we see is that, because the prototype created

1841.701 -> a new property called type with a new value,

1846.4 -> again, the delegate system faults on the local object,

1850.3 -> looks at the object's prototype--in this case,

1853.167 -> SubItemType.prototype-- pulls it out of there

1856.3 -> and doesn't fault all the way through to ItemType.prototype.

1859.734 -> So we can compose these things together in a way

1861.501 -> that gives us something like classical inheritance.

1864.267 -> It's not exactly the same thing.

1865.501 -> All this is dynamic.

1866.634 -> I can go and change these prototypes.

1867.901 -> I can change these objects later.

1870.2 -> But I've got the ability to factor out code

1872.667 -> into something like a macro or a trait, using mix-ins,

1876.267 -> and I've got the ability to create

1878.267 -> an entire subclass relationship,

1880.868 -> where I define new function types

1882.601 -> which defer to their super classes

1885.133 -> for a lot of their behavior.

1886.834 -> All right, we're starting to get someplace.

1888.534 -> These core concepts have given us the ability to

1890.367 -> define things that the language didn't give us naturally,

1893.767 -> but we can go get for ourselves.

1896.4 -> You know how I said that everything is mutable,

1898.434 -> more or less?

1900.534 -> That means that we can go and extend the stuff

1902.767 -> that is deferred to by almost every object

1905.1 -> in the system, right?

1906.1 -> Remember, arrays are objects.

1908.1 -> Objects are objects. Functions are objects.

1910.801 -> Well, those things have prototypes, too.

1912.467 -> They have exposed objects,

1913.901 -> which are--they defer to when you don't find a property

1916.434 -> in the local object.

1917.901 -> So a radar prototype is, again, an object which is mutable,

1921.367 -> and every instance of array, every array in the system

1924.467 -> that faults on some property is going to go look it up off

1927.634 -> of this object instead. So I can extend it.

1930.3 -> I can say array.prototype.clear is a new function.

1932.801 -> I can extend every single array in the system at runtime,

1936.567 -> because the next line is going to look it up

1938.667 -> through exactly the same mechanism

1941.767 -> as everything else, right?

1943.1 -> This is not me changing the type of array.

1945.734 -> I'm just extending it dynamically.

1947.467 -> I'm creating a new thing for you to hit,

1950.1 -> when you don't find the property in the local array object.

1953.2 -> And I'm going to add to.

1954.567 -> In this case, they're going to return new arrays

1956.334 -> when they're done, and so I can chain them together.

1958.968 -> And so this is how you can sort of create

1960.334 -> little dynamic languages in JavaScript.

1962.801 -> You can create DSLs in JavaScript

1964.133 -> by changing the things that you delegate to.

1966.567 -> If you create new objects,

1968.133 -> and they delegate to some prototype,

1969.667 -> and you can mutate that prototype,

1971.234 -> well, then you can change almost everything about the system.

1975.334 -> Yes, you can change almost everything about the system.

1978.501 -> And, yes, it is a huge maintainability nightmare.

1980.834 -> This is really good when your code can do it.

1983.267 -> This can be a huge problem when everybody's code can do it,

1986.267 -> especially as you get into larger code bases.

1988.467 -> So collectively, as a community,

1991.1 -> the JavaScript world has started to learn these patterns

1993.801 -> of practice, which they say, please don't ever go

1997.234 -> and mutate array.prototype.

1999.367 -> Please don't change object.prototype,

2001.501 -> so that you don't wind up

2003.467 -> stepping on somebody else's toes,

2004.834 -> stepping on somebody else's extensions.

2006.567 -> But this is power that we'd really like to have.

2008.367 -> This is power that we'd really like to be able

2009.801 -> to take advantage of.

2011 -> Being able to extend methods in the system

2012.601 -> is the sort of thing

2014 -> that we've seen work pretty well in languages like C#,

2015.934 -> where they have extension methods to interfaces.

2018.467 -> We really want to be able to use this,

2019.501 -> because it shortens up our code.

2020.734 -> It makes it dynamic. It makes it easy to read,

2022.467 -> and it makes it possible to build up the language

2024.868 -> to meet us halfway,

2026.834 -> which is a great feature of many dynamic languages.

2029.567 -> So JavaScript has this incredible dynamic behavior,

2034.167 -> which gives us a lot of power,

2035.501 -> and so we wind up using it to do all sorts of things

2038.4 -> that the language doesn't necessarily,

2040.4 -> because it's a little language, have built-in support for.

2043.067 -> So in this case, I'm going to, again,

2045.801 -> create an expression that has an anonymous function

2048.1 -> defined inside of it.

2049.367 -> But, instead, I'm going to do some stuff here

2050.767 -> where I'm going to define a local object, right?

2053.567 -> We've seen this before,

2054.868 -> that might get captured in an enclosure;

2056.133 -> and, in fact, it's going to here.

2058.434 -> But the little piece of sophistry

2061.968 -> at the bottom there,

2063.234 -> or in the middle there, where I end the function,

2066.701 -> I end the expression,

2068.1 -> which is going to return that function

2070.801 -> as the result of that expression,

2072.334 -> and then I invoke it immediately,

2074.267 -> means that what happens here

2075.534 -> is that I've sort of created some code

2077.701 -> and just run it directly.

2079.467 -> I've just top to bottom

2080.801 -> run some code, which is going to define a local variable,

2084.1 -> create a function-- which is not local,

2085.934 -> which is going to get exported back out to the global scope,

2089.1 -> but that function can see the local stuff, right?

2091.767 -> So I can sort of hide away in my own private stuff

2094.334 -> inside of my module by putting it in this pattern,

2095.868 -> using VAR for the stuff.

2097.467 -> It's a local and emitting VAR for the stuff that's global.

2100.367 -> That's pretty good.

2101.734 -> We've got some sense of modularity, again,

2103.434 -> built on this few set of prototypical properties

2107.501 -> of the language:

2108.834 -> mutability, functions as first class and functions

2111.067 -> as the only things that create scope,

2112.968 -> the ability to modify nearly everything,

2116.133 -> and closures as a way to bind behavior to data

2120.834 -> and not the other way around. Okay, so as you can imagine,

2124.968 -> we've seen a couple of places here now

2126.334 -> with classes and now with modules,

2128.067 -> where we could start to use these patterns together

2130.701 -> to start to build up our little library of stuff

2133.501 -> to help us meet the challenges

2134.767 -> that we've got in the large code base;

2136.267 -> and, in fact, nearly every large code base

2138.167 -> has a library like this.

2140.701 -> The world of JavaScript libraries

2142.1 -> has a lot of different answers to a lot of the questions

2144.4 -> that you want. So for modularity,

2146.534 -> it'd be great if we could sort of have a script loader

2148.901 -> that would pull in a bunch of stuff.

2150.367 -> It would transitive dependency management,

2151.767 -> and it would put our stuff inside of this body of code

2154.834 -> that we could then think of as something

2156.968 -> that has dependencies but can also hide local state.

2159.868 -> So this is the closure example.

2161.267 -> This is the tree control, and these are its dependencies.

2164.634 -> And it does almost exactly this, right?

2166.067 -> This is the module that it might define,

2169.3 -> and it's going to export some stuff.

2171.634 -> Okay, that's pretty good.

2173.934 -> But then you look at other JavaScript libraries,

2175.934 -> and they do almost exactly the same thing.

2177.634 -> Here's a tree control from the tool kit

2179.4 -> that I used to work on, digit.

2182.067 -> And so that does exactly the same thing, right?

2185.267 -> We've got this module pattern here,

2186.901 -> where that's going to be what you define inside of it.

2189.467 -> And at the same time, these two syntaxes

2192.767 -> and these two semantics aren't interoperable.

2195.1 -> You can't use them together. That's not great.

2197.667 -> Now, we're in a place where we have all of this raw power,

2200 -> and we can start to harness it in ways that solve our problems,

2202.634 -> but we can't say the same thing unless we all agree a priori

2206.3 -> which sort of patterns we're going to use

2207.767 -> and in which style we're going to use them.

2210.567 -> So this is the role of the language.

2212.701 -> This is where language evolution can really start

2214.901 -> to pay off some big dividends.

2216.767 -> And so this is Dave Herman's simple module proposal syntax,

2222.501 -> and this is something like the array,

2225.1 -> the tree control requirements written out in the new syntax.

2230.033 -> As you can see, we actually have syntax saying

2232.968 -> this thing is going to be a module.

2234.2 -> I'd like you to acquire it.

2235.501 -> I'd like you to import these sets of things

2238.267 -> into my local scope.

2240.601 -> And because we've got syntax for this in harmony,

2243.934 -> which is the next version of ECMAScript,

2246.267 -> we've got the ability for everyone

2247.801 -> to agree on what it is you're trying to get done.

2249.934 -> Because you have syntax,

2251.334 -> no one now has the incentive to go write their own thing.

2254.467 -> You can start to rely on there being one canonical way

2257.868 -> of saying here are my exports, here are my imports.

2261.267 -> Here's how it's done.

2262.434 -> And so tool kits can start to interoperate.

2264.434 -> They don't have to continue to compete

2265.934 -> or, you know, reinvent

2267.701 -> on the basis of a low level set of things

2270.367 -> that you might hope would be provided for you

2272.4 -> in the language.

2274.067 -> The same thing goes for classes.

2275.567 -> You know how we saw all that boilerplate earlier,

2277.534 -> where you had the mix-ins were for functions,

2279.234 -> and the classes which were defined as functions--

2281.567 -> well, they all have the same word, function.

2284.033 -> How do you know it's a function?

2285.334 -> Again, we saw the word function reused to go define

2286.901 -> that closure,

2288.2 -> which gave us the scope for using the module pattern.

2291.2 -> Well, the word function gets a lot of use,

2292.834 -> and in fact, it is used so often

2295.4 -> that it's hard to understand exactly

2297 -> what it is you're reading sometimes,

2298.901 -> if you're not familiar with all of these patterns.

2300.734 -> And so nearly every tool kit comes along

2303.467 -> and creates a shorthand to help you define a class,

2306.167 -> because, you know,

2307.434 -> you can just write a function that'll do it.

2308.667 -> Closure does it.

2312.234 -> Prototype does it.

2314.2 -> You can imagine that MochiKit

2315.834 -> or Dojo all do it slightly differently,

2317.534 -> and these all lead to slightly different semantics,

2319.467 -> because the way that you wire up those relationships internally--

2322.667 -> and I showed you one way with using traits

2327.534 -> or mix-ins inside of constructor functions.

2329.868 -> They make different decisions.

2331.234 -> You can compose this stuff a lot of different ways,

2332.734 -> because you're always sort of cobbling it together

2334.467 -> from the raw material that's already in front of you.

2336.734 -> It's incredibly powerful,

2337.901 -> but with that power comes the requirement

2339.734 -> that you have to get a bunch of people to agree with you

2341.868 -> about how to use it.

2343.501 -> And in this case,

2344.667 -> a bunch of well-meaning library authors came up

2346.901 -> with really good solutions that fit their constraints.

2349.501 -> And in this case,

2351.2 -> they all differ a little bit in terms of

2352.701 -> the underlying semantic, and that's a little bit frustrating

2354.734 -> when you want to just share a little bit of code

2356.467 -> with somebody over there.

2357.701 -> So what we'd like to do is say what we mean.

2360.501 -> So this is a little bit of code that comes from

2363.4 -> Marcin Wichary's awesome Pac-Man demo,

2366.667 -> but this wouldn't be how you'd write it today.

2368.834 -> This is how you'd have to write in the future.

2371.133 -> Or this isn't how you would have to write it today.

2373.033 -> This is what you would like to be writing.

2374.3 -> You'd like to say, I've got a class.

2375.934 -> It's got a constructor body, and it's got some methods,

2379.367 -> and then I've got a subclass which,

2380.968 -> you know, wires with that prototypal relationship

2383.1 -> with the other thing. It's got a constructor body,

2385.868 -> and it defines some properties on its prototype.

2388.534 -> What we'd like to do is have this syntax map

2390.701 -> to exactly what we saw before, right?

2392.367 -> We don't want to change the fundamental idea

2396.267 -> of what the language is.

2397.601 -> Prototype based, functions as first class,

2400.133 -> closures to carry state, top to bottom evaluation,

2403.701 -> delegation and not classes.

2407.033 -> When we introduce a syntax for the word class, right,

2409.834 -> what we would like for this to have happen here

2411.934 -> is when we evolve the language,

2413.3 -> we want to hold on to that fundamental set of things

2415.934 -> that define JavaScript as JavaScript,

2417.501 -> so that you can understand old code in the context of new code

2420.234 -> and that JavaScript can maintain a lot of that dynamic,

2422.567 -> which pays off so well when we need to start doing things

2425.534 -> that the language doesn't provide for us.

2426.834 -> Because what we've seen today is

2428.3 -> that we've put together a whole series of things from raw parts,

2432 -> just little raw material, things that are very high level,

2434.3 -> very high level constructs that you're going to need to use,

2437.767 -> that you might not expect to be there on JavaScript,

2440.367 -> but JavaScript provides them for you.

2441.734 -> And it's easy to love a language

2442.834 -> that gives you that kind of power.

2445.4 -> So we wanted something that

2446.868 -> we in the standards committee call de-sugaring.

2448.3 -> And de-sugaring is the concept

2449.734 -> of when you define a new idea, or you define new syntax,

2453.1 -> or a new semantic in the language,

2456.868 -> it would be best if we could describe that new thing

2459.634 -> in terms of the stuff that's already there.

2461.767 -> So if I describe a new language feature by

2464.868 -> what it would be like if I'd just written it all out,

2467.501 -> we can start to say, aha.

2469.334 -> This fits or this doesn't fit

2470.634 -> with the way we start to use JavaScript today.

2472.667 -> So this is an example of what I'd like to write

2474.801 -> in the new style, and what you would have to write today

2478.367 -> to go make this all work in the old style.

2481.734 -> Okay, that's a lot, and it's a lot of boilerplate

2485.501 -> that we shouldn't have to write.

2488.1 -> The same thing goes for a lot of sort of little

2490.334 -> syntactic niggles.

2491.567 -> So let's say I want a function

2494.167 -> that takes variable arguments.

2495.601 -> Today, in JavaScript, I have to go unpack those arguments

2497.667 -> out of an explicit arguments property

2499.534 -> that's available inside the scope of any--

2501.634 -> inside of any function.

2504.167 -> So if I want a default value,

2506.1 -> I have to go provide it for myself,

2507.601 -> and if I want to go grab variable array arguments,

2510.267 -> I have to go grab the--turn the best of the arguments

2514.467 -> into an array, using array.prototype.slice,

2518.934 -> pass it in to the arguments object as the scope,

2522.1 -> and then say give me everything after the first one, right?

2524.601 -> And then create me the list of parameters.

2526.167 -> That's a lot of boilerplate.

2527.367 -> It's sort of hard to read that function,

2529.834 -> if you don't know this particular sort of pattern,

2534.968 -> and then to understand what it is that it's trying to do.

2536.901 -> It's much better as a language,

2538.367 -> if what we get to is a place where we can say what we mean

2540.868 -> when we're writing our functions.

2542.2 -> I'd like the format to have a default property

2545 -> of a blank string, and I'd like the parameters

2548.167 -> that you don't have allocated to some named argument

2553.033 -> stashed away in an array called params.

2555.567 -> That's a pretty common thing to want to do.

2558.3 -> And so this sort of thing is coming in the next version

2562.501 -> of the language,

2564 -> and last week at JS Conf and again at Node Conf,

2570.601 -> we started talking about some work

2571.968 -> that we're doing on the Chrome Team with the JavaScript

2575.234 -> and JavaScript compiler written in JavaScript

2577.734 -> called Traceur.

2579.334 -> And Traceur's goal

2580.767 -> is to help us design these new language features

2582.968 -> in a way that works really well by trying them out,

2586.567 -> because language evolution isn't a straight line thing.

2589.033 -> You know, we said that all these libraries have different ways

2591.234 -> of doing a lot of the stuff,

2593.3 -> so what we'd like to do is figure out

2594.667 -> what's the best pattern or practice?

2596.1 -> What's the thing that we would really like to blast?

2597.868 -> Or when there is a new semantic

2599.1 -> that we can introduce into the language,

2601.067 -> what is it that we would be trying to say

2602.934 -> in JavaScript directly?

2604.567 -> And so this way, we sort of have a way of, at runtime,

2611.033 -> running this compiler over some piece of JavaScript

2614.3 -> written in the new syntax and have it do something

2616.033 -> in the old syntax.

2617.667 -> So in this case--

2628.4 -> I'm going to go grab something out of the parameters,

2631.1 -> and as you can see, it's recompiling here, as I type.

2648.167 -> And now it has--

2652.834 -> ah, yes, there we are.

2654.601 -> Now it's created all of the stuff

2656.501 -> that I was going to have to write out by hand.

2658.167 -> It's just compiled that down

2659.3 -> from the new syntax to the old syntax,

2661.734 -> and I can run it.

2664.567 -> I should be able to run it.

2667.3 -> man: [indistinct comment]

2673.033 -> Russell: Ah, yes, good call.

2679.334 -> Great, there we go.

2680.601 -> So this is a tool that we're starting to use

2685.367 -> to help inform the language evolution

2687.634 -> in order to help us prototype stuff fast,

2690.2 -> get feedback about how it works,

2691.901 -> and so we can start to understand

2693.701 -> how the new stuff that we're adding into the language

2695.467 -> fits with the old stuff by writing real code in it.

2697.801 -> And as we work in the standards committee

2699.3 -> to help make this stuff reality, this sort of tool,

2702.033 -> I hope, is going to make it possible for us

2704.067 -> to evolve faster and evolve in a straighter line

2706.767 -> with the existing versions of JavaScript,

2709.167 -> because what we don't want is for us

2710.4 -> to add new things like the idea of a class

2713.367 -> and have it be at war with the idea of prototypal inheritance

2715.868 -> or functions as first class objects.

2717.734 -> We want to continue to help you build on these core fundamental,

2721.901 -> really powerful building blocks in the language

2723.534 -> without introducing new sorts of ideas or overhead

2729.033 -> that you have to consider when you're writing your code.

2730.801 -> And so Traceur, again, is an effort to help us

2733.567 -> understand and experiment with the language,

2735.701 -> and it's available as an open source project on Google Code.

2739 -> You can use it today, both on the server and on the client,

2741.834 -> and you can start to play with it.

2743.734 -> You can start to write real code in it.

2745.3 -> There's a read, evaluate, and print loop

2748.167 -> that you can just go to and start typing code into.

2756.033 -> So I won't belabor that anymore,

2758.133 -> but what we're really hoping for is that you can start to use

2764.067 -> a lot of the new features that we've started to play with.

2766.767 -> We have a list of features that we've implemented in Traceur,

2769.033 -> and that's expanding every day.

2770.367 -> But things like modules, classes, and traits,

2772.868 -> asynchronous programming--

2774.2 -> Asynchronous programming is something we have to do

2776 -> all the time, and we wind up doing it with a callback system.

2777.968 -> It'd be great if there was support for that

2779.434 -> in a language that we didn't have to continue to write

2781.133 -> the same boilerplate over and over and over again.

2783.1 -> Destructuring assignment, like we just saw,

2784.968 -> and the ability to use the prototypal sort of style

2787.834 -> of extension, but have it happen in a way

2789.868 -> that doesn't conflict with everybody else's objects

2791.601 -> in the system.

2792.801 -> Those are the sorts of high priority work items

2794.667 -> that we're starting to use Traceur to evaluate designs for,

2798.734 -> and we'd love your help.

2800.167 -> We'd love for you to start using it, testing it out,

2802.601 -> working with the system, and helping us write code

2804.968 -> in the new style, so we can understand

2806.234 -> whether or not it's actually good.

2808.667 -> So Traceur is one idea to help us get there.

2812.133 -> We need implementations early to inform the design process

2814.968 -> for the future of the language, so that the things that you do

2817.267 -> in the language now carry out into the future

2820.334 -> as core idioms and core concepts that you can rely on there, too.

2825.1 -> But we need those things to eventually trickle down

2827.3 -> into real, live implementations, V8, other JavaScript engines,

2830.934 -> and we want to make sure that these things

2832.367 -> are available to you quickly in the fast-moving constituencies.

2835.033 -> So if you can start to use this stuff in the Chrome Web Store--

2838.667 -> because almost everyone in the Chrome Web Store gets--

2841.534 -> or who you can target through the Chrome Web Store

2843.868 -> gets the latest version of Chrome within a week--

2845.734 -> that's really good.

2846.968 -> We can start to get fast feedback in the language

2848.868 -> and in the design of the next version of JavaScript

2851.501 -> based on your feedback about what's working

2853.467 -> and what's not in ways that we couldn't before.

2856.267 -> The lead time on a new version of the language has been years--

2859.467 -> in some cases, closer to a decade.

2862.267 -> And so you can follow along the ECMAScript wiki.

2867.267 -> I realize this is-- the link

2868.567 -> is a little bit long, but there's a list

2870.033 -> of accepted proposals for the next version of the language.

2871.868 -> That's going to be somewhat formalized

2873.267 -> in the next couple of months.

2874.567 -> And as that list is locked down,

2876.3 -> we're going to continue to iterate on those proposals.

2878.3 -> They're going to get new syntax.

2879.601 -> Things are going to change there.

2881.1 -> But the list of things that are in the proposal stage

2882.968 -> for Harmony are the set of things that we,

2884.334 -> as a committee, have agreed to go work on

2886.267 -> and standardize together.

2887.667 -> And so Traceur is going to continue

2888.868 -> to follow that evolution

2890.2 -> and allow us to start to work in ways

2892.634 -> that give us quick feedback about whether or not

2895.367 -> we're doing the right things for you

2897 -> as you're writing large pieces of JavaScript.

2900.734 -> Okay, questions?

2909.734 -> man: Hi. So the common JS modules specification

2913.501 -> has like a really simple require and exports

2917.434 -> that really doesn't-- that--it's kind of--

2919.767 -> it doesn't factor in, you know,

2921.367 -> how things get loaded or whatever.

2922.734 -> It's really just a binding mechanism between

2924.801 -> disparate name space.

2926.334 -> That seems ultimately simple to me,

2927.934 -> but it doesn't seem like Harmony is going in that direction.

2930.968 -> Russell: So the simple modules proposal

2934.868 -> gives us a way to have a first pass.

2937.734 -> So...sorry, I should run this backwards.

2941.968 -> The common JS module system sort of is implicitly server JS.

2947.534 -> You kind of assume that the thing that you're getting

2949.534 -> in the next statement is cheap to fetch.

2951.2 -> And so what we need for the client

2952.868 -> is an ability to make the require and provide statements

2957.534 -> look apparently synchronous but have them operate

2959.734 -> asynchronously on the network, which means that we want to get

2962 -> the transitive closure of all of the dependencies

2964.667 -> that your module needs.

2966 -> man: Then you're kind of mixing like load,

2967.601 -> the loading and--

2968.601 -> Russell: They are mixed.

2969.601 -> There's no way to unmix them.

2970.834 -> Because of the way that JavaScript evaluates

2972.767 -> top to bottom, we either have to--

2974.367 -> and because it runs on the UI thread,

2975.834 -> we either have to block the entire client

2979.267 -> while we go fetch resources, which is what happens

2981.367 -> with the document.write, that sort of thing--

2983.234 -> man: Yeah, I see what you're saying.

2984.234 -> Russell: Or we have to find a way

2985.567 -> to accommodate asynchronous loading in the syntax,

2988.467 -> and that's what the simple module proposal does.

2989.834 -> man: I see what you're saying.

2990.968 -> Russell: Which is fundamentally different,

2992.234 -> because we can use syntax to do that in a way

2993.968 -> that common JS can't.

2995.4 -> man: Yeah, I use a system where I kind of--you use common JS

2997.767 -> on the client, but I don't-- I allow for, like,

3002.4 -> forward references. Russell: Right.

3003.634 -> man: So like, those things, they get resolved

3005.567 -> at a later time,

3006.934 -> so you can't kind of use them completely until later.

3010.067 -> Russell: Yeah, I'm really hopeful that we can get

3011.534 -> the semantic that Dave Herman has put forward,

3013.901 -> because it really does give us the power to not force you

3016.3 -> to think about when your code is going to run.

3017.734 -> If you say require in one line, you can use it in the next one,

3020.033 -> and I think that's a key usability feature

3023.267 -> of a language improvement in this area.

3027.834 -> man: Question. On the last slide,

3029.367 -> one of the things you mentioned was asynchronous programming

3031.033 -> with JavaScript.

3032.467 -> And, you know, like Node JS is one of the new frameworks.

3036.701 -> I'm wondering if you can talk a little bit about

3038.133 -> some best practices for how to handle error conditions

3041.3 -> or exceptions when you're doing an asynchronous call

3045.334 -> that may not be in the same call stack

3047.133 -> as when you actually executed the call.

3049.901 -> Russell: So this is a hot topic.

3052.434 -> The asynchronous pattern that seems to have won

3056.868 -> the most mindshare is something like deferreds or promises.

3059.701 -> Again, the common JS guys have done great work there.

3062.367 -> And so those systems tend to have some error

3066.234 -> handling callback that you can register,

3070.3 -> so that if an error does occur, you can be notified of it.

3073.601 -> I actually was talking with the Node JS guys just last week

3076.634 -> in Portland about exactly how they want to do this,

3079 -> because I'm hopeful that what we can do

3081.167 -> is build on top of built-in language deferred

3085.033 -> or promise API, the ability to use the weight

3088 -> or async keywords to go help mark particular methods

3091.167 -> of returning these deferred objects,

3092.667 -> but error handling does turn into a primary question then.

3096.601 -> So what they came to,

3099.467 -> and I think it's a pretty good answer,

3101 -> is that you have a single callback, right?

3103.267 -> And that needs to be also informed of errors.

3106.067 -> But you can have an optional second callback,

3108.601 -> which will be told about error conditions

3111.2 -> if you choose to handle them independently.

3113.2 -> And I think, you know, the idea

3115.467 -> that you're not going to have to deal with errors

3116.534 -> in the primary callback

3118.4 -> is a little bit farfetched,

3119.767 -> and so I think that's maybe a good trade-off.

3121.601 -> But it is an open topic.

3124.934 -> We probably need language level support

3127.133 -> for sort of moving stack traces.

3130.868 -> Like, if I throw in one catch here and then re-throw

3134.434 -> the exception someplace else, we need some VM

3136.4 -> or language level support to help us make that reporting

3139.734 -> cleaner and nicer.

3141.501 -> And I think that's another important area

3143.834 -> that we might be able to help tie these things back together,

3147.434 -> once we go async. man: Okay, great.

3150.4 -> man: Hi, I just wanted to know if there was any interest

3153.267 -> or effort within Google to do some more of the more

3159.234 -> server side JavaScript, stuff like Node JS,

3161.234 -> and maybe any possibility of ever having that available

3165.367 -> like on App Engine.

3166.901 -> Russell: I can't speak to future product plans,

3168.701 -> but I can say that the VA team is working closely

3170.801 -> with the Node team to continue to make Node faster.

3174.534 -> We care a lot about their use cases,

3176.167 -> and we want to make sure that we're supporting them.

3180.801 -> man: So looking at the Traceur function and the no sugar,

3184.634 -> de-sugaring, in Lisp, this was done

3187.467 -> because they had a powerful macro facility,

3190.033 -> so that the developer could actually introduce new syntax

3192.934 -> into their programs and define the behaviors in Lisp.

3196.901 -> Is there any thought of doing something like that

3198.434 -> in JavaScript?

3199.734 -> Russell: We have a hard time with that in JavaScript,

3201.434 -> because we have both statements and expressions,

3203.868 -> and we have, you know,

3206.4 -> a lot of complex grammar that's not movable.

3210.033 -> And as a result, any macro facility

3212.334 -> is going to quickly become undecidable.

3214.3 -> And so I think we're in a place where macros,

3217.801 -> the way I think you want them, aren't possible

3220.667 -> in JavaScript.

3221.968 -> New syntax, specifically,

3223.634 -> is going to have to continue to happen through the committee.

3228.534 -> So I think there are places

3230 -> where we can carve out some stuff.

3232.834 -> There's been some good work in string formatting,

3235.1 -> for instance, to make it possible to plug in--

3237.334 -> through protocols--some new behavior into existing syntax,

3241 -> and I think that's maybe the promising way forward.

3243.634 -> man: Yeah.

3246.534 -> man: So did you know that you can build Firefox

3249.801 -> with support for Python as a scripting language?

3253.234 -> Russell: I've heard tell of this,

3254.667 -> but it's been that way for many years, as I recall.

3256.734 -> man: Yes, debug build with Firefox comes with it.

3259.2 -> More seriously, what do you think of GWT

3261.767 -> or more usefully Pyjamas as actual development platforms

3267.734 -> instead of writing direct JavaScript,

3270.767 -> and using the richer type system of Python or Java

3276.033 -> instead of the bare bones one in JavaScript?

3278.701 -> Russell: Type systems are really great.

3280.067 -> I think that it's a key missing feature from JavaScript

3284.033 -> specifically because what you wind up writing, again,

3285.934 -> is a lot of boilerplate to help you test

3287.501 -> whether or not you were actually tall enough to ride the ride.

3290.467 -> You actually have to sort of go cart around

3292.1 -> a lot of this testing magic.

3293.467 -> I'm not hopeful for type systems.

3295 -> This is my personal opinion.

3296.367 -> I'm not hopeful for type systems as a be all and end all

3299.234 -> sort of verification system for your program.

3302.334 -> The web is too dynamic.

3303.834 -> Client-side programs are too dynamic for that.

3305.734 -> We're dealing with user behavior a lot.

3307.434 -> Instead, what I'd like for us to get to is a place

3310.234 -> where the syntactic warts of JavaScript sort of get

3314.334 -> eased over one way or the other.

3315.567 -> Things like CoffeeScript

3316.701 -> are pointing in a good direction here,

3318.133 -> where you can sort of come back up with some new syntax,

3322.734 -> and hopefully that'll eventually work its way

3324.467 -> into the language.

3325.667 -> But things like the module that are--

3327.167 -> they're going to have an analogous API, again,

3329.467 -> building a protocol that you can plug into with your own code,

3332.634 -> and that API will allow you to do things like run

3335.067 -> the CoffeeScript compiler or the Pyjamas compiler

3337.934 -> across loaded modules before they're run,

3340.267 -> which means that you can sort of have runtime support

3342.567 -> for those built-in.

3345.033 -> I think the--you asked a question

3346.667 -> of what do I think about

3347.834 -> those tools as a way to do production work.

3351.2 -> If your language veers far enough from the core semantics

3354.334 -> of JavaScript, you wind up not just with the ability

3357.334 -> to do all sorts of tooling and stuff that comes along

3359.901 -> with your source language, but you also wind up with

3362.667 -> the need for the runtime to do dead code edition.

3366.067 -> You need to go and sort of not just do a one-for-one

3371.234 -> translation down to the analogous statements

3373.167 -> in the other language, but you have to make sure

3374.434 -> that the semantics are right.

3376.234 -> You have to make sure that you have code in there

3377.667 -> to support any differences, any impotence mismatches

3380.367 -> between the two languages.

3381.434 -> And so I'm much more hopeful

3383.234 -> about things like CoffeeScript and the Traceur editions

3387.501 -> because they don't add a lot of extra stuff,

3390.033 -> because the languages aren't that far away

3391.467 -> in terms of core semantic.

3393.033 -> man: All right, thank you.

3395.534 -> man: Hi, one kind of application domain that could benefit

3398.968 -> from scripting that's not really--

3401.634 -> doesn't have a solution today is a native Android app.

3405.067 -> So I wonder if there are any--

3406.334 -> we've dabbled with, you know, plug-in Rhino

3407.968 -> and things like that.

3409.334 -> I wonder if there's any activity in that area right now.

3412.434 -> Russell: I think you'd have to ask the Android team.

3414.1 -> I'm sorry, I'm not up-to-date on what they're doing there.

3415.968 -> man: Okay. Russell: Thanks.

3418.567 -> man: I had another question.

3419.834 -> So in my Python programs, I like to use sometimes

3424.4 -> multiple inheritance, and I have complex--

3427.167 -> Russell: C3MRO, right, yeah.

3428.968 -> man: Dependency graphs and so on, yeah.

3430.567 -> So and they have a method resolution order in Python

3434.534 -> that allows you to call the super classes methods,

3437.434 -> you know, exactly once in the right order, and--

3439.601 -> or at least a well-defined order.

3442.1 -> Is anything going on in Harmony for allowing for something

3446.334 -> like an MRO type call graph resolution?

3450.3 -> Russell: I don't think we're going to break the idea

3453 -> of a single prototype. man: Right.

3455.234 -> Russell: So the analogous thing here would be

3457.033 -> multi prototype languages.

3459.501 -> I'm hopeful that what we'll get done

3460.801 -> is something like Tom Van Cutsem's

3462.734 -> Traits semantic,

3464.634 -> where we can add a syntax for defining

3466.767 -> a set of things that you would sort of--

3469.1 -> like we did with mix-ins, add to the class,

3471.1 -> and then do conflict resolution with syntax.

3474.968 -> Because what you're trying to say in a lot of these cases

3476.567 -> isn't, I'd like for you to sort of decide for me

3478.901 -> which of these things I am at runtime.

3480.567 -> It's not really a-- an "is a" relationship.

3482.3 -> It's sort of a "has a" relationship,

3483.434 -> what you're saying.

3484.467 -> I'd like this new behavior

3485.734 -> to also be available to my object.

3487.834 -> And if you can factor those things out,

3489.2 -> it can help with composability and then eventually

3491.267 -> with type testing.

3492.667 -> And I think Traits are where, at least I'm hopeful,

3495.901 -> that we'll go to make a lot of that easier.

3498.2 -> man: Yeah, I use a wrapper where like I kind of

3500.701 -> build a copy of a well-defined prototype chain,

3503.834 -> specifically for this particular set of mix-ins,

3506.534 -> and so like you can kind of emulate,

3508.567 -> you know, by specifically listing

3509.934 -> the order in which you want things to be resolved

3513.601 -> and kind of get the behavior for that in JavaScript.

3519.234 -> man: Mainly curious, do you know whether Traceur shares

3522.067 -> common lineage with the cross interpreter

3524.734 -> in Google Widget Toolkit?

3527.234 -> Russell: The Traceur code base is brand-new.

3528.834 -> It's a, you know,

3531 -> a new client-side compiler that we wrote,

3535.968 -> hand-built parser, that sort of thing.

3539.868 -> man: Thank you. Russell: Yeah.

3543.267 -> All right, one more. All right.

3546.801 -> man: So I'm a C# developer,

3548.901 -> and I've stayed away from JavaScript for a very long time,

3553.2 -> mostly because I didn't-- I knew the what,

3555.834 -> but I didn't know the why, and that's been really good

3558.901 -> in today's session.

3561 -> I'd like to continue exploring.

3564.634 -> Can you recommend any reading-- specific reading material?

3567.934 -> Because, of course, I could always do a Google search.

3569.868 -> Russell: Yeah.

3571.234 -> man: But that would continue along the path of not just

3573.501 -> the what but the why also.

3575.534 -> Russell: The latest version

3576.868 -> of "JavaScript, the Definitive Guide" is pretty good.

3579.067 -> I recommend "Eloquent JavaScript."

3582.067 -> It does a great job of sort of introducing these core concepts

3584.634 -> and getting you through not just sort of what you can do.

3588.567 -> I didn't talk a lot about how DOM interacts

3590.801 -> with all of these things.

3593.601 -> My recommendation is that you find someplace

3597.1 -> to start playing with a language that's not a web browser.

3599.868 -> I mean, web browsers are really handy.

3601.234 -> You can start to sort of like make this all happen.

3603.968 -> But if you just sort of play with the command line

3605.767 -> in the browser or start to work with a local copy of V8

3609.4 -> or Node JS, you can really get a feel

3611.334 -> for what's in the language and what's not in the browser.

3613.501 -> JavaScript takes--in almost every environment,

3615.4 -> it takes a lot of its identity from the standard library

3618.234 -> that sort of it's been wedded to.

3620.567 -> And in most cases,

3621.901 -> because it has a very small standard library,

3622.934 -> all of that is in the environment.

3624.4 -> And so the more you can sort of remove those potential hurdles

3628.3 -> or sort of impotence mismatches

3629.934 -> with what's just in the language,

3631.567 -> I think the faster it'll help you learn it.

3634.701 -> Yeah.

3635.934 -> man: Actually, in a similar situation

3638.2 -> as the previous question, which is I stayed away

3640.601 -> from JavaScript for a number of reasons.

3643.467 -> Probably one of the biggest ones

3644.968 -> was the lack of debug support. Russell: Mm-hmm.

3647.367 -> man: And the fact that you have unexpected surprises,

3652.033 -> like being able to overload the array constructor,

3656.267 -> that lend itself to, you know, security holes,

3659.968 -> whereas someone coming from another language

3661.801 -> isn't expecting that, and they don't even consider

3664 -> that as a possibility when you're looking at code.

3666.434 -> So specifically, is there anything that's talked about

3669.934 -> being added, where-- when you talk about modules,

3673.2 -> that the module can set up certainly like preconditions?

3676 -> I'm expecting these sets of things to be true,

3679.634 -> like the array constructor cannot be overloaded,

3682.234 -> or anything else where you can say, flag,

3686.934 -> this is going to be a problem or not going to run right.

3689.701 -> Russell: So one of the big things that's happening

3691.1 -> with the module syntax is that we're removing

3693.834 -> the ability to share globals, so you won't have

3696.3 -> a single shared global, which is going to be big,

3699.3 -> to prevent people from sort of blowing your own legs off.

3701.767 -> The other thing is that ECMAScript 5,

3704.133 -> the version that was just recently ratified,

3707.968 -> implements what we call a strict mode.

3710.2 -> And strict mode turns off some of the worst foot guns.

3712.467 -> It helps keep you out of trouble by giving you more and more

3719.234 -> pre-checking for things like uninitialized variables,

3722.367 -> that sort of thing, where it keeps you from

3724.634 -> sort of tripping over yourself in some pretty common areas.

3727.968 -> It's not perfect, but it's certainly a start.

3730.2 -> So use strict inside of all of your functions,

3731.801 -> and you should be good to go.

3733.2 -> man: And what about the idea of like official debug support?

3737.3 -> Russell: So that's an engine-by-engine thing.

3740.667 -> The topic of common stack traces has been raised

3746.033 -> a bunch of times, and it's going to be very difficult,

3748 -> because that constrains our ability to optimize.

3750.067 -> So things like alighting away dead code,

3753.4 -> those are the sorts of things that are going to be hard to do

3755.567 -> if we have to agree on a stack trace format.

3757.267 -> So what we do have is really good support,

3759.367 -> say, in the Chrome web inspector for setting breakpoints,

3763.3 -> future breakpoints, getting call stacks,

3766 -> and soon the ability to sort of wire up line numbers

3770.033 -> to source code.

3771.167 -> So yeah, debugability is a hot topic.

3773.734 -> It tends to happen through the browser

3775.701 -> and not through the language runtime.

3777.634 -> man: [indistinct]

3781.467 -> Russell: So the question was will a closure compiler

3783.2 -> help with the debugability. If the closure compiler has--

3785.601 -> man: [indistinct]

3788.901 -> Russell: Oh, will the closure compiler help beginners?

3791.434 -> No. It's designed to help folks who know

3795.767 -> that they have a problem avoid having problems.

3797.767 -> Okay, cool.

3799.133 -> Thanks again for coming, and I'm looking forward to it.

Source: https://www.youtube.com/watch?v=seX7jYI96GE