Devoxx 2012: AngularJS

MALE SPEAKER: OK, so we're here at Devoxx, and I'm here
with Igor and Misko from AngularJS.
And AngularJS, for those who've never
heard of it, is a new--
can we call it a JavaScript framework?
MISKO HEVERY: Sure.
MALE SPEAKER: Are you offended?
IGOR MINAR: That's the closest--
MALE SPEAKER: That's the closest.
But you have a different take on things.
You like things that are declarative, right?
MISKO HEVERY: Yes.
I like to think of it as what a browser would have been, had
it been designed for web applications.
MALE SPEAKER: And you don't like to deal with the DOM, or
you think other frameworks, maybe, are obstructing away
and hacking the web and browsers, and you're trying to
be more true to, maybe, HTML?
MISKO HEVERY: Yes.
A lot of frameworks take the approach that DOM and HTML and
CSS is complicated stuff-- even sometimes the Javascript.
And so they try to hide it from the user.
And so we're kind of unique in that we're saying, no, no, no,
we're just going to embrace it, and we're just going to
see if we can monkey back some of the
efficiencies to make it better.
MALE SPEAKER: So do you want to talk about data binding and
templating and how that helps?
IGOR MINAR: So in angular applications, we see that the
biggest benefit you get from using Angular is this declare
templating.
In Angular, you don't do imperative DOM manipulation
just anywhere in your application like are common in
JQuery applications.
In Angular application, you have a model.
This model is something domain specific to your application,
and this model drives the view, and it drives it in a
way that you take this template, and you declare to
specify where this model binds to the template, and you let
the templating figure out how to take the model and push it
through this template and render the view and keep the
model and the view in sync at all times.
MALE SPEAKER: Right.
So this is bidirectional.
IGOR MINAR: Yeah.
So it's bidirectional.
If you have input fields, we actually take the user input,
and we push it to the model back.
If you have just single binding, we take whatever
changes happen to the model and update the view for you
automatically.
MALE SPEAKER: So something else I understand about
AngularJS is the dependency injection being built in,
which is a term obviously that means a lot to, say, Java
developers.
Can you elaborate on that, and does that even make sense for
Java and for the web?
And is it about testability?
IGOR MINAR: So testability is one reason why we embrace
dependence injection, but in general, we find that
dependence injection just gives you these guidelines on
how we should just structure the application into smaller
components, and then have dependencies between
components that are automatically resolved when
any of the components need to be instantiated.
So not only dependence injection helps you with
testability, it helps you just making the application easier
to understand and write and maintain.
MALE SPEAKER: And maintain, yeah.
You mentioned components.
What was the component story in AngularJS?
Do you build components?
Custom components?
MISKO HEVERY: We basically were trying to follow the web
components story.
MALE SPEAKER: You want to say what components are first?
MISKO HEVERY: Web components is the new standard that's
coming from the W3C, where they're recognizing the need,
if you're building an application, that the divs and
spans is not what you want, rather you want this reusable
stuff like tabs and control panels and so on.
IGOR MINAR: We basically want higher level abstraction.
So you want to build abstractions from this small
li span, or whatever you have, and just create component that
would just say, oh, this is a tab, or this is a Google map,
or any other component that you might have that is
internally structured from this low level DOM element.
MALE SPEAKER: Right.
And Angular, how does that translate?
IGOR MINAR: So with Angular, we allow you to build these
reusable components today.
We use existing domain PIs in JavaScript, which is not as
powerful as what you can do with changes
to the native APIs.
And our story is, let's start building these reusable
components today, and pretend that we already have this low
level native APIs for building components.
And when the web component specification is done, it's
going to align really well, because it will allow you to
build the same kind of components,
but with native APIs.
MISKO HEVERY: What I want to add to it is, really, what
we're trying to do is we want to turn HTML into a
declarative DSL-- a domain specific language, where if
you're building an application that has a lot of panes and
panels and a calendar thing, then you want to have a
vocabulary that's useful for building that application.
MALE SPEAKER: OK.
So I have my components, I have my views, my--
how do I wire up the back end?
How do you get the data from your friends producing and
managing the data source?
MISKO HEVERY: So we're trying to be server side agnostic.
So there's no server side component.
That means that as long as the server is producing JSON and
something that [INAUDIBLE].
IGOR MINAR: Or XML.
MISKO HEVERY: Or XML.
IGOR MINAR: Doesn't matter.
Like, if there's a way how you can get data from the server
to the client, then we can just use this.
If this is done through HTTP, if it's done through web
sockets, if the encoding is JSON or XML, we don't care.
We provide you some helpers, so for HTTP and RESTful
backends, we give you some support to how you can
communicate.
But we really think that there are such a variety of backends
out there that it doesn't really make sense for us to be
tied to only one specific backend.
We should be able to use anything.
One thing that is really interesting for me is that
there are new approaches of solving the backend.
For example, MeteorJS completely says, REST doesn't
work for applications that we're building
today on the web.
We need to rethink how we deliver data to the browser.
And integration between AngularJS and Meteor is
something that we are discussing right now.
MALE SPEAKER: OK.
So for a developer looking into trying out AngularJS,
what does the tool chain look like?
What are the tools you recommend?
Do you recommend any?
I mean, this is the web, this is editing.
MISKO HEVERY: Tool number one, browser.
MALE SPEAKER: This is declarative stuff.
IGOR MINAR: You need a browser.
MALE SPEAKER: You need a browser, right.
But do you need the full blown IDEs that--
IGOR MINAR: No, not really.
Because most of the editors today have support for HTML,
so they can do syntax highlighting, they can do all
the completion for HTML.
And Angular is really just HTML extended, and
JavaScript, of course.
So if you have an editor that is suitable for web design and
just simple web development, then it's suitable for
AngularJS development.
There are some IDEs that are better.
For example, Web Store currently has the best support
for AngularJS, but there are other IDEs that--
MISKO HEVERY: Better support, just to be clear.
IGOR MINAR: So this means auto completion of Angular specific
attributes.
It also means maybe just pre-generating
templates for you.
So if you have some component that has well known structure,
it can just pre-generate the code for you.
What else am I missing?
Testing--
running tests with Angular.
So Angular's really--
we like to tell people that they really should test drive
their applications, and IDE can help there.
So having a good integration with
test runners is important.
MALE SPEAKER: You have integration with Chrome dev
tools as well for debugging purposes?
IGOR MINAR: For debugging purposes, Chrome is amazing,
because it helps us see what the application
looks like at runtime.
And the debugging tools in Chrome are really pretty good.
You can debug JavaScript, you can debug the element and you
can look at the DOM and see what state it is in.
But we thought it could be better, so we actually created
an extension for the Web Inspector
that you see in Chrome.
And with this extension, you can visualize what the
application structure looks like, what is the current
model state, what is the state of the dependence injector,
and all the dependencies in my system.
MALE SPEAKER: Very nice.
So I obviously have written some JavaScript already.
I have pages, I'm using probably some frameworks.
Does Angular play well with those frameworks, or do I need
to rip everything off?
MISKO HEVERY: You know, that's something that I feel very
strongly about.
I think one of the successes of JQuery was that you didn't
have to subscribe to the whole thing.
You could just say, I want to start using JQuery in this
little tiny portion of the page, and then I
grow as I like it.
And so we structured this Angular in the same exact way,
where you can just sprinkle as little of it or as much of it
as you want.
You can even use it with a round trip application, and
then later on think about how you turn the round trip
application into a single page Ajax application.
MALE SPEAKER: OK.
And the dependencies, how big are they?
I mean, are you dragging along like, big libraries, or--
MISKO HEVERY: No, so Angular is about the size of JQuery.
A little smaller.
[INTERPOSING VOICES]
IGOR MINAR: It's much smaller.
MISKO HEVERY: It's much smaller?
IGOR MINAR: Yeah, it's much smaller.
[INTERPOSING VOICES]
IGOR MINAR: So Angular itself is 29K right now, when it's
[INAUDIBLE].
We have some plans to make it even smaller, but really, 29K
is not that big.
It's a small image.
So I think we're doing quite well there.
Like, we try to keep the core of the framework small, and
then if there are some functionalities that we see
that people use, but not all the time, then that should be
a separate module that you can load if you want to.
And often this brings up the question of what about
components?
Like, are there components that the
framework brings and contains?
And the answer is no.
We wanted to build the core of the framework very small, and
we wanted to make it possible to build all these components
on top of Angular.
So one of the design tools of Angular is everything should
be extensible.
So when you look at all these custom attributes that Angular
created, like ng-repeat, ng-show, all of this stuff is
built on the APIs that are available to all the
developers.
So if you actually don't like all of our custom directives,
you can just throw them away and build your own, and just
use the HTML templating core and the dependence injector.
MALE SPEAKER: So where should people go to find out more
about AngularJS?
IGOR MINAR: AngularJS.org.
MALE SPEAKER: Dot org?
That's probably a good place
MISKO HEVERY: There's also this search
engine called Google.
MALE SPEAKER: Yeah.
MISKO HEVERY: It's pretty good.
MALE SPEAKER: Does it work?
That's awesome.
Well, thanks, guys, for being here.
IGOR MINAR: Thank you for having us.
MISKO HEVERY: Thanks for having us.
MALE SPEAKER: Thank you.