I'm the father of AngularJS.

BRAD GREEN: And I'm Brad Green, and I will play

Angular's manager today.

It's what I do.

All right, so we wanted to take some time in front of you

folks-- thanks for coming, by the way-- talking about what

it is that drove us to build Angular.

Because we think, when people come and look at the Angular

framework, a lot of times they see the features of Angular,

and maybe we're not very clear about what we meant.

When they come to see the features, they see what we

call the three D's--

directives, dependency injection, and data-binding.

But we're passionate about some very different things.

We just happened to arrive at these features along the way.

So Misko, why don't you talk about what do you care the

most about web development?

MISKO HEVERY: So web development, if you think

about it, is all about getting data to the browser, and then

back to the database.

And so one of the things that you end up doing is a whole

lot of boilerplate marshaling of the data back and forth.

And after you build a couple of web applications, you're

just getting tired of writing the same thing

over and over again.

And it's kind of getting in the way of just building the

actual stuff.

And so, the boilerplate is one of the things that we really

wanted to eliminate as much as possible

inside of our codebase.

BRAD GREEN: Right.

So we thought that if we can distill our apps-- if we could

boil them down, maybe--

to their essence, about just what adds value to the app,

then it'd be very much--

it's easier to build these applications, but also easier

to understand.

We spend a lot more time reading code than writing it.

So we thought that would be cool.

MISKO HEVERY: So the next thing is, every single

application I've ever been on, it was structured

in some other way.

And having a common way of structuring the application

means the developer can easily bring--

come up to speed on your codebase, and we can easily

move between projects.

And so giving structure to the applications is another

important thing.

BRAD GREEN: What is that shape, Misko?

MISKO HEVERY: That's a scaffolding, sir.

BRAD GREEN: Do you know how to draw scaffolding?

MISKO HEVERY: No.

I do not get paid to draw.

I get paid to write code.

BRAD GREEN: OK, good thing.

Good thing.

MISKO HEVERY: And then lastly, I'm a big fan of testability,

and so we put a lot of testing effort into our framework.

But it's not enough to just build a framework

which itself is tested.

It's all about making sure that the people--

developers writing code, using the framework will have easy

time testing.

And so one of things we wanted to make sure is the way the

framework is structured naturally leads you down the

stability path

BRAD GREEN: That's right.

And we believe that if you're shipping software, you better

be shipping tested software.

So we really wanted to make that easy.

So let's go back to a few years to 2009, where I think I

said, Misko, you should go learn JavaScript.

This seems like the new thing.

And what did you do?

What was your first inclination as a newbie in the

world of JavaScript?

What did you do?

MISKO HEVERY: Well, write a framework.

What else would you do?

BRAD GREEN: That's right, every newbie

should write a framework.

It's a good policy.

MISKO HEVERY: So the idea behind Angular-- the original

Angular was actually a little different, which was that

there's a lot of web designers out there, people who are not

really programmers, developers per se, but they know how to

put HTML together because it's so declarative, and

it's easy to do.

And so, could we enable the web designers to be able to

build a very trivial, simple application just by a dropping

little bit of extra markup logic into the HTML?

So you don't even have to manage your backend.

You have some database in the cloud, and you include the

script tag, put a little bit of extra tags, and all of a

sudden, your form becomes persistable form and can send

email, and things of that sort.

BRAD GREEN: That's right.

You know, this eye-stabbingly yellow logo, right?

MISKO HEVERY: You have something against yellow?

BRAD GREEN: I got better.

MISKO HEVERY: All right.

BRAD GREEN: All right, so fast forward just a little bit to--

we were on a project together.

And I remember Misko-- this was a project

called Google Feedback.

And Misko, you and the other developers on the project were

kind of unhappy with our development pace?

MISKO HEVERY: Yes.

The velocity was not so great.

We spent about six months, three of us working on this

particular project.

17,000 lines of code later, we were really not making the

progress we wanted to make.

And so we're frustrated.

And so in my frustration, I went to Brad, and I said, you

know, Brad, I'm working on this thing in my free time,

kind of an open source project.

And I bet you I could rewrite the whole thing in two weeks.

BRAD GREEN: And I said, go for it, because two weeks--

whatever.

But I don't think you quite made it in two weeks.

MISKO HEVERY: No, I didn't make it in two weeks.

It took me three weeks.

And 1,500 lines of code later, we actually have rewritten the

whole application.

BRAD GREEN: I was impressed.

And this was kind of the start where I though, well, Angular

seems like it could be a thing unto itself, not just a part

of Google Feedback as the way it was.

And this is where we decided we would spin it off into its

own entity.

MISKO HEVERY: So what exactly is it to build a single-page

application?

Well, you have a database, and you the browser, and the stuff

in the middle is really what we're talking about, right?

And so to have a single-page application is really all

about modifying the DOM-- you know, the divs, the spans, the

uls, the lis, the tables, and so forth.

You need to transfer it from one state to another state,

because that essentially is going to drive

the rendering engine.

But the thing that's different between [? round-tree ?]

applications and single-page applications that you have to

deal a lot of it about the internal thing called RAM.

BRAD GREEN: Memory.

MISKO HEVERY: Memory.

Memory, I see.

BRAD GREEN: We call it memory these days.

MISKO HEVERY: So the heap of the program, right?

So instead of getting the data in line with your HTML to get

data separately, you load it into the memory.

And now the problem becomes once we get it to memory, how

do we get it to the DOM?

And then back when the user interacts into the memory, and

into the database?

And so our passion really became how do we simplify this

flow of data to the DOM, and back to the database.

And this is essentially what became Angular.

BRAD GREEN: Right.

And we got a logo.

But let's see how this works.

And we're going to go to an example of the basics of

moving back and forth.

And this is one of those three D's--

and we'll actually describe them-- not our goals.

But it's important.

So data-binding, the way this works.

We've got a--

just in a template, we're actually able to express kind

of an interesting case.

Well, let's actually see how this works before we

dive into the code.

So Misko's a text box here, and you'll notice how he

types, the words that he types appears below, and the word

"hi" appears when there's something in the box.

So if he deletes all the text in the box, the word "hi" goes

away, and we don't see anything.

So let's go back and take a look at how this works.

So at the top, you'll notice in the HTML tag, we have an

extra attribute that is not actually

part of the HTML spec.

And there-- all these things in green are--

these are extensions we've added.

And we call them directives.

But they allow us to assemble the application

in interesting ways.

And here on the input field, what we've said is that the

model for our data-- the place in memory where this lives--

we're going to name it with an object called "user," and we

have a property called "name." And that we want this thing

synced up, so that whenever somebody types that in memory,

it should update this user.name, and we

can use that elsewhere.

So right below it in the paragraph tag, we want to

place that text.

So what we do in double curlies-- we call this

interpolation--

we're able to place that text right in there just by putting

those double curlies in.

This is a familiar syntax that's used in other

templatinig languages.

But we're also able to use it not only to modify what data

is there, but to control whether it's shown or hidden.

So in the p tag, we have ng-show equals username.

Well, what this says is that showing and hiding should be

controlled by presence of text in there.

If there's no text, hide it.

If there's text, show it.

But we had an interesting eureka moment in here, which

is that our templating system was actually HTML, which means

you can use all your existing HTML editors, such as

Dreamweaver, or your HTML editor inside of your IDE.

And this is in stark contrast to most other templating

systems that happen to be templating languages of their

own, and just happen to produce HTML on the end.

This is actually HTML all the way through.

And that makes it easy for people to pick up and learn,

such as for web developers-- or, for web designers who are

already familiar with the HTML paradigm.

BRAD GREEN: That's right, but data-binding isn't the whole

story, right?

So we also want to put in but some other bits when we create

an application.

MISKO HEVERY: So at the beginning, I mentioned the

idea was, could I build a very simple web application without

having actually any kind of logic inside--

without having to write any logic, any program just by

using data-binding?

And if you wanted to build a real application, sooner or

later you come to the situation where, well, you

have to put the logic in there.

And so it's not sufficient to just have a good data-binding

story, but also have a good story about how do we manage

all the code that has to be written, and how does the code

interact with the data-binding, as well.

BRAD GREEN: That's right.

And let's take a look at another example.

So here we've got a slightly more complex example where

we've got two files-- one index.html on the left, end

UserController.js on the right.

And again, let's take a look at how this works before we