Tip:
Highlight text to annotate it
X
>> GREEN: Okay. So, we're going to talk about a bunch of things, and not all of it has hit
yet. But we're going to--there's a bunch of things that are live that we're going to demo
that are--we're got a release candidate for in 1.2, right?
>> MINAR: So, many of the things are finished, they're already master. Some of the things
are like we're putting final touches on the stuff, and we want to get the release candidate
out as soon as possible. But what you'll see is what we'll have Angular 2--1.2 and you
can give us feedback on that, and just I hope you like it.
>> GREEN: Okay. I'm Brad Green I'm the manager for the AngularJS Project at Google, and...
>> MINAR: I'm Igor Minar. I'm the team leader on the...
>> GREEN: Oh, right. Well, let's get going. Let's see what we got here.
>> MINAR: Yup. So, where should we start? A lot of stuff. So, we've just got some bits
and pieces, some quiet--they're actually quiet... >> GREEN: In those theme, we haven't practiced
very much so we're just kind of vomiting on you guys. Be ready. You guys in the front
row, watch out. >> MINAR: Well, we have quiet a few demos
and--yeah, if you have questions, please ask at the end, we'll be happy to answer and just
go back to code examples and talk about that. Let's talk about Angular 1.2 and how it happened,
and how Community helped us. >> GREEN: And so, we released Angular 1.0
almost a year ago, in June actually. So, a lot of you have been with the project. So,
actually, how many people are new here? Okay, good. Thanks for coming. A lot of you--a lot
of folks have been with us since 1.0. As a matter of fact, there's a lot of contributors.
We wanted to thanked all of you. Here is the list in 3pt fonts of all the people who have
contributed since 1.0. There's 248 folks who are not on the Angular Project who have actually
added code to Angular. >> MINAR: Thank you so much everybody. Like
you really shaped what Angular 1.2 is. We--when we set out on the journey of building 1.2,
we had a few features that we wanted to add, but it was really Community that helped to
shape what Angular 1.2 ended up being. So, thank you for that.
>> GREEN: Yeah. All right. Well, one of the most requested features has been the ability
to do animations, and animations hasn't been easy. Igor, you want to talk about why?
>> MINAR: Right. So, with Angular, everything has been declarative, and there's very little
dominant collation you need to do. But if you happen to play with CSS transition or
CSS animations, you realize that there's quite a bit of manual work you have to do to make
these animations possible in the browser using the CSS, or if you don't even have CSS, using
Java Script fallbacks or animations. So, we thought quiet a bit, you know, how can we
preserve the declarative nature of Angular and Angular templates, and at the same time
make animations possible. Because often we see in applications that the presentation
logic and the business logic has to mix in order to make animations possible, and you
know, if you follow Angular for--if you have been following Angular for quiet a bit, we
really feel strongly about not mixing or polluting business logic with presentation logic stuff.
So, here's what we came out with. We came up with a new directive called ng-animate,
which collaborates with the service $animator. And with this--with this directive, you can
declaratively control animations. Angular will do most of the grunt work. These animations
worked with CSS transitions and animations. We also give you options to do JavaScript
fallback if you have to. But what we see out there is that there's quiet a bit of uptake
for, like, CSS animations libraries, and we thought it'd be great if we could just leverage
these. So, instead you having to write the animations over and over again, what if you
were just able to pick Greensock or many other awesome CSS animation libraries, and just
use them in your applications. And this is what we did. So...
>> GREEN: So, Igor is going to do the demo, but I should say we're actually leading off
with the feature here that was done not on the Angular Team--well, partially on Angular
Team. So, Matias Niemala, one our main contributors actually started and did a lot of the work
on this. >> MINAR: Right. So, Matias actually created
a demo to just show off how powerful this feature is. And he took the "Built with Angular"
site, and just rethought it, you know, "What would this site look like if we had animations,
and if we could just animate many of the things that happen?" So, let's take a look. We have
just a list of projects, so before I--before I do this "Built with Angular," just list
of Angular projects, and you can just drill down and see what has been build with Angular.
And what Matias did is just made it look really hot. So, you clicks on stuff and there are
transitions that happen, things just animate in and out. It looks really nice. So, we're
going to show you actually how this works internally, not on this application, but on
simpler examples, so you'll get to see. But the important thing is that we actually not
only build this ng-animate, but we also made it work with ng-view, ng-repeat, and many
other built-in directives that do this changing of the DOM structure that often needs to be
animated. >> GREEN: We'll see examples of each of these.
>> MINAR: Yeah. >> GREEN: Okay. So, right now, what you can
do is you can animate DOM state transitions, you can dominate--you can animate when DOM
elements come into and out of existence. >> MINAR: For example, repeaters shrinking
or expanding, or ng-view switching from one template to the other.
>> GREEN: Right. We'll see some examples. The next thing we're working on--the next
thing that Matias and Misko are working on are the ability to animate CSS transitions,
where I add or remove a CSS class. So, you can do things without DOM state trans.
>> MINAR: You don't even need to destroy DOM in order to bring animation to your application.
It's enough to just add a class and you can make things zoom in or zoom out. It's going
to give you a lot more flexibility and this is--this is something that's going to come
after 1.2. The other--the other topic I want to talk about is a little bit boring, it's
$http. How many of you are not familiar with $http?
>> GREEN: Yeah, couple of us. So, it's actually... >> MINAR: I see like one hand. So, $http is
really just a wrapper around the XHR object in the browser. And just makes it much easier
to make calls to the server and make HTTP requests. The reason why I'm bringing this
up is because http is so important that we see it being used in many of the components
that make Angular. And any kind of enhancements to this very core service have impact on the
rest of the Angular. So, some of the things we did; we now allow custom types, custom
respondType--responseTypes, so we can send blobs over the networks. For example, we have
support for authentication, so you can use withCredentials headers to just do authentication
on the HTTP level. We allow you to customize cross requests forgery on configuration, so
this becomes much more flexible. Many of you ask for aborting requests, so now you can
abort requests. And my favorite feature is around interceptors. We have interceptors
in Angular before these were response interceptors, and what response interceptors allows you
to do is just intercept the response and do something with it. Well, many of you asked,
"What if I don't want to intercept the request as well?" And there was feature request, "Hey,
let's just add request interceptors." We thought about this and, like, "That sounds good, but
it would be much better if we had around interceptors, wherein one go you can just intercept both
the request and response. And this is what we did. I'm not going to show you a demo.
I have a link to documentation. But what is this great for? This allows you to really
abstract the way authentication from the application, do any kind of async request and response
rransformations, and also, do transparent error recovery. And when I say transparent,
let's take an example of your application makes a request to the server, but as the
request was been made, the authentication, the session--the application session of the
user expired, and now, the server just responds with, "Hey, user is not logged in anymore."
But what you can do now is you can just intercept this response, and you can show up a logging
dialogue to the user, have the user log in, re-establish the session and then continue
with their original request where it left off, and the rest of the application doesn't
even know that there was any kind of authentication problem. You can learn more about this in
the documentation. >> GREEN: By the way, we'll give you a link
to this entire slides-deck. They're all at in [PAUSE] and documentation and all of those
things, so we'll make sure you've got a link to that at the end of the presentation. $resource,
another feature for communicating with server, but RESTful communication stuff.
>> MINAR: $Resource is a high-level service in top of HTTP. It's a--it's a RESTful client
generator, it's a way how you can build RESTful clients in your application very simple--n
a very [PAUSE]. What we added was more configuration options, configuring all of the HTTP low-level
stuffs like headers and reconfiguring URLs. We also added support for resource interceptors,
so you can create a resource-specific interceptor, which allows you abstract more of the underlying
HTTP stuff from the application and just keep it in resource definition. And most importantly,
we enhanced the APIs with promises. This is--this is something that people asked for a--for
a long time. And let me show you a demo of that actually. So, we have a very simple application
that you probably know this application from our homepage, it's a--it's a list of popular
frameworks and libraries, and we fetched this list from the servers, so let's see how we
built this. So, in this application, we're using a little bit of unrelated feature, routeProvider
and resolve property on the routeProvider. Let me wrap this font. Okay. And if you ever
try to use resolve property, it makes the application look much better. The transitions
from one view to another are much more seamless and better, but you have to deal with promises.
And because the $resource didn't support promises, there was a lot of work you had to do. So
for example, just to fetch a simple project to list, you had to take $q, you had to create
a deferred object, you had to make a query to the project, and then you had to resolve
the deferred with the response, and at the end, we had to return the promise. This is
like nobody would do this because there's just too much stuff you have to know. Well,
now because $resource supports promises, what you can do is just say "Give me projects,
query them, and return the promise." And what this will do is in our controller, then we
can just say, "This controllers needs projects." And we can then bind the projects to the scope,
or in this case, we're using the new controller as syntax that we'll talk about soon. And
there is no asynchronous stuff happening in the controller constructor. This simplifies
the code and make things much better. Awesome. [PAUSE] Let's talk about $route and ngView,
$route and ngView is how you can do browsing in Angular applications, and one of the very
small change that we did, but has a big impact, we separated all the code for routing into
separate module, just like we have ngResource, we now have ngRouter. We did this for some
of the reasons. One of them is that, many applications especially the mobiles ones,
they don't use the $route to control routing, and they--unfortunately, we're forced to pull
the bytes that $route and ngView representing in the AngularJS minified file. So, by separating
this out, only those application that needed it will include it, and those that don't will
not. But also, we see that in the Community, there's a lot of interest in pre-embedded
routing, and there are projects that tried this, and one of my favorite ones is Angular
UI-router. If you ever try that, it looks really awesome. It's...
>> GREEN: They've heard about that earlier tonight, actually.
>> MINAR: Oh, you did? Okay. I wasn't [INDISTINCT] I'm sorry. Yeah, it's a--it's a state-based--state-based
routing, state machine based routing in Angular applications, and by extracting route into
separate module, we give space to alternative implementations, and I think this is good
because I don't think that the Angular team should be the only one deciding, like, "This
is the right way to do something," and by giving more freedom to the Community to innovate,
we can make Angular better together. Another feature that we added to existing routing
is catch all parameter matching. >> GREEN: Wildcards.
>> MINAR: This--basically wildcards, it's just another way how--it's extend--it's extending
the syntax, how you can manage URLs against the patterns, against URLs, and it's something
that many people wanted for their applications. And animations support, just like we mention
ngAnimate, ngAnimate is now deeply integrated with route. And let me show you a quick demo
of that. So, we have the same application that we saw before, but the biggest difference
now is that the views will transitions in as animation, and also if I switch to a different
view, that there's a--this animation happening. [PAUSE] And all I have to do to make this
happen--what's up with the template? [PAUSE] I had to specify on ng-view that we have ng-animate--there's
an animation that is bound to this--to this view directive, and the animation is a viewSlideAnimation.
This is the expression, so it actually is a model that is controlled by the application.
And if you look at the routing on this application, we'll see that we define [PAUSE] if I can
find it quickly. What the heck. We define new listener on the routeChangeSuccess event.
So, whenever a route change happens, we redefine what viewSlideAnimation is, and viewSlideAnimation
will have two properties; enter and leave. These properties then points to classes that
control the animations, and this way, we can create different animation, so animating to
the--to the right when we are transitioning from one--from the details view to the master
view, and animating to the left when we are going from the master view into the details
view. ngRepeat. >> GREEN: Keep talking, man.
>> MINAR: ngRepeat--ngRepeat is a directive that is used almost in every application,
and again, you know, we thought it has to support animation support. And you told us
that it has to, so [PAUSE] It takes additional ng-animate attribute as a collaborator, and
again, just like we saw with ng-view, through ng-animate, we can just define what kind of
animation should be applied for elements coming in and out of DOM. So, in this case, we're
just saying that using slide animation, and notice that we're using slide as a literal
string because ng-animates takes expressions. So slide in this case is defined in a CSS.
[PAUSE] and let me show you that. There is bunch of classes that start with slide. So
there's like slide-enters, slide-enter-active, slide-leave, slide-left, right, and all of
these. These are all just reusable CSS animations that you can use over and over in the application.
And once you've build them, then you can use them with different components. But more--most
importantly, when I start typing in my list you just see that these animations have been
applied to the elements coming in or coming out of DOM. You don't have to think about,
"Oh, how long do I need to keep this element in the DOM until the animation is finished
and then remove it?" Angular takes care of all of these. All you have to specify is which
animation to apply, and then you just have to, using conventions, specify the animation
using CSS. >> GREEN: That's right. If you change your
animation timing in the CSS, we actually know that and we delay the the DOM and [INDISTINCT]
>> MINAR: Yup. The next feature, ngRepeat (multi-element repeater). We heard that it
was impossible to build a DOM-based templating language that will be able--that would--that
would allow possibility of repeating over multiple DOM elements, or any kind of like
constructs where Multiple DOM elements would be grouped, and it would just work everywhere.
And it's true that it's hard because there are many cases where you just can't create,
like, artificial nodes to just group elements. For example tables and lists are good example
of that. The same applies to options and so on. So, we came up with a very interesting
solution where we allow you to just specify -start and -end. And this actually applies
to any kind of directive that you want to use. This is not just ng-repeat or specific.
You can use it with ng-switch, but with--and the most common use case will be ng-repeat.
So with ng-repeat-start, you can say, "This is the start of the repetition," and with
ng-repeat-end, you mark the last node, and everything in between is part of the DOM fragment
that needs to be cloned every time we expand it for a new model in the collection. So,
in this case, we are iterating over books. It's--we're using and s as defining
a definition for these books. And and are very interesting because they are
not even, like, nested, they are just sibling elements, and they're really to deal with,
especially if you have a templating language. But with these, you can easily just mark them
with ng-repeat-start, and it just works. Oh, we have an example, but the code is pretty
much the same as what we saw. And you see that they render properly, and if I hit my
giant "Add MOAR" button, it will add more stuff to the DOM. In this--in this way, you
can just iterate over table rows, table columns, lists, whatever you have. Next one. Again,
ngRepeat track by. >> GREEN: Yeah. So we have this awesome property
where Angular repeaters, they bind to the references in a black in collection.
>> MINAR: We keep in association between the model instance and the node, and that way,
for example, for your collection, you can just reorder this collection. We will just
reorder the DOM nodes in the DOM. >> GREEN: And this works out really well until
some--in some cases where you might reload data from the server, but you can't guarantee
they're going to use the same collection. >> MINAR: Right.
>> GREEN: So, what do we do? >> MINAR: So, we--we're introducing track
[PAUSE] extension to the ngRepeat expression. And what you can say--you can specify, what
is the property that should be used to keep the association between the DOM node and the
model. So, in this case, a very simple example where we have--we are repeating over students
and we're just printing their names and scores, but we are saying that, Use the student ID
to track the--to track the association between the DOM node that is going to be displayed
to the user and the actual model instance. And let me show you this code, and it's going
to make a lot more sense. So, the template looks just like what we had--we have ng-repeat
and says, "track by student.id, and we are printing a student name and student's score.
But when I hit the "Make Smarter" button... >> GREEN: I wish I had that button.
>> MINAR: That actually going to increase the scores of all the--all the students. Like
this example is a little convoluted, but--or contrived, but what we're doing is whenever
the button is hit, we're going to call this function, and this function will reset the
model to a new--a new array with new objects. But these objects have the same ids as the
ones before. So, we're not dealing with the same objects as the ones that were originally
used to render the repeater. But this new objects have the same ids.
>> GREEN: And so, they'll render in the same order. It's important.
>> MINAR: Yup. And if--let's see. I'd like to show you--if I go to the console and actually
inspect this element, you see that once the button is hit, the binding is just updated,
and if we destructed the DOM like the position in my web inspector would disappear because
the DOM node would be gone. You can play with this, and there's actually a way to remove
the track by and see how the DOM nodes get destroyed, you'll see that. This is really
useful especially in bigger applications where the models are more complex. And that's where
you'll see--you will be able to take advantage of this feature.
[PAUSE] >> GREEN: Controller as. We actually demoed
this at Google.IO, but it's quite--it's good to revisit this.
>> MINAR: Okay. Why are we doing this? >> GREEN: So, there's--sometimes in--where
I write my controllers, I'd like to--maybe I don't even need the scope. I want a simpler
syntax, like, for the way I define my controllers. >> MINAR: Or maybe we could just getting started
with Angular, and you don't even want to know what the scope is.
>> GREEN: Sure. Let's go do that. [PAUSE] >> MINAR: Right. We thought about how we could
simplify the controllers even further. And one of the ways that we came up--sorry--one
of the ways we came up with was this controller has Syntax which allows you to define the
name of the instance of the controller, which we can then use to reference in the templates.
So in this case, we're defining a new controller, DemoController, and we're saying, this controller--the
instance of the controller is going to be known within the scope, but in the scope of
this body as Demo. And then, we can just say, demo.students and we're going to take the
property of the controller of students and use it in the repeater. And really the controller
then can just say, this.students and assign the model to this. So, in the controller,
you don't need to be dealing with scope. This simplifies the controller further. If you
do need scope, you can always have it injected. So we are not taking the scope away, so if
you--if you need to use $watch or other APIs on scope, you still have the power, but this--we
see that this simplifies the code, and from the feedback we got from you guys, it seems
like you like this feature as well. >> GREEN: It seems kind of polarizing or anything.
Some people love it, some hate it. >> MINAR: I see that like the hard core Angular
people, they're like, "Give me my scope back, like, I don't want to give--use--I don't want
to give it up," but most of the people that I've talked to, they really like the syntax.
>> GREEN: Absolutely, that's optional. No one has to use [indistinct]
>> MINAR: ng-if, this actually is something that was already implemented in Angular-UI
project, and people liked it so much that they just threatened us and so that if you
don't include it in core, they will--they'll just leave Angular.
>> GREEN: We gave up. >> MINAR: We gave up. But for a while, we
thought that this feature was not necessary, but then when we thought about it, the way
we implemented it, it allows new things to be done in Angular that were not possible
before. So, what ng-if is it allows you to conditionally enable components in the application
or even template fragments in the applications. So, in this example that I have right here,
we have a clock component that we're using. And we're saying that this clock component
should be enabled only if the--this particular model is true.
>> GREEN: Actually, this is important because sometimes your CSS can get screwed up if you've
got DOM nodes that exist and you don't want them to.
>> MINAR: Yeah, if you're using ng-show, ng-hide, there are some cases when the CSS selectors
might match a wrong thing like with nth child and stuff like that. So ng-show and ng-hide
might not always give you what you need, and ng-if solves--solved this problem. So, on
the demo. [PAUSE] All right, here. So, we have a small application, just as I said,
I have this clock component, and what it does is just prints the current time and will refresh
it every second. I'm going to also open the console because the component will just log
every time it's instantiated, and also, every time it will refresh the timer. So, when I
hit the button, the clock will be--the model that controls ng-if will be set to true, and
what we'll see is that the clock appears here, and we also see that we actually instantiated
new instance of the clock, and then we see how it's refreshing time and every time it
logs, it also refreshes the view. And if I hit the button again, I'm going to disable
this clock, and we see that it's stopped refreshing, so we actually completely killed that clock
component. There's no background work happening. And when I hit the button again, it will actually
recreate--I don't know if you can see it because the font is quite small, but we recreated
a new instance of the clock, and that is now used to display this time. Tangically, ng-if
again, just gives you more possibilities that were harder to do before, and this is one
of them. >> GREEN: All right. So we've got this Expression
Language in Angular that inside your templates, you can do some powerful JavaScript-like things.
But it's not quite JavaScript. But it was--it's not complete, so we've added a couple of things.
>> MINAR: Right. So, we are adding some operators, especially the one--we're adding three operators.
We are adding operators for strict equality and strict non-equality, and also, ternary
operator. This allows you to write expressions that are little more precise than what it
could do before. So, for example, if you have ng-if, and you want to say, "Show this only
if the user is logged in," and the loggedIn has to be true, where true is a string literal
and not just... >> GREEN: Truthy.
>> MINAR: ...Boolean or truthy, then you can just [INDISTINCT] And ternary operator is
useful, for example, in ng-class, where you just want to say, "Depending on this model,
use this like 'user' class or 'anonymous' class on this--on this element," and just
makes the code easier to read and understand. >> GREEN: Again, we demoed some other cool
stuff at Google.IO, but I think it bears repeating. We want to invest more in mobile. A lot of
people have built a lot of mobile apps using Angular without us doing anything special
to support it. There are--there's a bunch of third party libraries that support mobile,
but we thought some things deserved to be in core.
>> MINAR: Yup. So, we're introducing a new model--a new module that we call ngMobile
right now, but I think we will--we'll rename it to ngTouch, just before the release. Because
it really contains only touch-specific stuff, and now, with like Pixel and other devices,
it's not just cell phones and tablets that have touch capabilities. Let's look at the--well,
some of the stuff that you can do. So ng-click is a directive that you know, and it's been
used to capture mouse clicks. But we extended it, so that if you include this module, it
will just become a tap enabled. So then, on devices that allow you to tap or to do gestures
and have tap support, half will just work on any of the ng-click element. We're also
adding in ng-swipe, so you can have swipe gestures in the application. And again, this--we
made this work with mouse, so if your user is using mouse and makes the swipe gesture
with the mouse, it's just going to work. We have some demos, and actually, Jeff back over
there, he built a really sweet application that shows off some of this touch capabilities.
It's a very simple feed reader that allows you to specify your own feeds, and it's just
going to pull them in. But if you--if you have a touch-enabled device, and you just
click on any of the articles, you see some animation and transitions. But also, you can
do stuff, like, swipe to the sides that we have or so, and again like tapping and usual
touch stuff just works. You can check this application and I think he also recorded a
screencast, so he will demonstrate some of--some of these features in the--in the screencast.
Security, who cares about security here? >> GREEN: So...
>> MINAR: Only like ten hands? Come... >> GREEN: Or [INDISTINCT] more should maybe.
We're lucky to be at Google. >> MINAR: Maybe they shouldn't. Maybe we should.
>> GREEN: Well, I think everyone should. I--we're lucky to be at Google. We've--from the beginning
been able to review Angular with the Google security experts, and we do this on a regular
basis, and we've just gone through the latest, like, most forward-thinking about browsers
and web security, then we've got some things to add.
>> MINAR: Right. So, with 1.2, we're adding CSP autodetection. How many of you are familiar
with CSP, Content Security Policy? Really, just like three hands? When you go home, search
Content Security Policy. It's this new feature in browsers that allows you to control what
your application is allowed to do, and by using Content Security Policy, you can greatly
minimize risks of XSS or any kind of attacks that could otherwise easily happen in your
application. And you do this at the browser level, so you don't need to rely on any of
the code or libraries to do this stuff. So, what we are doing with CSP is CSP requires
certain things that--certain configurations that Angular lack. One of--one thing that
you need do is specify ng-csp to unable the CSP mode, but what we did is with 1.2 if the
browser can tell us that CSP is enabled, we will just enable this mode by default, and
Angular will just work, you don't need to worry about it. The other thing that we did
is automatic contextual escaping for images and URLs or links. This is something that
most of you really don't need to worry about, but there are some very weird cases when people
could exploit the application using images in the links. What we did is, we added another
layer of sanitization into Angular that will just prevent any of these attacks by default.
We did also just more security hardening. Like one thing that amazes me is that like
we're becoming--we're getting to a stage where we are hardening things that are like so obscure
that we can't even, like, easily talk about it because it's like, we have to do this and
that, and that, and that, and maybe then they will be exploit. So, like, exploiting Angular
becomes so dramatically hard that it [PAUSE] develop the security in Angular. What about
error messages, however? >> GREEN: Yeah. So, right now, when I get
an error message in Angular, what do I get, Igor?
>> MINAR: Maybe something [PAUSE] Uncaught Error: No module: ngResource.
>> GREEN: So--and what do I do? I'm not sure. >> MINAR: Yeah.
>> GREEN: Maybe search StackOverflow. >> MINAR: Maybe, yeah.
>> GREEN: Could I have something better, maybe? Something more actionable?
>> MINAR: Right. So, we thought about this for quite a bit, and this is one of the things
where the answers is not trivial because we want to provide you good error messages, but
they say at the same by giving you more text, we're increasing the size of Angular, and
as we know quite well from your feedback, you're really sensitive about the size of
Angular, you don't want Angular to be bloated to like, you know, fifty or a hundred kilobytes,
and this is something that we really strive not to do. So, we thought how could we just
give you good error message, for example, like, modules: ngResource is not available,
maybe you misspelled it or you forgot to load it, and even provide you a link to [INDISTINCT]
can read more about this stuff. And do this in a way that would not bloat Angular, and
I think we came up with a pretty good solution, which is if you are using non-minified Angular,
you will get this really nice error message, but if you use Angular in Production, the
minified build, we're actually going to strip all the--all the lengthy strings from Angular
file, and just give you a error code and a link, and you can just pull off the link,
and the link will reconstruct the original message. So, you can actually read it what
it--what it was and take some action on it. This reduces the size of Angular by I think
somewhere between five and ten percent, so it's very nice to see that this is half of...
>> GREEN: Speaking of documentation, we've heard Angular is good, but the docs are may
be unbelievably horrible, and people mean that in the worst possible way.
>> MINAR: I didn't know. I'd like--I meet people, and they're like, "Your docs are so
awesome," and I'm like, "Really?" And then [PAUSE]
>> GREEN: There are some interesting things in it. Like for example, in the--in the Concepts
section, there are maybe five different pages that could be construed as the overview. So,
we actually--we took a survey. Let's go to the next page. We took a survey of like [PAUSE]
thought should be fixed, and we wanted to do this in a very deep way. And the guy who
did the animation stuff, who runs the blog, yearfomoo, Matias.
>> MINAR: Yes. >> GREEN: Is working on a number of improvements,
and this will be rolling out over the next several months, but we wanted to kind of intersperse
things that existing developers would like to see with things for newbies, things for
experts, newbies, etcetera. So, everybody gets some love. Now, we're going to start
off with a bunch of things around. First of all, navigation, search, and just the general
API organization. So, some folk said that they wanted to be able to jump to previous
versions. And so now, we'll have a way that you can just click the dropdown and jump to
whatever version you want, go back in time, whatever version you happen to be using in
your application. Or search, we've got--we also--we already have a couple of search boxes
here, but what we wanted to do is make sure that the one on the top of the APIs is mainly
just a filter, and the one in the upper hand corner, we're going to turn into a full-size
search that works in real time in memory. So, you don't even have to be connected to
the internet if you download one page. So, we'll search across the APIs, the guide, the
tutorial, and any other pieces of the Angular site to find references to whatever you type,
and allow you to get there. And then, as well in terms of API organization, we wanted--we're
going to do some very deep things. So for example, here's the select documentation and
if we scroll down a little bit, we noticed that, okay, we've got some nicer tables now,
[indistinct] to declare the types you can see what it is. But there, if you look in
the current documentation, you see a lot of very big content and so, we have a way to
collapse this so I can easily what's the main concept and if I click on that expression,
it can be set in anyone of these, we get a nice drop-over with more additional detail.
>> MINAR: Right. For example ngOptions it's a beast of it's own. Like there is quite a
lot that you can do with it and just having all the documentation in the select page was
polluting that page. So we just pull it out into this side page.
>> GREEN: Next thing we're working on, and this is--this is very early to show it off.
But, we have all of these concept pages we wanted to pull together into a really good
explanation. And we have this tutorial and tutorial is, I think awesome. [indistinct]
worked on it. It's--it requires you to actually, like, leave the site and download some things
and get going with [INDISTINCT]. We wanted to merge these things together into a full
online experience. Where at the top I can read about all the cool concepts in Angular
and then at the bottom, put them to use and immediately, we can actually see what looks
like an editor and a browser. And if I change anything in it and go ahead and maybe add
some texture and click, we got some things to work out. But, it actually behaves like
a browser. We also have tests so you can actually see how we write tests [indistinct] in our--and
actually see them run in the "Tests" tab. So, this is going to a five step tutorial.
It would be a great introduction for new folks coming to Angular and we really want folks
to--from those five steps understand all the basics.
>> MINAR: If you have a colleague that is starting with Angular, you can just point
him to this tutorial and he'll be able to experiment with Angular in the browser without
even doing anything on the--on the machine. But, if he wants to check out all the code
and work with it locally, he'll have the option to do that as well.
>> GREEN: I'm very excited about that. Okay. All right. Okay. So, what's next--what's next,
Igor? >> MINAR: Well, this was Angular 1.2 or a
stuff that is coming very, very soon and you'll be able to use it. I'm [indistinct] to think
what's beyond 1.2 and we wanted to give you some overview of this so that you also have
an idea of what to expect--what to expect after 1.2.
>> GREEN: Right. So, we've--most of the folks who use Angular, they used it with JavaScript.
Of course, Angular is written in JavaScript. We've also seen folks who used a lot of other
languages. They've used CoffeeScript, of course very popular. TypeScript which adds types
and it's, you know, very close to ECMAScript 6 type standard. Even folks doing what might
be construed as crazier stuff in the Closure script world. There was one script--there
was one scripting language that we wanted to add support for, but we didn't think the
Community could do and we actually have a big project using at Goggle. So we were going
to add support for the DART language. Who knows what DART is? A couple folks. Oh, lot
of friends. Okay, good. So, we could go to their site. If you're not familiar, DART adds
optional types to JavaScript. They're working heavily on performance. It's the same team
who built the V8 JavaScript engine, so they know a thing or two about performance. It
adds a lot of other nice, interesting bits. Like they have promises built into language
itself. So what we're doing, let's go back to the slides, is we're building a version
of Angular that's a port onto DART. And they're not going to share the same code, though we
want to keep them conceptually similar so that they feel like the same thing. If I know
the JavaScript version, I should be able to work on the DART version very easily. And
we think the templates will probably always be the same and we want to align various things.
But like I mentioned, DART already has promises, we didn't need to port that yet. So there
will be differences, we're not going to commit to the actual code being the same. So where
we are right now, we have a bunch of the core components like, $compiler, $scope, expressions
already working in DART. We've done some basic directives like ngBind and ngRepeat. And we're
porting other critical bits like Dependency Injection and Routes and you can start seeing
some of these pieces. We've also made testing easy. We've made Karma the test runner work
with DART. So, these pieces are coming together. The status is, it's not really ready to play
with unless you're really desperate, but we are using this on an internal project or we're
actually, we're going to start using an internal project next week, so it'll start coming together
quickly. >> MINAR: Right. And just to make it--this
absolutely clear, we're not dropping the JavaScript support. We love JavaScript. We are very passionate
about JavaScript. This is just another option for people who like DART and like using DART.
There are project at Google that being built with DART and they want Angular. But there
are also projects that are build with JavaScript at Google and they want Angular. So, we thought
about, you know, how could we help both of these groups of people at Google and the easiest
answer that we could come up with was--you know, was just support Angular to DART. Let's
expand the Angular team. The original Angular JavaScript was really built with just three
guys. >> GREEN: That's right.
>> MINAR: Now, we have quite a bit more than that.
>> GREEN: We have--well, six full-time folks and three folks externally doing full-time.
>> MINAR: Right. So we expanded the team, we invested into the Angular team and we're
going to do both DART and--both Angular and DART and JavaScript and it's going to be option
to choose which one you want to use. >> GREEN: Right. So let's talk about what's
coming down for the full Angular [indistinct] JS.
>> MINAR: Right. So, when we're talking about Angular Next, it's really, you know, JavaScript
and DART. The overall theme is the same for both. It's going to be based on standards.
When we started with Angular four years ago, many of the standards that are in browser
today or many of the APIs that are in browsers today, didn't exist. Some of--some of the
examples of those are Object.observe() which allows us to do very performant checking of
the model mutations. The other one is DOM Mutation Observers (DMO) just a way of browser
telling us, "Hey, there was a new element added to the page or to document."
element, an awesome element that allows us to avoid many of the hacks that we have to
do with Angular today because we don't have an element that would be...
>> GREEN: A good place holder for... >> MINAR: Yeah, a good place holder and would
not cause, like, script loading or image loading and any [indistinct] of stuff. Shadow DOM
is like probably the best API of all of these. It allows you to isolate DOM fragments and
like create real true encapsulation within DOM. All of these are really come under the
umbrella of Web Components and Model Drive Views (MDV) and these are the standard that
we want to build the next Angular on top of. This is going to come after Angular 1.2 and
it's going to take some time, but this is the direction that we are taking. You might
ask--you might wonder about backwards compatibility. With existing browsers, we're going to use
the strategy of polyfills and transpilers. This is--this is something that's becoming
more and more popular and I think it's the best the option how to push the web over and
this is what we are going to do. >> GREEN: Right. So, Angular right now is
mostly one big piece in the core, but we started to split some things out, right?
>> MINAR: Right. So Angular is--you know, when we started with Angular, it was just
one thing, it was AngularJS and it was composed of many different pieces, like $location,
$compile, $parse and many other services that you use probably on a daily basis. There are
also [indistinct] filters and repeaters and directives, and many, many other pieces. And
as we were building Angular and adding more features, unless you were asking for more
features, we actually outgrown AngularJS and we started building like these modules, angular-resource,
angular-route, angular-sanitize and many others. This strategy has worked for a--for some time,
but we feel like Angular is--the core is still becoming bigger and bigger. And really, the
best way to deal with this thing is what if we just took all these pieces and just created
them as separate projects. So, we could--we could just have $location which is really
just a generic wrapper around navigation within the browser. $http is just the wrapper around
http. It doesn't really--there are very--there's very little that is Angular specific about
this thing. And if you wanted to you should be able to use these pieces outside of Angular
ecosystem and I think this is very good thing. Let's take dependency injection as an example.
Like many people want to use the dependency injection after they saw it working in Angular
and they want to use it in Node. But, they can't use the one in Angular because it's
part of Angular and, like, you can't rip it out. Well, we'll rip out for you. We'll just
take it out. We'll make it completely agnostic with Angular and you can use it in Angular
or you can use it in your Node application if you choose to. This allows you to build
Angular that you need, own and have only those pieces that you need in your application.
And it also allows you to just take the pieces for Angular and mix them with other pieces
of different frameworks or different platforms like Node.
>> GREEN: What if I want the old Angular? >> MINAR: If you want this--the old Angular,
we're going to create it for you. It's just gonna be a meta module that just has dependencies
on the oldest small modules [indistinct]. Then we'll use tools like Bower and Grunt
to just make it easy and very seamless, to just pulling the pieces you need and build
the Angular that you need. We also hope that by doing this, we're going decentralize the
project. We already see that it's really hard for us to scale. Like, if you look at our
issue tracker or pull request, it's becoming quite hard to just, you know, keep organizing
the project in the--in the way we've been doing. By decentralizing Angular into smaller
projects, this is going to become much easier, it's going to be much easier to delegate responsibilities.
But again, you still have the good old Angular. [indistinct], when you look at the micro frameworks,
like, micro libraries, this is--this is not a new approach. It's just many people have
tried it from the other end, where they tried to build many small pieces and then have them
work together. But doing it in this way you'll end up, like, when you just try to combine
all these small pieces, it's really hard. But what we are doing, we're taking something
that works together really well, we're just going to break it up into pieces that can
or might not live on its own. So it's very easy to just create Angular back into single
piece. And the last thing... >> GREEN: One more piece, yes?
>> MINAR: The last thing... >> GREEN: Something you're endure to our hearts,
it's testing. >> MINAR: Yeah. We really care about testing.
We probably know all about that. And well, we are super happy about the state of unit
testing in Angular applications. We are not as excited about how the end-to-end testing
in Angular application has turned out. We have a solution called Angular Scenario Runner,
which has some really awesome features and one of--one of the best one is this tight
integration between the test runner and the application framework so that the two can
just collaborate and can make writing tests easy. But, the current implementation in the
Angular Scenario Runner is based on iframes and there are many things that you can do
with this approach. For example, it's very hard to simulate touch events or any kind
of, like native events that happen in the browser. So we are--we are doing--we're creating
a new project called Protractor. >> GREEN: It's to find the right angle.
>> MINAR: Yeah, to find the right angles in the application. Julie is a awesome engineer
from Seattle who's working on this project. And this project is already out there on GitHub.
It's in reasonably good shape. Well, we are actually starting to migrate all of our end-to-end
tests that we use to test Angular to use Protractor. So, it's definitely ready to be checked out
and Julie is looking for more feedback. >> GREEN: We'll have Julie come down here
for a meet-up some time in the future. >> MINAR: Right. So, what is Protractor? Protractor
has the same great integration with Angular. So, many of the things like if you're dealing
with Selenium test, you have to do this polling or you have to check, "Is my application ready
for insertions?" This just doesn't exist in Protractor, just like it didn't exist in Scenario
Runner. But it's based on WebDriver. WebDriver is--this project that allows you to have full
control over the browser. It allows you to emulate events, control the screen size and
many things that you just couldn't do using iframes. This is definitely a project you
should check out and we're gonna slowly migrating all of our tutorials and all of our end-to-end
test suites to this solution. >> GREEN: Pretty cool. Here's the link to
the slides and we will take questions. So, Canon Misko have--where's Misko? [indistinct]
--oh, yeah, there he is. >> MINAR: Yeah, can you just come in here?
>> GREEN: Yeah. So, if you could guys come to the aisle--just ask. [indistinct] and use
your feet to walk and Misko or Ken will hand you a mic. Come on up, anybody, form a line.
Both aisles. Maybe over here first. Yeah, sure.
>> So, I'm interested in the browsers that you tested against with transitions and stuff
with the animation. >> MINAR: Misko, maybe you can...
>> MISKO: So, this is just a standard, you know, continuous integration suite we have
and tests... >> MINAR: We test IE8[indistinct]...
>> With 8, 9,10? >> MINAR: ...Firefox, Chrome--yeah.
>> MISKO: Safari, Firefox, Chrome? >> MINAR: [indistinct] browsers and Android
browser. But really, what we are just doing the animations themselves are defined through
CSS or JavaScript. This is not part of Angular and this is the part where you need to make
sure that this things are cross-browser compatible. But again, you can leverage existing CSS libraries
to do this stuff. >> GREEN: Well, over here.
>> Hello--oh, there you go. So, I'm just wondering, you guys introduced a lot of stuff today,
especially, you obviously Angular 1.2, but also the revamped website. I'm sort of in
the middle of teaching some people on my company, how to use Angular. And I'm just wondering
that--the new website with the new search and all of that, I know Angular 1.2, I don't
know when the deadline--release date for that to you. But, the website itself would be super
great to have really soon. >> GREEN: Okay. Yeah.
>> MINAR: With the release candidate, you'll get most of the--looking from the enhancements.
The site is already--if you go--if you go to, like, code AngularJS and look for the
documentation that is specific to the latest unstable releases, you'll see most of these
enhancements already out there and we're just merging these changes as they are ready.
>> GREEN: The five-step tutorial is going to take a couple more weeks. Yeah.
>> First of all, huge thanks for actually revamping the documentation.
>> GREEN: All right. Okay. >> The question I actually have here, as you
guys mentioned that there's going to be, like, different versions of Angular that you could
swap in and out for like by the error messages. And like--I've been using CDN-hosted version
and build the version that you can swap out over the error message, will that also actually
CDN-hosted available? >> GREEN: Yeah. So this is just the minified
version. We'll have those little error messages with a link to the doc and the un-minified
version will have the full error massages. Same stuff you already use.
>> Yeah. >> MINAR: One thing I see quite a bit which
is a little bit unfortunate on JSFiddle or Plunker people are building all these examples
with minified version of Angular. Then, when you look at the console and, like, they send
us, "Oh, there is this bug and I start debugging and I'm getting very weird stack traces,"
and it's because you're using the minified version of Angular. Like, whenever you develop,
you really should be developing with the non-minified version of angular. It makes it so much better.
>> GREEN: Over here. >> One of the things we always run into, I
think you kind of partially address now is that--using--well, you always had resolve,
so, like, using a resolve to load the data before your controller dose. But we always
have that from with directives. So directives try to, like, render and the data is not there
yet, so we end up having to like do a bunch of watches and wait for promises to resolve,
then render the data in the directive. So, I'm thinking now is the proper way to do that
using ng-if on the directive to say that, when the promises resolved then render the
directive? >> MINAR: It's one of the use cases, you could
use it definitely in that way. But if you have access to the promise, like, the easiest
thing is just wait for the promise to be resolved and then do stuff.
>> My second question is about lazy loading of, like, modules. Is that in the plan?
>> MINAR: Right. That's a very good question. And--or actually something we didn't have
time to discuss. There is a project that is actually in works with these awesome guys
from Utah. They are integrating RequireJS with Angular so that it just works. We know
how to do it now and we're going to get rid of Angular modules in case we are using RequireJS.
This is something we are trying to back-port to existing Angular and I think that it will
just work. We should have an update on this very soon, so just watch out on Twitter or
Google+ and we'll give you update. >> GREEN: Yeah. Oh, over here, yeah?
>> I know you mentioned using Bower and Grunt to manage Angular modules, I mean, before,
I was wondering if you're gonna expand on the Yeoman/Angular Integration so far and
what the future of that would be? >> MINAR: Yes. So, Bryan Ford is the guy who
created the existing generators. He's joining our team next week. I can't wait. So he's
gonna be working full-time with us starting tomorrow--starting next week on--in Yeoman
and Bower and Grunt, all these things. This is something he's really passionate about
and he's going to keep on enhancing those. Is there's something particular you would
like to see or... >> [INDISTINCT]
>> MINAR: Yeah. Well, definitely we think that Yeoman is a cool project and it helps
a lot developers get started, so we want to invest in more of that.
>> GREEN: Yeah. >> So, for the great on Angular, there's another
Google JavaScript framework called Polymer and it's seems like it has a lot of commonalities
with Angular. I was wondering if you could discuss some differences and similarities.
>> GREEN: Yeah. >> MINAR: Polymer is a project that really
pushes the web forward. It's a project that tries to imagine what the standard APIs or
tries polyfill existing standards that are not implemented yet in browsers and you use
those and provide a way for developers to start using these APIs before they are implemented
in browsers. As you mentioned, yes, there are some polyfill--or there is--there is some
overlap. We are working with polyfill or Polymer team. We are all passionate about the future
of the web, web performance and the modular reviews and we just want to work together
on making this better. >> GREEN: Over here, Dean.
>> DEAN: Yeah. I was wondering with the new Docs site, there's a feature I've been requesting
for a while now. Is it going to be URL searchable so I can use Google Chrome search browser
engines and put it in to my IRC bot? >> GREEN: It's a good question. I don't--I
don't think it's on our list, but it could be.
>> DEAN: Isn't it already URL searchable? >> No, I want to type a search query into
the URL [INDISTINCT] results, right now, I have to know the URL of every page. Do you
want me to repeat it? >> GREEN: Yeah. Go ahead and repeat it and
I'll talk--I'll chat with Matias about it. Yeah?
>> DEAN: I'd like to able to have like ?q= some random search query and it gives me search
results. Right now, I have to know every specific URL and it would be nice if I can just, you
know, do Google site search or... >> GREEN: I got you. It's a good request.
>> MINAR: Okay. Yeah, yeah, yeah. >> GREEN: Good request.
>> MINAR: We could totally do that. >> Okay. Thanks, guys. I have two newbie questions
actually. Ng-if, so that'll actually remove the DOM element?
>> GREEN: That's right. >> MINAR: Yes.
>> About the... >> GREEN: Versus ng-show or hide which just...
>> Right, that's it. That was a good one. >> GREEN:...that changes the CSS on it.
>> [INDISTINCT], so thank you for that. And $http synchronous, I can do that or [INDISTINCT]
>> MINAR: $http is synchronous, asynchronous. Yeah?
>> I'm just wondering if I could do synchronous [INDISTINCT]
>> MINAR: No. You can't and you really should never do that.
>> Kind of--kind of some other question about Polymer a second ago, are you going to be
doing polyfills for things like Shadow DOM in Angular 2?
>> MINAR: Our team already built most of these polyfills...
>> Right. >> MINAR: ...and were going to...
>> So... >> ...use those and we're going to help them
enhance them if needed. Yeah, this is going to be really a collaboration between the two
teams. >> And so, you'll bake it into Angular 2?
use their things. >> Okay.
>> MINAR: So we're actually going to share some of the stuff. Like it's really hard to
tell what's going to happen in the long term, but we already see signs, like, sharing stuff
between the two projects and I think that's the right direction to go. Like, we're going
to take their polyfills, they like our syntax and our parser--the expression parser. So,
we are--we are working on many of these things and see, you know, how we can just trade things
or work on things together. And like breaking up Angular into small pieces will even help
with this. >> GREEN: Yeah, right here.
>> Hi. My question is for Angular on Dart. Will you have any migration part if I have
existing project on AngularJS and if I want to migrate? And how easy or how hard it would
be to migrate? And what benefits I would get compared to my AngularJS versus Angular on
DART? >> MINAR: We can't--we're talking about Angular
1.0 versus 1.2, right? >> GREEN: So it mean--just a couple of things to think about. So DART
is still a developing standard or language. They're going to--they're shooting for their
1.0, so it's a little earlier than JavaScript is. But some of the--some of the things you
get out of it is, it sense a typed language, and you can put some types on, so they're
optional. You get better syntax highlighting, command completion, figure out where the references
are, so your IDE can actually do a lot more for you. They have--they have some benchmarks
that show them actually performing very well, particularly on initial load time and then
some of the execution speed over JavaScript. But we haven't--we haven't yet seen applications
written in it. This is one of the things one of my other teams is working on. I've got
about 60 folks who are working on the largest application for Google. So some of it's yet
to be seen. But--I don't know. Igor, you want to add something?
>> MINAR: Yeah, it's really too early to tell like--we open-sourced Angular DART just so
that the community can see what is happening, what we are working on. And there are people
who have been asking for that DART support for a long time and, you know, this is our
answer. Like, if you're really passionate about DART you can watch this project, you
can--you can contribute. It's definitely not ready to be used today. It's going to take
some time. We want to build this internal application with this Angular that is evolving
in DART and see how things work out. And once we are confident that we got the DART implementation
right, then we'll call that stable version that people can use. But, with DART itself
being a moving target, it's really hard to discuss these things. Like, you really have
to be a passionate developer and like bleeding edge code and that's--then you can look at
this project. >> GREEN: We'll keep you updated. Yeah. Over
here. >> Yeah, I just want to do say thanks to the
Angular team and just let you know how awesome I think Angular is, so great job. It's...
>> GREEN: Thank you. >> ...it's fantastic.
>> GREEN: Thanks for being a fan. >> And my question is, so if you have--let's
say a fairly large application, you've already written in Angular 1.1.4 or 1.1.6 or whatever,
and you want to just throw in 1.2, is there any particular pain points or things you need
to watch out for to migrate it or to be fairly seamless or is there anything to...
>> GREEN: A couple of breaking changes. >> ...consider?
>> GREEN: ...there's nothing. >> MINAR: There are a few breaking changes.
We're going to document them all. We actually have been documenting these as we've been--we
were making them. So probably the biggest one, if you're using $resource, the promise-based
API changed few things, but it's not [INDISTINCT] backward-compatible. It's only vertically
use cases that you need to watch out for and we'll document these. Other than that, the
breaking changes have been relatively small and well-documented.
>> Actually--let me just add something to it. 1.1.4 is essentially what will become
1.2, right? At some point, we're going to, just basically say--instead of 1.1 [INDISTINCT]
which is going to declare 1.2. So as long as you keep up with the 1.1 releases, at some
point, we'll match what become 1.2. So as long as you can keep up with the 1.1 releases
at some point [INDISTINCT] that will become 1.2
>> Two more quick questions. I'm--again, bringing data into the Angular world, I'm finding myself
having to--and so I'm running into that digest issue, digest is already running and I--my
solution is always been to do $scope.$$phase to see if that digest is running and then
do an $apply if I need it, you know, because that's the only way I can find to solve that
problem. So is that the right way to do it? >> MINAR: No. That's the worst where you can
handle the situation. And the reason why I'm laughing is because we had a really passionate
discussion about this with Misko yesterday where I was proposing a fix for this and he
was explaining to me how stupid I was and that it would never work. And can you talk
to us afterwards and just we can look at the code and just show you. But, really, Misko,
do you wan to summarize what we--what we ended up.
>> MISKO: So, what you're basically doing over there is--I don't know how to summarize
this. You're setting yourself, so--let me back up a second. You have this non-Angular
world and you have this Angular world, right, and you crossed the--from a non-Angular world
into the Angular world by calling apply which then determinably closest to digest.
>> MINAR: Most of the time, this happens automatically when you use like ng-click or $http, like
this crossing of this boundary just happens before you don't know about it.
>> MISKO: Okay. And so it's very important that you keep your code always on one side
of the boundary. Either, it's always outside or always inside. And whenever I hear people
doing something like this, what it means is that you have coded it sometimes inside and
sometimes outside. And the trouble is that the rules about how the system behaves are
different between those two places, and so the chances of you getting the code right
in both cases, is very hard. It sets you up, basically, for failure when it comes to testing
because your test will pretty much not work and there's a couple of other issues with
that. So... >> GREEN: But, what should he do?
>> MISKO: Well, so I will--[INDISTINCT] and Igor has a slightly different opinion. Is
that whenever you run into this issue, it's a sign that something is amiss in your--it's
a programming error really. So something, somewhere, made a wrong assumption. The same
piece of code cannot be running both inside and outside of Angular.
>> Okay. I mean, it's just when I'm the calling the Facebook API and trying to bring data
back. >> MISKO: Right. So, that gives us the next
points. So--why did you get yourself into this trouble? And the usual answer is you're
calling an API such as a flash, or third party address, such as Facebook which doesn't have--doesn't
follow this simple principle that if you have an API that's async, it needs to be always
async. And if it's sync, it needs to be always sync. But the flash and--it sounds like Facebook
what they sometimes do is they sometimes call you sync and sometimes call you async and
this gets you to trouble, because if they call you sync and you're already in apply,
then, you know, you just continue being instead of apply. But then when they call you async,
then all of a sudden, you're not in apply. And so, it's really a third party mistake
that's then--gets manifested by us and then everybody kind of puts the finger to us. But
we don't actually know a good way of solving this. We're struggling with this and debating
this. >> MINAR: Maybe you catch after...
>> MISKO: But--I like the [INDISTINCT] maybe we can learn something from it.
>> MINAR: ...but if we look at the actual code...
>> All right. >> MINAR: ...because we want to see examples
of this, like, we looked at some of the examples, a few people were discussing...
>> All right, I'll catch up with you later. >> MINAR: Okay.
>> Second question was about UI-Router state manager. Is that--I think you said that you're
going to talk about it, but I don't know if you did, actually.
>> GREEN: We did. We--the thing we actually broke out our router and we added some things
to it, but it's not a state manager, like, the UI-Router.
>> MINAR: We don't--we don't plan to introduce state-based routing into the existing router
just yet, like it's too big of a change. But by making a simple move of just picking the
existing router out of the Angular core, we are preparing us for the future where we could
either adopt UI-Router or work for the team and, like, rebuild something that would become
part of Angular... >> GREEN: It's a good project. So the first
step is we're going to take ours out, so if you want to use that one, you're not paying
the extra bytes for ours. One over here. >> Hi there. I had a quick question. I love
the ng-animation. I want to see any supports or anything could be plan for HTML5 Canvas
Base64, anything in that aspect. >> GREEN: That actually kind of outside the
realm of Angular, I think. But Misko made sense.
>> MISKO: It's not--that's... >> GREEN: Can you mention a particular in
use case? >> Yeah, the new--the new animation was really
great. So, with that, there's a lot of things that Windows animation it would be a lot of
things with the Canvas, for example, that would be great. Or play Base64 animation with
the images... >> GREEN: So you can do animation inside canvases
and there's lots of great libraries for that that you could use with Angular. But Angular
is about manipulating DOM, and Canvas is a big area that you can manipulate inside the
DOM that's kind of a way to punch a hole in it.
>> Lot of HTML5 [INDISTINCT] >> GREEN: Oh, yeah, yeah. For all the HTML5
DOM components, like all of the animation stuff.
>> MISKO: So what you can do is--Angular works on a concept of adding or removing a class
and the class may trigger animation. But in your case, what you can do, is you can actually
take advantage of the polyfill. So for example, in the browsers that don't have CSS animations,
adding or removing classes is a no-op, but you can register a JavaScript function which
gets triggered when this class gets added. And then you can use that to execute any JavaScript
you want and including canvas animation. >> GREEN: Sure. Over there.
>> Yeah. There's a lot of new features that were introduced tonight. And so, I guess I
have a question, it's an A and a B. So, the A part is, are you guys affiliated with the
Batarang, like Chrome Extension. And if so, is there any, like, new changes coming to
that? >> MINAR: Yes, Brian Ford...
>> GREEN: Brian Ford. >> MINAR: ...joining us on Monday. Brian Ford...
>> GREEN: Wrote the Batarang. >> MINAR: Batarang was Brian's intern project
for last summer. He was my intern last summer and during the summer internship, he developed
the Batarang. And then he continued working on it during the school year. He finished
his school and he's coming next week. So this is definitely something that we are interested
in supporting, and it's just going to be part of Angular.
>> GREEN: Are you looking for something particular? Just more better.
>> MINAR: More better. >> GREEN: Okay, got it. We will more better
it. Over here. >> Do you have any prescriptive guidance for
using Angular in real-time applications scenarios? >> GREEN: Maybe Misko.
>> MISKO: You mean like socket.i.o? >> Any kind of app where there are multiple
users simultaneously, you know, and there's a lot of visualization going on, real-time
updates across browsers. >> MISKO: So there have been a couple of demos
where you could use socket.i.o and essentially, you just have to wrap any event that the underlying
layer provides you for real-time, you just have to wrap in the $watch--I'm sorry, the
$apply. And then you could just have--you could have essentially kind of shared canvas.
What was it? >> MINAR: Firebase.
>> MISKO: Firebase is a database that's real-time and they--or actually already provide an API
to Angular which essentially creates sync objects across multiple browsers. So you get
a different--you get the same object basically in multiple users and then as we modify that
object from any location, it gets synced across to the other browsers as well.
>> GREEN: We're also--Jeff Cross running the video board tonight, but his day job is working
at Angular. He's actually thinking about this and the future of Angular, maybe grab him
after we're done. >> MINAR: And if you're--if you're looking
for particular applications that are already uses this stuff, Plunker is built with Angular
and it has a collaborative feature which is based on WebSockets and stuff. And they do
most of the stuff that we mention here. [INDISTINCT] >> GREEN: And one last over here and then
we'll call it quits. >> Yeah. This is a pretty specific request.
In directives, would it be possible to pass a function to templateUrl, like add some logic
behind. >> GREEN: Done.
>> MISKO: It's already done, isn't it? >> Oh, really? Okay.
>> MINAR: And we didn't mention it, it's part of 1.2. This is--like, there are many things...
>> GREEN: You're welcome. >> MINAR: ...that we didn't have time to mention.
>> GREEN: Yeah. Oh, okay, one more. >> So, thank you for all the work on Angular.
We are really enjoying it after a lot of hair-pulling experiences as we got started with it. But
one question that I have for you, Igor. I know you posted something on Angular-gesture
directive, that's somebody had written. Is that what the ng-animation is based off of
or is it totally different? I know that's written HammerJS and...
>> GREEN: So the HammerJS wrapper for Angular was written by guy who works for Volkswagen...
>> Okay. >> GREEN: ...and it's not affiliated with
Angular. It's not what we based our tech support on. HammerJS is a great library and if you
can't wait for the rest of our touch-based stuff, it's a good option. But we're actually
building the touch-based piece in to the core of Angular.
>> That is [INDISTINCT] >> GREEN: Cool. All right, everybody, thank
you so much. If you haven't signed a--if you actually asked a question and haven't signed
the release, place secrecy in the back. We will be around for a little while later and
feel free to come up and chat with us. Thank you so much.