Placeholder Image

字幕表 動画を再生する

  • Russell: Good afternoon.

  • I'm Alex Russell.

  • I'm a software engineer on the Chrome Team.

  • Thanks for tearing yourself away from lunch

  • to come hear about JavaScript.

  • So like I said, I'm an engineer on the Chrome Team,

  • and before I joined Google,

  • I spent a lot of my life working in JavaScript.

  • I joined the Chrome Team from a web development background,

  • specifically working on open source JavaScript tool kits

  • and before that,

  • working web application development and security.

  • And before my recent detour into C++,

  • I spent most of my day trying to figure out

  • how to make JavaScript do interesting things.

  • My personal history with JavaScript started in 1997,

  • I think when a lot of us started to be cognizant of the web.

  • And at the time, JavaScript was this thing

  • that was starting to become powerful

  • and somewhat standardized

  • and somewhat widely available on the back of the browser wars.

  • So I want to talk a lot about

  • how we got to where we are today with JavaScript,

  • why it's so important, why that history,

  • that long history continues

  • to figure into the sorts of things we try to do

  • with JavaScript on a day-to-day basis.

  • And I want to take you through what's really

  • inside of JavaScript.

  • What is it about JavaScript that it is,

  • that makes it so different to the languages

  • that you might be using in your day-to-day work

  • that aren't JavaScript, because there's a lot that is.

  • Exactly where are we right now?

  • Because I think this is also sort of

  • an ambiguous question, right? If you're a browser bender,

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

  • If you're a web developer,

  • you can look in your deployed base

  • and understand who's got what,

  • but that doesn't necessarily tell you anything

  • about the future.

  • And I want to spend a lot of time today talking about

  • how it is that we are going to get a different future

  • for JavaScript,

  • because JavaScript, like the browsers,

  • is starting to move again,

  • and I want to tear back the veil

  • that covers each of these topics

  • and help you understand exactly what's going on

  • and how these parts relate to each other, because they do.

  • The history informs the future,

  • and the current state informs what's going to happen next.

  • So JavaScript is a functional language.

  • So how many of you write in other functional languages

  • or are familiar with functional languages?

  • Awesome.

  • The front of this talk is going to be something

  • that maybe just warms your heart and may not be new information.

  • So JavaScript is a functional language.

  • In the sort of the history of functional languages,

  • it supports closures.

  • Much like Scheme,

  • it's got this nice first class function system,

  • and in 1995, Brenda and I hacked it up as a little prototype

  • which made its way into Netscape 2,

  • and Netscape 2 was the first browser

  • to really have any serious scripting supported.

  • It had DOM level 0, and soon afterwards,

  • JavaScript sort of, you know,

  • once it escaped into the browser,

  • started the standards process at ECMA,

  • not inside the W3C,

  • because the W3C wasn't the place for languages.

  • And in 1997, we got the first version of JavaScript

  • as a standard.

  • In 1996, Microsoft shipped IE 3.0,

  • and that was the first version of JScript.

  • So we now had two competing,

  • mostly compatible implementations

  • of a scripting language for the web.

  • Nobody knew how big the web was going to be,

  • although, at the time,

  • it looked like things were trending up.

  • Well, we know how that story ends.

  • Today, you can't ship a credible platform

  • that doesn't have the web.

  • In 1999, ECMAScript version 3

  • was finalized at TC39, which is the technical committee

  • that is the standards body for JavaScript.

  • And from its humble roots

  • as Mocha/LiveScript/JavaScript in Netscape 2,

  • JavaScript 3, ECMAScript 262-3, the version or the standard

  • that was released in 1999 has powered us pretty much to today.

  • It has been the thing that for more than a decade

  • has been what we think of as JavaScript.

  • And JavaScript, on the back of that standard,

  • has gone pretty much everywhere.

  • JScript, the component that runs JavaScript inside of IE,

  • has been built in to the OS for Windows since Windows 98.

  • You can't get a copy of Windows,

  • you can't buy a copy of Windows today

  • that does not include JavaScript in the OS,

  • and every browser on the planet now includes

  • at least one implementation of JavaScript,

  • and these things are moving really, really fast.

  • I work on the Chrome Team; therefore, I'm partial to V8.

  • It goes nice and quickly,

  • but these things are all compatible

  • to a very high degree.

  • All of these implementations are separate implementations,

  • and they're competing on things that aren't,

  • "Oh, here's a new language feature."

  • We're collaborating on language features

  • in the standards committee,

  • but we're competing on performance,

  • which is a really great place to be for a language,

  • because it takes a lot of investment

  • to make a language a real success.

  • It takes a lot of deployment,

  • a lot of competition, and a lot of investment

  • to sort of get the really smart guys

  • that it takes to go make a VM go like hell.

  • And so JavaScript has been the beneficiary

  • of this sort of ecosystem of investment in a way

  • that only a couple of languages before it ever have.

  • And as a result, today's JavaScript runtimes

  • and today's JavaScript performance are vastly different

  • than they have been in the past, even the recent past.

  • And so every device that you get today,

  • including the tablets that were handed out to you yesterday

  • and the Chrome books that you'll be receiving as attendees

  • on June 15th,

  • these all have JavaScript as a core part of their runtimes

  • because the web is the platform.

  • The web is the way that you're going to build

  • a lot of the applications

  • that your user is going to care about,

  • and it's the way to build portably today.

  • So JavaScript is everywhere, and it's terribly misunderstood.

  • And I think what I want to do first here

  • is to talk you through the parts

  • that most people don't really have a sense of,

  • when they talk about,

  • like, what is it that makes JavaScript different?

  • Because we hear it's a dynamic language.

  • We hear it's a functional language.

  • But it looks a lot like C. It looks a lot like Java.

  • It looks a lot like C++.

  • And some folks have been doing a great job

  • in the last couple of years at sort of helping to tear back

  • the blinders that are on us,

  • as folks who come from a C or C++ background,

  • and help lay out what it is.

  • But I want to go through it very briefly,

  • because I think it's important to understand

  • what's actually in there,

  • because when we understand what's actually in there,

  • we'll understand how the language can evolve,

  • because you don't want necessarily separate--

  • competing ideas to be existing inside the same language.

  • You want a language to sort of have a theory of itself.

  • You want it to be coherent in ways that make it,

  • so that when you understand one part of the language,

  • you can understand the next part of it.

  • And my interest in this is coming from a background

  • as a web developer,

  • I serve as one of Google's representatives to TC39,

  • the standards committee for JavaScript.

  • And so I have a particular and keen interest

  • in making sure that we evolve the language in ways

  • that are reasonable and solve real world problems

  • that we've all got.

  • So JavaScript only has a couple of key languages.

  • I said earlier that JavaScript is a little functional language,

  • and JavaScript started out as a very small language entity.

  • There aren't a lot of core concepts.

  • There's no type system, per se.

  • There are types.

  • You can have a number, or an object, or an array,

  • but there's no type testing.

  • There's no way to define your own types, necessarily,

  • and have them participate at, like, function call time

  • and have the system throw an exception for you,

  • unless you do the testing yourself.

  • And JavaScript reads top to bottom.

  • JavaScript has run-to-completion semantics.

  • That means that if you start a body of code,

  • there's no multithreading in the language.

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

  • Anything that does that in a JavaScript environment

  • is doing it as a built-on.

  • So browsers with their set timeout and their set interval.

  • That's all happening outside of the core language semantics.

  • JavaScript reads top to bottom,

  • and the interpreter and runtimes read it exactly

  • and run it exactly that way.

  • If you see a block of JavaScript code,

  • it goes from top to bottom, and that'll become important,

  • as we see in just a minute.

  • Almost everything in JavaScript is mutable.

  • That means that you can change nearly everything,

  • and we'll talk about the several exemptions to this rule,

  • but those exemptions are very small,

  • and they're very narrow, but they wind up being powerful.

  • So that means that if you get an object back from

  • some function call,

  • you can probably change it in JavaScript.

  • Closure is the way we do private state, though,

  • so if I get an object,

  • and everything is mutable,

  • it means, ah, I might be able to surprise somebody else.

  • I might be able to go change some state out

  • from underneath them.

  • The thing that returned me the object might expect it

  • back in some reasonably okay state.

  • Well, the way we do data hiding in JavaScript

  • isn't through the private key order,

  • through some method that gives you some sort of a private field

  • that you can only see.

  • Instead, we invert the relationship

  • between classes and functions,

  • and we treat functions as behavior that can carry data,

  • versus classes,

  • which are data that can carry behavior.

  • And so the last key concept is, instead of having a class,

  • as you understand it in other languages,

  • we have prototypes,

  • which is to say we don't have this strong "is a" relationship

  • through a hierarchy of classes.

  • Instead, we say, when I don't find it here,

  • please look over there.

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

  • up to a root object that everybody shares.

  • So we'll talk a lot about how exactly all this works,

  • how it fits together,

  • and hopefully you'll understand at the end

  • how it's going to inform where we can go from here.

  • I said earlier that JavaScript runs top to bottom.

  • That means if I see a piece of code in JavaScript,

  • one line before the next,

  • before the next--because there isn't necessarily

  • a compile cycle.

  • Most JavaScript runtimes traditionally were interpreters.

  • That means that the easiest way

  • to think about your JavaScript program

  • is as something that is going to happen in a live environment.

  • So if you had a command line,

  • and you started typing in commands,

  • JavaScript runs almost exactly the same way.

  • Top to bottom, line for line,

  • it gets evaluated in the order that it is written out

  • in the program, more or less.

  • And so statement to statement,

  • your programs--they can change in ways that are surprising

  • in other languages.

  • Where you might otherwise have compile time exceptions,

  • JavaScript just sort of merrily goes on

  • and runs the next line.

  • So whenever we read some JavaScript code,