>> Lars Liden: Okay. I'd like to introduce Cory Forsyth. He's an adjunct faculty from the ITP
program at NYU. He's also an expert at Ember.js. He helped out the FUSE Labs group at MSR
with some work that we were doing over in New York City with Katie London and he's come
here today to share some of his knowledge about energy Ember.js. Thank you. Cory.
>> Cory Forsyth: Nice to meet you all. My name is Cory Forsyth. I'm bantic on Twitter. I run a
consulting firm in New York called 201-created. Anyone have an idea why we are called the?
>>: Area code.
>> Cory Forsyth: That would be Jersey, which is very close. It's the HTTP static code for
creating a new object. We use it sort of like a little litmus tests sometimes for our clients. If
they can figure it out, then we know we can work with them. As Lars said we used to be called
404, but that just didn't work out. I'm going to talk about single page applications, sort of go
over a little bit like what they are, why they are popular now, what they do and why we build
them. And then specifically talk about my tool of choice, Ember.js for creating single page apps
and what it provides us and then I'm going to show a little bit about the project that we worked
on with FUSE Labs to make an Ember application in Microsoft here. Single page applications,
sometimes abbreviated SPAs. I've had people talk to me about this and it always surprised me
until I figured out what it meant last year. They are, let's see. What is a single page application
exactly? How does it differ from the other typical sort of like a browser experience that we
have had for most of the time that we have had browsers in the web is like a common
response. Server, we make a request and sends off some data or a request to the server.
Server does a little bit of processing and sends back like a full-page that is very much like a page
by page experience. We are sort of moving now into a new mode of being I think on the web.
The primary part about single page apps is that the single page part refers to the fact we are
now able to build up our applications that don't rely on page reloads, full-page reloads before.
It's more of a sort of a long-lived application in the browser. A lot of the things that entails
meaning we sort of have to think about memory management and synchronization of data
between what we're showing on the client end and to what other clients may be creating and
also what's on the backend, stuff like that. There are a lot of new complexities that this brings
to the table. We still work within the context of the web so we have to like manage URL and
browser history and we think more now in terms of flows then just in screens, so rather than
moving from screen to screen, we think about a like a real low latency UI where different
actions that a user takes will change other things that they see on the screen. It's not simply
throwing down all of the state to the server and then rebuilding it right back up on the next
page request. Here's an example of sort of a canonical single page application. It's a todo
manager at todoMVC.com. They, this is like the Rosetta Stone, I think, of todo apps and
application JavaScript frameworks for the front end. You can see this is the Ember example.
They all work exactly the same way. It shows, you'll see, the top of the screen is a little bit cut
off, but you can see how the URL changes as we move around. All of this stuff is happening
without any server implementation having to happen at all. Now that we have an idea of what
single page applications are, the question is why do we build them at all? What do they give us
that we don't get normally? I think there are a few major reasons. A very big one is mobile. A
low latency UI, which is what we can happen we don't have to fetch the entire state from the
server every time is, that's what we get when we can avoid that call response cycle. Especially
for mobile ware, bandwidth is at a real premium and there is high latency between the server,
the cloud and your phone or your tablet so it makes a lot of sense to build an application that
can run for a long time that can be responsive and snappy and increasingly, I think there is a
marketplace expectation now. Users are used to apps getting more and more powerful.
They're used to native apps and so they want to see the same experience on the web. The
reason that we build these in HTML instead of proprietarily, instead of native apps is that we
can share everywhere, so the project I'm going to show you here is the same code base and it
works mobile, tablet, web, and we also get to take advantage of a lot of the great things that
the open web gives us like shareable URLs and just being able to be able to see and freely
distribute these things, distribute updates and stuff like that. Now that we have a motivation
for why we build them and what they are, the question is how? My choice is Ember and that's
what I'll be talking about for a little while now. If you have seen much about Ember or read
about it before, I'm sure you have seen the slogan. It's a framework for creating ambitious web
applications. It's pretty much, it's on the front page of the Ember website and something you
see pretty much every time you get involved with Ember. It can sort of like wash over you if
you have seen it too many times, but I think it's worth taking a second and unpack exactly what
that means. First of all, Ember is a framework. It's unabashedly a framework. The creators,
Tom Dale and Yehuda Katz gave a talk at Fluent Conf recently called in Defense of frameworks
and they made the case for the fact that for what frameworks bring to the table, and what
specifically Ember does, the idea is that we are sort of all -- the similarities between web
applications outweigh the differences and we're all climbing the same mountain. Ember really
works hard to provide a structure to what you are doing but also giving you all the tools, all the
hooks and stuff like that to modify it to your own needs, and I think we are seeing that out in
the ecosystem. No one is being constrained by the framework of Ember and, in fact, I'm going
to argue a little bit that the predictability and framework of that structure is actually a very
positive thing. The second part is that it is for creating ambitious web applications, which I
think is an important word to think about in that slogan. The web is, web applications are
increasingly getting very complex and I think Ember developers and Ember framework creators
have a healthy respect for that complexity. Originally, JavaScript was sort of like a toy language
that you would throw on, add to a webpage to sprinkle on a little bit of extra, a little bit of extra
form validation or like alert messages or something like that, but increasingly, it's coming into
its own as a first-class language that can be used to build really important and powerful things.
And we want to respect that complexity and want to pave over as many of the common
challenges as we can so that we can really reach far with applications and not settle for too
complicated solutions or sacrificing features instead. It's a community driven project. It's open
source and it's very much growing. I just came from a conference in Portland, the first major
Ember conf. It's continuing to grow. These are some of the meet ups I was able to
find@meetup.com and it's sort of spreading and getting more and more popular around the
world and I think there is a lot of interest in the Ember community to continue to spread that
and to help make web developers all over the world more productive. First demo I would like
to talk about. I'll show a couple of things. Actually, I'm going to skip ahead and show the code
for this one. It's so simple. If you have used an Ember tutorial you have probably seen
something like this before. It's the canonical use case, maybe, for Ember. What this is showing
where, it's a little template, binding a property called name to a text input field and then
displaying that same property. This is literally all of the code. Other than maybe the two lines
of JavaScript that set up the applications, this is the entire code that handles finding those
properties from one to another. I'll show you how it works here. If I type in my name here, you
see it just live updating. We can change it as much as we want and it continues to update the
value that is shown on the screen. Again, this is sort of one of the very core features that is
built into Ember. You never have to touch JQuery. There's no manual don manipulation or
anything to do this. The nice part is that Ember sort of things of having a single source of truth,
I suppose, for the data, so there's a controller that internally is going to back this and store that
property name and so anywhere that changes that name property, whether it's through user
action on the client’s site or through application code as it's running, it's going to instantly
reflect all of those changes everywhere that that property is being used. This button will set it
on in application site code and it will watch the values just immediately propagate to the
server. Likewise, as many times, this is just the same template over and over again. It's the
same property without having to do anything else every other place that it's bound will just
automatically update, this same code just repeated four times down below. So that's a little
example of data binding. Another thing I want to show you is computed properties. This is
another way Ember sort of, as I mentioned there's like a single sort of truth, single source of
truth rather for properties in templates and they live in code. Computed properties allow us to
maintain the dependencies between different properties that we have in our app and combine
them in logical ways. For example, if I wanted to think about taking a hike today in the
Cascades, I would say whether it's raining or not, because I understand it's kind of a tall order to
ask for it not to rain around here. But we'll say that if it weren't raining, I would want to go and
if it is warm out I would want to go. I don't want it to be too cold out. I can't go unless I have
fuel in the car, but if I do all of a sudden the property is just updated and I'll show the code so
we can change any combination of these will continue to say no until we get it to the right one
here. The code for this is also pretty simple. We are able to use Ember’s computed properties,
the and and the nots to transform our raw properties, has fuel, is warm and it is raining into a
logical condition called should hike. Again, Ember will just continue to update the value of
should hike every time any of its dependent properties changes. These things sort of cascade
through your application. They will allow you to write really expressive communicative code
and you very rarely get into synchronization issues where you have to remember to update
another dependent property as you change one. I want to show a little bit more advanced
sample of data binding. I mentioned that the properties here will just propagate. I found a first
name property to one text input field and the last name properties to the other and I'll
combine, have them combining into a full name property. Let's do this. They combine to a full
name property like that and Ember allows you to not just read those properties as they're been
changed by the user and the interface reacts to them. You can actually react as they are being
set and decompose the computed property here, which is the Abe Lincoln. If I change it here
you'll notice that the name itself changes and I'll show you the code for how that works too.
We have a property called full name which combines the first and last, but it functions as both a
setter and a getter and so when it's been set with a new property when I was changing the
combined property there, it was able to decompose the first name and the last name from the
component parts and set those properties. Again, you just set these things in your application
code and then they propagate to your templates automatically and vice versa. Finally, one
thing that's really nice about Ember is that they are very actively embracing the future of the
web. In particular, has anyone heard of the web components W3C spec? This is a spec that
they are building that is looking to find more ways to make the web shareable and extensible
through web developers. It's a spec to allow people to write -- it's mostly based around which
it, so the idea of a date picker, for instance, would be a good candidate for a component which
has its own little maybe JavaScript functionality the way it reacts when you click different things
in a small calendar and it would have a UI which displays this calendar and stuff like that and
they are all kind of combined together. You can imagine wanting to reuse this through a lot of
different applications. Ember has, is embracing, this is not fully built into browsers yet, but it is
being actively spect and Ember is looking to the future and they have sort of made their own
poly fill of this to allow people to use it before it's fully ready. I made a component that wraps
around all the functionality needed to instantiate and show a Bing map. Here is our Bing map
and because the number of data binding and we can bind properties into the map and change
them live. I can change the zoom and then the map instantly updates and I can zoom in here
on Microsoft and change things that don't relate to the actual map code like the width of the
thing. The real power here is because this is a component, all of these actions are isolated and
contained within the Ember component so I can just sprinkle it arbitrarily wherever I would like
in my pages. For instance, when I click this it's the same map because it's all down to the same
properties, but I am able to add it anywhere I want with a little bit of template code once I have
defined what the functionality of that is and they all behave the same way so they will all
instantly update too when I change that. I'll show that code here. This is just a little snippet
from the map component, but Ember has these lifecycle hooks for its components where you
can call a bit of code as, when they get inserted into the dom so this function create map gets
called when we call date insert element, it calls out to the Microsoft Bing maps Ajax API, sets up
the map and then this update map it hooks into the data binding and the property change that I
had mentioned before and any time any of the dependent properties there, center, zoom or
map type ID, map type ID was not actually shown, but if we change the latitude and longitude
or the zoom it will immediately update the map with the new properties and so that's how we
sort of are able to bind that. I actually have some example code for this that I have shared and
people are able to basically just take my code and can drop a Bing map component into their
own Ember app this way. Ember is continuing to work on sort of capturing and encapsulating
that stuff so that it becomes more shareable between Ember apps. This is the template part. I
just have to specify that I'm using the Bing map component and then I can combine in any
values that I want, so I am reading a zoom value in from the outside scope and setting it to the
zoom of the map. Ember has a law of small like nifty tricks in the different pieces of Ember that
make it useful to use, but it wouldn't be a framework if it weren't giving you a structure to sort
of combine these things altogether, so Ember really falls, it's definitely inspired by rails, the
creators of, one of the creators, in particular, of Ember came from rails before this and they
have that same philosophy of giving you a lot of good defaults out-of-the-box. It's the
convention over configuration sort of idea and Ember, it sort of prescribes a lot of things to you,
telling you where things should go and I won't say forces you but it very strongly encourages
you to use a certain predictable structure. It gives you five basic primitives, routes which
handle serializing your application state. As you went to the application, then controllers such
as the ones that handle showing and reacting to events in your UI and then models which are
your data properties, views which react to dom events like clicking and dragging and stuff like
that and templates which actually show what's displayed there. Ember gives you all of this very
predictable structure and a sort of a prescription as to where all of these things should live and
how they should interact with each other. Why is it important to have this predictable
structure? Before I answer that question I want to show you one more thing. The Ember
inspector is an extension for Chrome and Firefox that was recently released and we'll just move
right into it here. It allows you to inspect in any, even the production app, you can inspect an
Ember application as it's running and here is a screenshot of it showing, I'm hovering over in the
bottom part and this is the inspector. I'm hovering over one of the templates and a controller
and it shows me on the screen what template is actually being displayed there, what controller
is using to handle the properties and so on and the great part of this is because it's a live
application you are able to just use the Ember inspector. As I said there is a single source of
truth for data in Ember and if I change the Ember inspector, it will instantly update in the UI
also. Again, it's the same thing. This is sort of an ah-ha moment when I was using Ember. It
feels a lot more like application development. When you are using it 90percent of the time you
are not thinking about how you are interacting. You never liked are using JQuery to find things
or set things. It's much more like a declarative sort of formalized structure. It's a really nice
and the sort of thing. I said that Ember has a very predictable structure and that's the sort of
thing that makes something like this possible. If Ember didn't have that specified then you
wouldn't be able to make like a really high level tool like this that works for all Ember apps and
allows you to sort of see them, change them, debug them as their running; it's really nice. The
predictability, in addition, it gives you very predictable or at least as much of the ramp for on
boarding someone, so any time you come into an Ember UPI, you know roughly where you are
going to find the files that control different parts of the UI. If you don't you just open up the
Ember inspector and it will show you, basically tell you which template controller and route are
covering the different part that you are looking and it makes it really easy to get very
productive fast on a new project to bring new people in and really get going. It's a nice, it's a
great thing about Ember I think. I'll talk a little bit about what Ember development feels like,
but first we should talk about what non-Ember development feels like. Before really using
Ember, I mean we should say -- it's 2014 now and we still really don't have a packet manager
for client-side JavaScript on the web. We've got Bower but it's not by no means like a
comprehensive solution. It still requires a lot of manual work to integrate that. There's this
awareness, I think, there's still a lot of room that we have to go. The tools for doing client-side
development have improved a lot, but the default still is to throw things into global scope, try
to make sure they don't conflict with each other, edit CSS files to match what your JavaScript
expects, all this type coupling between different parts of your application. Ember is really trying
to leapfrog that and they are working on the tooling is well as the application structure so we
get beyond that to something that works a little bit better. As I said, Ember development feels
a lot more like first-class app development. They are working on a lot of good tooling for it
including looking for it to ECMAScript 6, syntax is much as possible they use something called a
ES 6 module transpiler which allows you to write ECMAScript 6 code that looks like the way you
actually expect to write real JavaScript programs or any program in any language, which allows
you to define an object or a class or something inside a file and then export it and require it
from another file. Here use Typescript, so Typescript is trying to do the same thing, right?
Unfortunately, Typescript’s module syntax in the ECMAScript 6 model syntax are not the same,
but I believe in the one one of Typescript they are going to try to converge to be the same. I
think that will be a really important point to sort of like Typescript will really come into its own
in regards to working in the greater ECMAScript 6 community at that point. Anyway, writing
Ember apps feels a lot like when you write your code you write your class, your model class in
one file and you write your route class in another file. If you need one into the other, you just
import it and use it and then Ember has a nice build pipeline that runs through grunt. It runs on
node to build all the files and that's where it gives you that all out-of-the-box. Feels a lot like
iOS app development because you've got -- or Windows presentation foundation. Is that right?
Yeah. I haven't used them myself but I've been told that it offers a lot of the same data binding
and like controller and action handling that Ember does and so if you use that maybe Ember
will be familiar or fun for you to use also. Ember is really looking toward the future and I think
they have a pretty good line on sort of like where things are going and how to converge on it to
make application development on the web feel like real application development rather than
just messing around. There are a lot of companies that use Ember now. There are many more
that are not listed on the slides. It's a growing community and here are just a few of the
headliners. There are more all the time and as of about a month ago also Microsoft Research
uses Ember. To my knowledge it may be the first publicly deployed Ember app from Microsoft?
I'm not sure if there are other. I hope there will be more. The one we made is called
HereHere.code. Made it with two of the people in this room, Lars and Iman. HereHere, did
anyone see HereHere at the tech fest demo about a month ago? Okay. HereHere takes 311
data from NYC which is, 311 is the number we call for nonemergency public issue reporting,
something like a street light out, fire hydrant missing, graffiti or a pothole. It runs it through
another project from Fuse called the Sentient Data Server which is something that maps data to
emotions. We take all the public 311 data that it gives us, normalize it, sort of run it through
this Sentient Data Server and it us out emotions for different neighborhoods based on what
they have seen happen. If there's like a lot of graffiti today that there wasn't yesterday the
upper East side might be particularly upset about that. I feel like the upper East side has a very
stodgy personality, so we get fussy and upset, whereas in the lower East side if there are a
bunch of streetlights out, they get angry and so they are much more gradient and hard-core
down there. We take all of these things then we build the neighborhood statuses out of it, sort
of walk you through a few things. The client-side, this is HereHere. The client-side UI is all built
in Ember and I think it allowed us, we had a lot to do in this project from, there's a lot of data
work, a lot of big data sort of, data hygiene work to do with the 311 data, running it through
the Sentient Data Server and so we wanted to be able to iterate very quickly on the front end as
we explore different ideas for generating neighborhood statuses and things like that and Ember
allowed us to sort of define a URL structure and allow us to change sort of different pieces in it
pretty quickly. Halfway through the project we really did a big re-factor of half of the sort of
data that we were showing and how we were displaying it and Ember allowed us to handle that
pretty easily. It manages all of the URLs for you so as you move around to a different
neighborhood you'll see the neighborhood changes up here. That's nice because it allows you
to share these things very easily if you refresh the page, then it will come right back to the one
that you were at because it uses the native web URL. For something like this about page where
we've got this map living in the background, for performance reasons we don't want to tear
down this map and rebuild it every time if we're only simply switching from one screen to
another. The map lives below it our routing structure has a route that comes in, builds up the
map and then shows the about page and that route is the parent of the neighborhood routes
also so they seamlessly move back and forth. They won't rebuild that code, so it is performant
and it makes it easier for things like mobile where it really matters re-downloading all of those
tiles. I mentioned a bunch of these things. We also were able to encapsulate a lot of client-side
authentication through Ember. Ember uses the JavaScript concept of promises. It's a way of
managing asynchronous behavior without having to nest in a lot of callbacks. The promise
represents an eventual value so that you can use promises as though they are roughly, you can
sort of lay out your code roughly as though it were synchronous, but they will actually sort of
move from one step to another with asynchronous action happening in between. It's a
powerful abstraction. It's not unique to Ember, but Ember was maybe sort of a front facing
leader in bringing it into their framework and they definitely use it for all of their asynchronous
behavior. It allows us to manage something like a client-side login pop-up that pops up a
window, allows you to go in there, forget your password, try to sign in a couple of times and
finally completed before it closes and that's managed just through a single line of JavaScript on
the client side while it basically says while I'm waiting for this promise to finish, do nothing and
then continue. It gives us a lot of nice abstractions that allow us to do things like that fairly
easily and allows us to add a bunch of other authentication strategies without having to change
our application code. In addition, Ember has a really nice testing story. These are tests, some
of our tests running. Stuff like this also helpless re-factor. Ember is increasingly putting focus
on making the testing primitives nice and easy to use, but the ones that are there now are still
pretty great and they allowed us to, like I said we had this big re-factor halfway through and a
lot of this allowed us to keep the complex client-side interactions between different parts of
the page working while we change other parts of the application code. It makes things pretty
easy. Earlier I asked who uses Ember and I hope at the end of this talk that you are at least
inspired to check it out and maybe the next person who uses Ember will be you. Thanks a lot.
[applause].
>> Lars Liden: We can open it up for questions.
>>: Can you compare Ember with Knockout which seems to do similar sorts of things?
>> Cory Forsyth: Sure. Actually, Knockout is one of the few things that I really have very little
experience. I probably should have looked at it more because I know it's very popular within
Microsoft. Knockout also has data bindings, correct? Yeah. I'm not sure. Would Knockout be
more of a library or a framework? Sort of a little of both?
>>: I think of it as MVVM framework.
>> Cory Forsyth: Okay. I guess I don't really know a whole lot about it. I know that Ember
really tries to be incredibly comprehensive. It does as much as it possibly can for you. It
probably goes further than Knockout does in terms of things that you would have to solve,
problems that it would leave for you to solve, but yeah, I don't really know too much.
>>: I wondered about the Ember as far as scalability? I've seen it before you were here but I'm
interested. Do you know of any applications or bigger sized applications that takes a lot of
traffic and can they support that like when a web application grows and it has so many routes
and components and controllers will it work well or will it have issues around the?
>> Cory Forsyth: This is definitely something that the Ember folks are working on a lot, making
that easy. One thing they are spending a lot of time doing now are improving the build
pipeline, so I mentioned that you write Ember more like a real application with files that all live
separately and sort of logically contain their functionality, but then they all have to get
combined and we are still working on a web so you want to end up one big concatenated
JavaScript file and it takes a long time to rebuild that pipeline. There is a lot of work now going
on to make that very fast. When you get to tens of thousands of files it can really slow down
but I think it's going to get a lot faster. They have a new tool called Broccoli which takes trees
of data sources and then combines them intelligently and quickly. As far as structure, I'm not
sure of the best example of a really large complicated app. I'm not sure what the most
complicated ones are, but some of the ones I showed, I think Squares app is really complicated.
The company that funds, or the consulting company that the creators of Ember have
[indiscernible]. They have a product called Skylight which is a performance monitoring tool that
has a lot of complicated routes, I believe.
>>: [indiscernible] situations where the browser consumes a lot of memory and stuff like that.
>> Cory Forsyth: That size. Yeah, I'm not totally sure. I do know they are working on intelligent
route loading, so that's one of the new things that's going to come to Ember, which makes a lot
of sense, because the way in iOS app would work as you would download the entire thing one
time and then you could run it forever, but web apps you are basically downloading an entire
app every time you visit that page, and so they are working a lot on being able to easily split
those parts apart, so you wouldn't load up any of the admin routes, for instance, if you weren't
an admin user or until you've visited that part. I think that will help a lot with their
management. Just the data bindings themselves, I think, make a lot of that stuff easier. It's a
lot harder to accidentally create a leak when Ember is managing that memory for you already.
You don't have to manually do it.
>>: What are your thoughts around mobile development? We are doing some work with
Cordova. You showed the Ember inspector which looked real interesting. Where is that in
terms of mobile development?
>> Cory Forsyth: I know that there are several applications that people are building that use
PhoneGap. Is Cordova and PhoneGap the same?
>>: Yeah.
>> Cory Forsyth: Yeah, to package them up and distribute them, there is a company whose
entire, their entire company runs on building apps through PhoneGap. It's called the APP and
they allow people to generate their own apps through a drag-and-drop user interface online
and it packages it up into an Ember app, runs that through PhoneGap and actually makes
something available that you can download through app distribution channels. I think that
because it's their core business, they spend a lot of time optimizing for mobile and there are a
lot of people in general who are optimizing for mobile. Ember, because it has that repeatable
structure, it gives you the ability to share common solution patterns. For instance, there's a lot
of stuff that involves virtualizing list views that you can share, and that was built because
handling 10,000 dom list nodes in mobile is pretty tough. It will automatically manage having
them removing them from dom as they move out of screen or reusing them, like reusing table
cells as they shift off hopping them back on the bottom with the new thing and stuff like that. I
think that story is going to continue to improve with Ember.
>>: I've got one more question. I know we talked a couple of months ago and at one point you
had tried to use Typescript and you said it wasn't quite compatible yet, so would your
recommendation on that be to just hold off for Typescript 1.1 before trying to do Ember and
Typescript together?
>> Cory Forsyth: I think maybe the, there may be two things that make Typescript a little bit
tough. One is that the static type checking that Typescript gives you, Ember uses like what is
called a uniform access principle for its, for getting properties from different pieces of the
application. You ask for it right like a path name and I think the Typescript part is going to be
really difficult for it to infer what type of property is going to come back from that because it
would have to introspect a string and the string could be dynamically created. That part of it
will be sort of tough, but I think, as I understand it, the IntelliSense will still work well in terms
of just giving you what parameters and functions are available to you at times, so that will help.
The Typescript, the compilation as I understand it has basically to modes, like a node mode
where it says I'm going to take Typescript files, make them into common JS style individual files
for export, or web mode where it does the compilation but also then the build process for you
and the last time we tried to use it it creates anonymous AMD modules which do not work well
with Ember because Ember expects to be able -- it can work with AMD modules. That's the way
it actually transpiles down but it needs them to be named so it can resolve them. It uses
dependency injection pretty heavily so it looks up a lot of these dependencies at runtime or as
it's going. That part I think is the most complicated. We actually in our work we released an
open source compilation step for Typescript that runs through like the grunt build pipeline, but
it's still hard. I wish it were easy to use. We actually really enjoyed using Typescript but we had
a little bit of trouble with it for that reason. I think it will be when Typescript modules match
JavaScript 6. It should actually be really easy to use I think.
>>: I have a question. Are there any like server-side integrations or anything in Ember that
makes it more or less attractive to use? Certain server-side frameworks or as long as you have
the law defined TPI, it doesn't really matter?
>> Cory Forsyth: Ember data is the official data layer solution for Ember. It's the least complete
of the Ember ecosystem, partially because I would say it's the hardest part to get perfectly right
in the generalized way. It has, it does work pretty well, but it is very, it is the most opinionated
part of the Ember ecosystem in terms of how it expects things to work and be structured.
There are a lot of concerns that come up when you're fetching data in terms of keeping them in
sync when you have dependent resources as opposed to many comments and comment
changes does the post also become dirty? What needs to get back to the server when new data
is coming through like web sockets or something like that? How do you make sure that
everything stays in sync? So that's hard and Ember data does give you sort of like a paved
happy path, but it is pretty narrow at the moment. They are getting a lot better at giving you
folks to normalize and transform like JSON responses from the server so you can sort of work
with an API that you don't own, transform it into responses that it expects, but it is definitely a
hard part. It gives you I would say all of the hooks to do it, but it is hard. This is their, they are
perpetually this far from like a 1.0 official release. I'm sure it will happen and it's not too far off,
but they have been kind of on the cusp for a while I think because they are working really hard
to get it right. When it is released I think it will be really good.
>>: Can you talk about the role of community here? Are they contributing only to the
framework? Are there packages the way node has packages that are community generated?
>> Cory Forsyth: Yeah. There are definitely, there's this sort of small ecosystem of packages.
There are a fair number of really popular and common ones like internationalization libraries,
form validation libraries. There's some authentication libraries and those are shared, but like I
said, those are even the best we have for sharing this stuff is still Bower package management
system which is really just a download tool. You know, it doesn't actually integrate it into your
app, but I think this will be a thing that comes pretty quickly and Ember is a good plug-in
system. They already have sort of a basic one where you can add your own dependency
injections like register a service, set and initializer function on your application that will set it up
and add it to the parts that it needs, but it's not totally automatic. It still requires a little bit of
manual for it. Probably the most excitement in the community is still around the framework
and like ironing out things. Particularly, it's moving into the periphery though. Like the build
pipeline is getting really popular. People are doing a lot of work there. Testing, strategies and
tools are getting a lot of interest right now and then yeah, I think the next sort of layer, sooner
or later we will have like this explosion of plug-ins once the components, like I said,
components really encapsulate functionality, so in theory they are very easy to sort of spread
and take one from another place and use it in yours, and that’s I think where we're going to see
a lot of things happening. There's a pretty good, there's probably like maybe a couple dozen,
like 30 or 40 good libraries out there that have reusable solutions packaged, but I think we'll see
a lot more pretty soon.
>> Lars Liden: Thanks a lot, Cory.
>> Cory Forsyth: Yeah. Thank you very much. [applause].