AngularJS

Transcription

MISKO HEVERY: Hi, my name is Misko Hevery. 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 walk through the code. So Misko's going to open his second tab, and we've got a text input. We've got the word "Larry" in there. And when he clicks the word-- the bye button, it says, "bye Larry." Nothing too complex. But if he changes the text and clicks bye, it updates to use "Google I/O" as the text. OK, let's take a look at how we do this. So now, we've got-- we need some logic. We need some way to take that text that somebody typed, and move it somewhere where we can use in our bye button. So our template on the left-hand side, we're adding another piece to the template. We are now telling Angular to construct a template that relates to some code. And in this case, we're specifying that a class called UserController we're going to use to manage this part of the DOM. And this is some new syntax, so for people who have used Angular before, this is some new syntactic sugar we'll be releasing tomorrow. But we're able to create an alias for UserController. We're just going to call it UControl and then we can refer to it later. And what we'll see is that we can put attributes on UControl that we want to access as part of our model. So the input will bind to UControl.user.first. And for clicking the button-- when users click it-- it will specific an ng-click there that UControl should call the bye function that we defined there on the right-hand side. MISKO HEVERY: But I wanted to point out something over here, which is that the UserController has no access to the DOM. There's also no special thing you have to inherit from, no special way that you have to instantiate your model, other than regular object. And notice there is no API one has to call inside of Angular. This is really just a plain old JavaScript type that exists in JavaScript. BRAD GREEN: Right. And maybe even more importantly, notice that there's no new-- we never call new on UserController. We don't create it. Just by specifying in the ng-controller tag, Angular knows enough to create it at the right moment when this view comes into my application. It creates a controller, and attaches it-- or, it hands it the right things in the DOM. MISKO HEVERY: Right So when you have a model-view controller, in Angular, everything is driven by the view on the left-hand side over here. And the view says I need the controller, and so the instantiation of the controller has to happen, which then goes ahead and instantiates the model. Now the thing to notice over here is that all of the arrows point away from the view, and into the controller or the model. And because the arrows point in this particular direction, it means that one doesn't have to start with the view. One can start with instantiating the controller and the model separately. And this is very wonderful in tests. And also, this allows you to easily reskin your application for different devices. BRAD GREEN: Right. And what this really means is that my view and my controller and my model are decoupled, meaning I could change the view with the same business logic and the same model for maybe different devices, or different use cases. So Misko, let's talk about how this assembly of the application actually works then. MISKO HEVERY: So here, we're taking a simple case, which we just saw with the hello world, and making it a little more complicated by saying instead of popping up a dialog box, maybe we can use a voice synthesis to actually say the words that we're about to display in the LR box. So in this case, we again need to have a UserController, but notice the UserController says it needs VoiceSynth. And below, we have a definition of what Voicesynth might look like, which then uses the web audio to actually speak to-- to generate the text, and speak it through the speakers. And a thing to notice over here is that the view says it needs a UserController. And the dependency injection system that tries to instantiate the controller, but it notices-- a-ha-- but in order to get the UserController going, I need to have a VoiceSynth object. So then it goes one level lower and says, OK, let me make one of the voice synth. But again, it sees, well, I need a web audio, so it goes one level further yet, and it tries-- it instantiates web audio. Hopefully, that has no dependencies. And then it takes the web audio instance, puts it inside of the VoiceSynth instance, which then is placed inside of the UserController instance. And the whole controller is then handed over to the view. BRAD GREEN: But let's talk a little bit about how this actually works. Like nowhere in my UserController do I actually directly refer to VoiceSynth? MISKO HEVERY: That's right. So normally, when you have a constructor parameter, such as over here, those don't matter. I mean, they're only there for the user-- for the developer to kind of understand what's going on. But in our case, we actually look at the actual text, and we use the VoiceSynth key to match it up against the VoiceSynth class so that we can instantiate it. BRAD GREEN: Right, very cool. Now this is great for building my app, and rearranging my app. If I go to refactor my application, this is cool. But it's also great in testing. MISKO HEVERY: That's right. So let's say we wanted to test this thing. So first of all, we probably don't want to instantiate the whole HTML5 DOM. That's expensive. So we'll start a layer lower, and we're going to say, well, that's just instantiated UserController. But tests don't hear. They don't have ears. BRAD GREEN: They hear very poorly. MISKO HEVERY: Yes. And so we would really like to do is replace the VoiceSynth-- the actual voice synthesizer-- with a VoiceSynthMock. And so what we're really trying to tell to the dependency injection system is that we're going to change the recipe by which you build the application slightly so that we can get a subset of the application going configured in a slightly different way. And once we get the subset, it's very easy to apply stimulus to it, and assert that the right methods get called on a VoiceSynth. BRAD GREEN: Right. OK, let's take minute and step back, and talk about what do we got so far. MISKO HEVERY: So we have this imperative world, and we have this declarative world, imperative world being, let's say I wanted to center something. In imperative world, you have to compute the width of the page, the width of the thing you want to center, divide it by half to get the midpoint, align the midpoints, and then render the text that you want. The trouble with this way of doing it is when somebody else comes afterwards and looks at the code, and they're going to have to reverse-engineer. What is the side effect of this piece of code? Declarative is, on the other hand, if you simply say I want to center to this thing, and it doesn't matter where the implementation is. And actually, the concept of centering might actually be implemented slightly differently in different browsers, as long as the end result is the same thing. And so, up to now, usually when you have a framework, the developers really are just, hand it over, and say, you get to use this imperative thing-- this is you, you can play with it any way you want. But the declarative thing, well, we'll have the framework give you some vocabulary for the declarative stuff, but it's essentially fixed. So we thought, wouldn't it be great if we could take this vocabulary and extend it. And this was our a-ha moment, and saying, hm, why are we in some way special that we can create vocabulary, but the developer can't? What if we gave the same tools to the developer, as well? And so we have a change in Angular in that the developer gets to use the imperative or gets to use the declarative world, depending on what they feel like is the best way to solve this particular problem. BRAD GREEN: That's right. Let's take a look at some examples. So we've seen how directives can be used to express the way we wire our application together with ng-model and ng-controller, and the way we change the structure of the DOM with ng-show, as we saw. But you can also use it to create reusable components. For example, if I wanted maybe a star rating component, I could, after implementing it, then just use it in my template by saying, angle-bracket-rating, and then pass the data to it that it needs through its attributes. You can create more complex things where you've got nested, or components that need to collaborate. For example, a set of tabs will have the information about which one is highlighted, and which one should I paint with a box around it. And then the individual tabs inside will contain the title and the content. You could also do it not just by element name, but also by attribute name. And so you can create things like a tool tip, where you could place it on a span or on a tab or in a rating, or anything else in the UI. OK, we've covered kind of the basics in Angular. And now let's take it back to the way we were kind of creating apps before we wrote the Angular framework. We weren't using jQuery, but we're going to use jQuery here because we feel like a lot of folks know it. We've got a simple application. Misko's going to show us. MISKO HEVERY: It says you're going to tap dance, but you got no shoes. BRAD GREEN: I took them off because I knew that line was in there. And then we're going to rewrite the application in Angular, and show some of the differences. MISKO HEVERY: So here's a very simple application. All it really does is it shows you a list of projects. And what you can do is you can add, and it brings you to the detailed view. Notice when I click the Add, it's a single-page application, the URL didn't actually change. It's the same URL. I can say something over here, hit Save, and now I have my new item inside of the list. I can further click on it, and delete it. BRAD GREEN: I should mention, there is a very simple RESTful server running a node on the backend here that we used to persist the project. MISKO HEVERY: So really, it's just an application with two views-- very simple. And what's strange about this thing is that it takes me two sentences to explain what it does, yet it takes me about 200 lines of both HTML and JavaScript to actually implement this. And so there's a little bit of a disconnect over there. So what does this look like? Well, so this is a list of projects. And in this case, we have a template, which is a table. And inside of the table head, we have this plus on the right-hand side. And notice what we have to do here. We have to say, well, there's a link-- so that it looks like a link-- but actually, it actually goes nowhere. Inside of JavaScript later on, I'll show you, you basically have to set up a click listener, and we have to prevent the default behavior of the browser-- which is to navigate to a link-- and actually just modify the DOM to render the details page. And this kind of breaks the paradigm of what a web application is supposed to be. And so we'll show you how Angular can make better usage of this thing. The other thing is that in the table row, the same kind of a click has to happen, but there's no-- it isn't clear what the text goes inside of here. And so we actually have to get a hold of this thing from the JavaScript side, as well. We do something similar for the form for the details view. So let's have a look at how is this implemented in JavaScript. So the first thing you're going to notice is that there's a tremendous number of selectors that have to get executed in order to get a hold of the right pieces of the DOM. And what the selectors essentially end up doing is they are essentially creating the arrow going in the opposite direction from the code to the view that creates coupling, and it makes it difficult for a web designer to come in and move things around, and number break the CSS selectors that select them. BRAD GREEN: Even if we're using IDs, it's still fragile. It's still something that you have to be careful about when you move things around. MISKO HEVERY: That's right. And so this basically shows you how we rendered the page on the right-hand side. So we had this show method-- what it does is, well, it has to assume that there might have been a different page before, so it has to remove the existing content. It has to add its template to it. It has to remove any existing projects that happened to be inside of the template before. And it has to set up this click listener, which I talked to you-- mentioned briefly before, which does the navigation for one page to another. We then go and do an Ajax to the server. And for each project, we basically do clone of the table row, write the data into the right locations. And again, we have to set up a click listener which transitions us from the detail to the-- I'm sorry, from the list view to the detail view. And so, what's lost in the process over here is it's not clear what this thing actually does. There's tons of DOM manipulation, and the actual business logic of this particulate page is lost in here. BRAD GREEN: Right. So let's fast forward, and let's reimplement it in Angular. Let's see how it's different. MISKO HEVERY: So let's look at the template again. What we have done is we have removed the templates from index.html and replaced them with something called a view. So this is essentially a hole into which individual pages will be loaded. And the actual pages get moved into a separate file. BRAD GREEN: Now this template, the top of the template right now-- if this was a more complex application, this is where we would put maybe are top nav, or our left-hand nav. But here it's simple. We just have one view that we swap in and out. MISKO HEVERY: Exactly. Now notice, instead of registering a click listener for this href, we let the href do what the web does best, which is create links. So this case, we're saying, look, there is a sub-view of this particular page, which is the slash project with no ID. And this is what's tied to the URL. So now if I reload this application, and I click on the plus, notice that the URL has changed. Now a nice side effect of this is all of a sudden, our back and forth button just work without really any effort whatsoever. BRAD GREEN: Now, we could have done that in the jQuery reversion-- just a lot more work. MISKO HEVERY: We could have done it, and it would be a lot more work. But this is a model that people are very familiar with, that developers are familiar with, because it's the kind of round-trip application model, except the round-trip, it all happens in the browser. There's no actual round-tripping. This is still a single-page application that we have here. So the next thing to notice is that, instead of manually making clones on the table row, we have this other directive called an ng-repeat, which basically says for each project in the list of projects-- and I'll explain where the list of projects comes in a second-- we just want to have a copy of the TR, and this does the copying and cloning and managing it automatically. The next thing is that all of the double curlies shown over here naturally show us where things belong, so we don't have to have selectors to place them there. And finally, again, we have an example of deep-linking where, if you want to click on an Edit button, it just means that we want to update the URL with a specific ID in the URL that becomes bookmarkable. And again, all the magic of bookmarks happens automatically for us. So let's look at how this changes inside of the JavaScript. And this is the goal that we were more after, which was, if you want to explain to somebody what this particular page does, it's just as simple as saying, give me a list of projects. It's a single sentence. And I want this to be a single statement inside of my code, as well. So in this case, we're saying we have a project list controller that is a single item in there. So how did we know to load this particular controller? Well, if we look over here, this is where we set up routes. We're saying we're emulating kind of a round-trip application, but in the browser. So we have to say that when the URL-- which is shown right here-- is a regular slash, we activate the project list controller and the project list template. And so the project list controller simply says, go to the database, and fetch me a project query. BRAD GREEN: OK, so there's something interesting going on here. We should explain. When we query, we're actually connecting to the database, but you'll notice, there's no call-backs there. What's really going on, Miska? MISKO HEVERY: So this is a place where we get to take advantage of data-binding in a very unique way. So project.query query does essentially an XHR in the background. And the way it does this is that it returns immediately, but it returns an empty set, because the server will respond in some future point in time with the actual data set. And it takes that ng-array, and just assigns it to the project. So when the ng-repeat gets notified to say, hey, I have a new data for you inside of the projects, it simply says, oh, there's nothing there, and therefore it renders nothing. But at some future point in time, the data actually does show up, and updates the same instance of the array, which then automatically causes the ng-repeat to unroll itself and make as many copies of the project as you have. So in the simple situation where all you need is to fetch some data and render it, we can actually bypass the whole need to have a call back. Now the second thing is, where did the project come from? This is where dependency injection comes in, and this is how the application actually gets assembled, which we kind of mentioned that earlier. So right above here, it says a project can be made by using something called a resource. A resource is just a service in Angular that we can use to build JavaScript types for the RESTful backend services. So we're just saying, this is going to be a standard RESTful object, which we can just use query on to fetch the data set. And again, notice that the application gets automatically assembled for us. So just simply by navigating to the right URL causes the right route to be activated, which then activates the right controller, which then knows to go and make a new project, which then knows to build the project using the resource. And the whole application gets assembled without us ever having to do any of this stuff. Similarly, inside of the project [? details ?] controller, we can simply say, show me an existing project or a new project, depending on whether we have an ID or not. BRAD GREEN: So how many lines of code do we have? MISKO HEVERY: So we are about 40 lines of code. And we actually added a new behavior, because we have deep-linking available for us. BRAD GREEN: OK, that's very cool. As your manager, however, I need to ask you to add more features to this application. MISKO HEVERY: More features? OK BRAD GREEN: Miska, could you please add more features? MISKO HEVERY: What feature would you like to add? BRAD GREEN: OK, well, thanks. So this is a list of projects-- probably frameworks. People like to write frameworks, as we know. It could get long. How about add the ability to filter how many frameworks are there if I want to search for the one I want. MISKO HEVERY: So the first thing you need to add is an input box, right? So if I refresh now, I have an input box. And if I type into it, this text actually ends up in the memory location called search text. Now we need to do something with this particular case. Now one of things we have-- and I'm sure you're familiar with in UNIX-- is the concept of filters, which we have, as well as using a simple pipe-character. And we can run it through kind of a special [? mini-ask ?] functions. In this case, there's a function called filter-- I know the naming is a bit confusing. BRAD GREEN: I see, yeah. MISKO HEVERY: But what a filter does it just looks through the list of objects in an array, and sees if any of the objects happen to have a text inside of it that matches the search text criteria inside of the input box. So now if I refresh this, you will see that as I type the word "web," it will show only those projects that actually have the word "web" inside of them. Notice how the repeater automatically grows and shrinks as the filtering changes. BRAD GREEN: OK, very cool. However, modern applications use animation to show me-- to give me a more intuitive sense of what's going. Could you maybe animate the items in the list in and out as-- MISKO HEVERY: Do you understand how complicated animations are? BRAD GREEN: I don't. I'm a manager. MISKO HEVERY: I see. [APPLAUSE] So animations-- as you guys all know, I'm sure-- are complex things, because you have to add things to the DOM before they actually come on to stage, then you have to transition them to keep track of timers, remove things, and so on. And this is where the power of the declarative world really comes from. Because really, what I want to express to when I'm building the application is there is something called animation. And I want to animate this thing using a slide animation. A slide animation is just something I've declared inside of my CSS, as this is the set of transitions we want to apply to the system. But actually managing the DOM's add and removing, setting the classes at the right time is actually managed by this ng-animate directive. So let's refresh this. And notice, as I type "web" now, it removes and adds item in the correct way with just a couple of keystrokes. [APPLAUSE] BRAD GREEN: Sassy. Very sassy. All right, so we're kind of at the end of our coding portion. Miska has, however, added some other interesting features also in sort of a declarative way. But we'll just demo them. You can go to the GitHub repository. We'll give you a link at the end of the session. But you can also do things like animate between views. So if I was on a mobile device, I would want to be able to slide back and forth. We've also done form validation, so you can have things that are required, or that are not really required but they have to be in a specific reg-x format, like something must be a URL. And these things, as I mentioned, we can add in also a purely declarative way. These are well-understood problems. We can just put them in the template. So we should talk about a couple of other things before we wrap up. One of the things that people tell us is fantastic about Angular-- besides the framework-- is the community. And there thousands-- hundreds of thousands of folks in the community who do a great job of helping each other, documenting new things in Angular, adding code, all kinds of things. There are meet-ups that happen regularly. There are-- on our Google group, on Twitter, on Stack Overflow, and Google+. There's a tremendous community. There's an IRC channel that's very active, too. As you can see from the map, there are actually still some places in the world where we would love to see monthly meet-ups, and we'd love to help you make these happen. Let's go next. So the rest of the ecosystem, Angular kind of fits a small piece of the whole web development puzzle. And I think this is kind of cool, because it's made space for other people to create things that fit in the world. We've developed some of them, but a lot of other folks have created things, too. So in the world of tools, one of the things we created is a Chrome Developer Tools plug-in called Batarang. And Batarang lets you visualize your application, visualize your data-bindings, where your template is set up, optimize the performance, and debug it-- for all of the Angular-specific concepts. The good folks over WebStorm have created a plug-in that makes it Angular-syntax aware. And a lot of us use WebStorm on the team because of it. We've been working with Addy Osmani and Paul Irish and the other folks on Yeoman to make it very easy to scaffold an Angular application, to update its dependencies, and then to build and deploy it when you're ready. And then, one of our team members, Vojta, has done something I think is extra special. We talk a lot about testing. But making the framework testable was not the full story. He wrote a test-runner called Karma. And Karma, we think, is the fastest, most reliable, easiest test-runner on the planet. Matter of fact, I would say it would change your life. We should do a demo of that later. But it's awesome. Go download it. Search for karma test-runner. It's awesome. Now when we were talking about directives, we said that you can write your own things, like star ratings and tabs and tool tips. And it turns out a lot you don't want to be doing that. And so, there are a ton of directives-- web components-- that you can just use. And we have things like the Angular UI Project. It's not part of Angular but, they've collected a number of the web components from across the web. And they're specifically a Twitter Bootstrap theme set of components. There are also commercial versions, like KendoUI and Wijmo So you can come out of the box with a whole bunch of components that you just snap together like LEGOs in your template. In the rest of the world of libraries, there are things like BreezeJS that gives you a very rich set of tools for manipulating data that comes from SQL and NoSQL databases. If you want a database in the cloud, there's Firebase, who have created Angular-specific binding so that you can use them with our data-binding system. And the folks at Salesforce recently created a developer tools pack that lets you create Angular applications with Salesforce on the backend on mobile devices. And then there's books. I actually-- I wrote one of them, the one with the fish. I think that is the most handsome of the books. But there-- I think last count, there are seven books. Really, you should buy them all. I could not choose. All right, so thank you everybody. Thanks so much. We-- at the lower right-hand side is the link for our GitHub repository, for the demos that you saw today. Misko and I are available on Twitter and Google+ if you want to reach out to us. We're going to be in the Chrome Sandbox upstairs for the next half hour. We've got a little bit of time for questions. But we'll be there. We'd love to answer questions. We've got some stickers to hand out upstairs. And then Angular books are going to be in that Chrome Sandbox area on Thursday and Friday all day long. Thank you for coming. Really appreciate it. [APPLAUSE] So, let's go over here on the mic. AUDIENCE: So good to see Angular at I/O. BRAD GREEN: Thank you. AUDIENCE: So my question is, how do you configure the curly braces for data-binding? That is configurable, right? I'm using Jekyll with Liquid templates, and there are curly braces used there as well. So I'd like to be able to configure that. And do you recommend against it? MISKO HEVERY: Yes, so there is a interpolation provider which allows you to configure the starting and ending set of sequence of characters that will do this. And so you could use that. The caveat is that, if you're using a third-party library or third-party widget library that assumes curly braces, you might break them. It's not true? [INAUDIBLE] Oh, we compensate. Oh, we fixed it now. BRAD GREEN: OK, good. MISKO HEVERY: You can change it using the-- BRAD GREEN: It just works. It just works. Thank you, Igor. AUDIENCE: Great, thanks. BRAD GREEN: All right, sure. AUDIENCE: I come from China as a [INAUDIBLE] [? TGD ?] organizer. So I notice that a map, a pocket of all the Angular's community. But in fact, AngularJS [? dot-send ?] is building just users [INAUDIBLE]. In fact, in China, it is very-- so many people like AngularJS. so my question is how make the AngularJS community, and you can address-- you can know it. I just want to-- I think you [? might ?]. You're not quite [? sure? ?] BRAD GREEN: I'm kind of missing the question. AUDIENCE: I'm trying to say [INAUDIBLE] [INTERPOSING VOICES] MISKO HEVERY: I think he's saying there's an awesome [INAUDIBLE] AUDIENCE: [INAUDIBLE] BRAD GREEN: You're saying in China, there's a fantastic JavaScript community, and there's AngularJS going on. AUDIENCE: But we lost it in your map. So I have a question, why-- BRAD GREEN: Ah. Tell me where it should go, and I'll put it on my map. AUDIENCE: OK, thank you. BRAD GREEN: Yeah, that would be awesome. Thank you, thank you. AUDIENCE: How is Google using AngularJS internally? Are there going to be apps that we use? Or that consumers use? BRAD GREEN: Yeah. We've built a lot of internal apps on Angular. Google Feedback was one of them. The two big external applications that we've built on top of it is DoubleClick, which makes some money for Google. This is display advertising. I mean a lot, actually. And then YouTube has built their-- it's kind of like an embedded in the PlayStation 3 application. So the live player that you get with PlayStation 3, that's built in Angular. There's some more stuff on the way. Can't pre-announce it. AUDIENCE: Yeah, because that's always a concern that you guys keep using it so that it keeps growing, right? BRAD GREEN: Indeed, indeed. It's well-loved within Google. AUDIENCE: OK. BRAD GREEN: Thank you. And over here. AUDIENCE: First question is, the query-- it does have a call back, though, right, if I need it? BRAD GREEN: That's right. You can have a call back if you want to. AUDIENCE: OK. BRAD GREEN: Yeah, for catching errors, and there's some other reasons you might want [INAUDIBLE]. AUDIENCE: And secondly, we think Google-- is there any sort of internal fight with Backbone? BRAD GREEN: There's actually no fight with Backbone in terms of Google. No. There's none. None whatsoever. AUDIENCE: Thank you. BRAD GREEN: Yeah. Yes? AUDIENCE: Hi, yes. I just started using Angular for the first time actually a couple of weeks ago. BRAD GREEN: Thank you. Awesome. AUDIENCE: And I absolutely freaking love it. MISKO HEVERY: Thank you. AUDIENCE: So-- BRAD GREEN: Next question. Awesome. No, go. AUDIENCE: The search functionality, it's really nice. But can you talk a little bit about patterns to use when the data set is big, and it needs to be paged in and out, and how-- what's the right way of setting up your services? MISKO HEVERY: I think that's way beyond what we can answer on stage. BRAD GREEN: Yeah. I mean, I can point you-- there are several services that help doing this, for help doing the pagination, and doing sort of an infinite scroll effect, which is what folks often want. AUDIENCE: The search, the actual search, right? The ng-search stuff. Not just the scrolling, but the actual-- BRAD GREEN: Yeah. So that as you type. You want it like the Google homepage search style thing. AUDIENCE: Yeah, even if I set up like a backend search stuff. BRAD GREEN: As Misko said, there are some details-- maybe come up to the Chrome Sandbox, and let's have a chat about it. MISKO HEVERY: Yes. That's a better way of-- yes. AUDIENCE: Thank you. BRAD GREEN: Yeah Over here? AUDIENCE: OK, first of all, thank you for making Angular. You saved my bacon like two months ago making a site. It's really awesome. Two questions. First, what are your recommendations towards search engine optimization for sites built with Angular? And the other one is, I'm currently trying to get a site done in Angular, but the manager is concerned about users who don't have JavaScript enabled, or what-- MISKO HEVERY: What year is this again? BRAD GREEN: I think it's 2002. But no-- so I can't help your manager, because he is living somewhere else. But as far as-- what was the first question? AUDIENCE: SEO. BRAD GREEN: SEO, yeah. So there's a recipe for SEO. There's a website called "Year Of Moo." It's this guy named Mateo. He worked with us on the animation directive actually. And he is a very good documented path for doing this. Search for "Year of Moo" angular SEO. MISKO HEVERY: And it has to do with the headless-- BRAD GREEN: Using PhantomJS to kind of render your pages. AUDIENCE: OK. And that wouldn't be penalized by you guys, as Google? Because-- BRAD GREEN: No. AUDIENCE: Since users are-- BRAD GREEN: There's no way for Google to know. We see what you finally render. AUDIENCE: Oh, OK Thank you. BRAD GREEN: Sure. Yeah? AUDIENCE: So we already built a map with Backbone and other stuff, and we don't have a-- it's like a financial app. So now, do you think I could introduce Angular and, with it's help-- because it's a huge app, a trading app, but lot of Backbone, and a lot of stuff in it. BRAD GREEN: So what is the core of the question? Could you rewrite in Angular? AUDIENCE: I mean, do I have to only rewrite something? Or will it-- can I use this as a part of it? Or how will this help-- MISKO HEVERY: Yeah. I think [INAUDIBLE] is [INAUDIBLE] do a full rewrite, or you can do it partially. And one of the things we wanted to make sure that Angular plays nicely with other frameworks so that you could rewrite an app one page at a time, or something like that. So there's even-- I've seen some blog posts about people trying to get Angular to run together with Backbone. So they'll use Backbone for the models, and Angular for the data-binding and rendering. So that should be possible. AUDIENCE: Yeah, because we use data-binding of the Backbones. Thanks. MISKO HEVERY: I think we can make time for one more question, and then time is running out. BRAD GREEN: Yes. Right over here? And we'll hit the rest of you up in the sandbox. AUDIENCE: All right, score for me. So I actually have been using it for the past half year, and loving it. I have two very specific questions about ng-switch. So one of them is, lately I've been doing a lot of nested ng-switches. One inside-- like for instance, one is true, and inside that another ng-switch, and sometimes a third. Should I be concerned about doing nested ng-switch? That's question number one. MISKO HEVERY: If you're just going to nest just a few ng-switches, it shouldn't be an issue. If you're gonna nest 50 of them, then maybe you should look at a different way of doing it. AUDIENCE: Yeah, OK. That's good to know. So the second one is, is there a good way to do undefine with ng-switch, because I haven't been able to do that very successfully. So what I always have been doing is to actually have the wrapper do a return true or false. And then have it go to web [? branch ?] when true, and then when false-- versus when I tried to do one undefined, it just doesn't seem to fall to the right branch. So not sure if anybody else has seen this similar problem. BRAD GREEN: I didn't quite get it. But maybe let's continue this back upstairs. AUDIENCE: Yeah, OK. Cool. BRAD GREEN: Thank you everybody. MISKO HEVERY: Thank you BRAD GREEN: Thanks so much for coming