KENT: And we're live with JavaScript Air. Hello everyone, my name is Kent C. Dodds and I am your host today for this JavaScript Air episode number 20, which means it's our 21st episode because we started zero here. We're gonna be talking about Ember today. Before we get into that and introducing our guests, I'd like to give a shout out to the sponsors that make the money parts of this podcast possible. The money parts being like transcripts, and posting and the newsletter and stuff like that, so thanks to our sponsors.

Our first sponsor, our premiere sponsor is Egghead.io and they have a huge library of bite-sized web development training videos. Check them out for content on JavaScript Angular, React, Node, and hopefully Ember sometime. I'm looking at you, Iheanyi. (laughs)

Then Front End Masters is a recorded expert led workshop with courses on advanced JavaScript, asynchronous and functional JS as well as lots of other great courses on front end topics. I think they actually do have content on Ember. So yeah, check them out at FrontEndMasters.com.

And then TrackJS, TrackJS reports bugs in your JavaScript before customers notice them and with their telemetry timeline, you'll have the context to actually fix them. Check them out and start tracking JavaScript errors today at TrackJS.com.

And SparkPost is an email delivery built for developers. Build something awesome with their node JS library or SMTP relay. Start sending 100,000 emails free with SparkPost at SparkPost.com/JSair.

And then WebStorm, WebStorm is a powerful JavaScript IDE, it makes developers more productive with its super intelligent coded assistance for JavaScript, Node, Angular, React, and integration with lots of different tools. Learn more at Jetbrains.com/webstorm.

Sweet, that's our sponsors, so before we get underway, if you have questions while we're doing this show, if you're watching live, then you can ask those questions of the panelists and our guests using the hashtag #jsAirQuestion on Twitter. And I watch that during the show and at the end of the show, so that we can bring up those questions during the show.

And then remember that this is a weekly show, so we do have another show next week. It will be a different time, I believe it's 2:00 PM MDT or MST, whatever daylight savings we're on right now. We're gonna be on site at ngConf. So, yeah, should be fun. And we'll have a bunch of guests there. It'll be like our other conference on sight shows. Definitely like you for feedback on those. And then as always, follow us on Twitter, Facebook, and Google+ to keep up with the latest from JavaScript Air.

Great, so let's go ahead and introduce who we have as panelists today. First for our panelists we have Iheanyi, Ekechukwu.

IHEANYI: Ekechukwu, we'll get it.

KENT: Ekechukwu. I'll get it, I promise. (laughs)

IHEANYI: Yeah, no worries. (laughs)

KENT: And Kyle Simpson.

KYLE: Hello, everyone.

KENT: And then for our guest today, we have Gavin Joyce.

GAVIN: Hi.

KENT: And Matthew Beale.

MATTHEW: Howdy.

KENT: And Robert Jackson.

ROBERT: Hello, hello.

KENT: And we're super excited to have you all. I'd like to invite each one of you to just introduce yourselves, who you are, why you care about Ember, that kind of thing. So we'll start with Gavin.

GAVIN: Okay, so, I live in Dublin, Ireland. I've got two young bright kids. I've been building software for about 18 years. Two and a half years ago I joined my present company, InterCom, and I introduced Ember successfully to InterCom. We've grown fantastically since then, we've released a number of great products, and I am very enthusiastic. And I love Ember, the community and the framework.

KENT: That's great, let's go with Matthew next.

MATTHEW: Yeah howdy, my name is Matthew Beale. I go by the handle @mixonic on Slack and Twitter, since there's public Slacks now. Web developer based in New York City. A few years ago I started out a small consulting company with a partner of mine Cory Forsyth, we're called 201 Created, we do a lot of open-source and helping companies work with open-source to create scalable solutions and scalable communities. So we've done some work on open-source. Text editor called Mobile Doc and we've been working with Ember for like three and a half or four years or something like that. It's amazing how much time has gone by. It's really incredible. Yeah, so, that's the 80/20.

KENT: Cool yeah, time flies when you're having fun. (laughs) Awesome, Robert, why don't you go next?

ROBERT: Yep, I'm Robert Jackson. I am a developer at Twitch at this point, and I work with mixonic on the core team, the Ember core team, and do just a bunch of open-source development in and around the Ember ecosystem on roughly any possible add on that exists. And, just love the community and it's what keeps me coming back and contributing and getting involved.

KENT: Very cool, I didn't realize you worked at Twitch. That's cool. (laughs) So when I was live streaming adding you to the JavaScript Air website like two hours ago, you're like, "Oh cool, Twitch."

ROBERT: Yes. Hey, I know that site. (laughs)

KENT: Yeah. Cool, well let's get into our subject today, we're talking about Ember and each one of you care a thing or two about Ember. So, I think it's good to always start out our conversations with a good baseline, so we all understand what we're talking about. Make sure that we all understand we're talking about a washing machine. No just kidding, a framework, let's chat about that, so what is Ember?

ROBERT: Well there is a coffee mug that is made by a company named Ember, maybe that's it.

KENT: That's confusing. (laughs)

MATTHEW: Also, Ember is a dance club in Portland which everyone recognizes when we go to EmberConf every year. And then Tweets about.

KENT: Nice.

MATTHEW: Yeah, Ember's a JavaScript framework that originally was called SproutCore 2 and then was called Ember. It was really spun off from a legacy of, well a legacy at that time project called SproutCore. Yehuda Katz and Tom Dale are the ones who famously started working on Ember. Really what their goal was was to take some of the parts of SproutCore which was heavily inspired by iOS development and Cocoa and that style of library and try and bridge that with the fact that SproutCore felt very awkward on the web, because you know you had access to things like HTML and CSS, and what you kind of expected from a web framework. So Ember really attempted, very early on, to marry those two things, to say, "Let's take the things that work really well in Objective C or any other kind of native development and bring them into the web, but not lose the parts of the web that make it, you know, a liable important platform that's been around for 20 something years."

So that's the high level summary, values that Ember has that make it kind of unique or at least things that we like to tout of course many frameworks have different variations but we strongly take from Rails the idea of convention over configuration. So Ember tries to emphasize that there's a pit of success that you will fall into by doing something, instead of needing to discover or find what the right way is amongst multiple options. There's a question that popped up I should close this real--

KENT: That's right I was just mostly making that as a note to myself, but I wanted to ask you Matthew, you mentioned that there are some important things that you didn't wanna lose in the web platform, what are some of those important things that you were talking about?

MATTHEW: Yeah, HTML and the web APIs are they are like the strongest thing for a guarantee that you can possibly have right? They will never break. You can write an app for the web and there's a pretty chance that it will still work on many, many platforms all around the globe in eight years. We're supporting Microsoft browsers that are nearly 10 years old, and we are actually supporting them. And that's a thing that you couldn't say if you were to write your app for iOS, you're not supporting a 10 year old version of iOS. But I think that's a really valuable part of the web platform that we wanna hold on to. The other thing is still URLs, URLs are still something that native platforms have attempted a couple passes at, but I don't think they've quite knocked out of the park like the web has. The idea that you can take all of the state of the application that you're currently running, put it into a simple text string, which is hopefully human readable, but not always, and then pass it around is still a really valuable concept. Yeah, I feel like maybe I should kick that over to Gavin or Robert if they wanna talk. I'm sure I missed a whole bunch of good intro things.

GAVIN: Okay, so, for me, as not someone who works on the internals of Ember, I'm not on any of the teams that like Robert and Matthew are, but I do build a pretty large application on Ember, so I have that perspective. For me, some of the great things about Ember are one, the conventions, and this isn't just the conventions around thinking about the application that's actually running in terms of the moving parts. There are very strong conventions there, but it extends to the actual structure of the file system, how files are laid out, how we test the app, how we deploy it, how we create it. How we pull parts out into add ons, how the community coalesces around these add ons. And we progress the framework by submitting RFCs, how it has a six week release cycle and how it cares about all the apps that are out there, and thinks thoughtfully about how we can get from a pre-release to a one release, to a point two to a point three, how we actually bring everyone along with that and everyone gets better all at the same time. How we talk to our JSON APIs, all of these things are decisions that a lot of people have to make for themselves, and people make various different decisions. By not having to make those decisions, an app like InterCom and a team of 70 engineers, maybe thirty who regularly worked on the Ember, we're just starting from a much higher place. So we could be extremely productive with the framework.

KYLE: I have a question, so, Ember I think would very fairly be categorized in the top three of the major frameworks that get most of the attention these days, certainly not the only ones, but I think top three Angular, React, and Ember kind of most people would agree with that so. I think a lot of our listeners might be interested to hear you talk, any one of the panelists, talk about why would I choose... it's a two part question. First of all, why would I choose Ember over just writing the code myself? You know, so what are the places where Ember has kind of a sweet spot. You touched a little bit on that with some of the platform level stuff, kind of like the inherited from Rails, but I'd like to know more about that, like what are some use cases where Ember really shines? And, second part of that question is, what are some of the places where Ember is going to differ in the approach to app development as opposed to something like React or Angular?

ROBERT: I'll jump in, so a couple of things to the first question, basically the idea behind Ember is that you can jump in and you can build out an app quickly and you don't hit walls as you go. You don't have to get to a point where the things you've written before you have to tear apart and redo because it doesn't scale. With regards to number of developers number of pages or routes or whatever the case may be in the app. I think, so to do that, we've built a ton of tooling around making it very easy and straightforward to get started in an app. I mean it's just a handful, like two npm install number, CLI, and then Ember new some name. That's it, and I think that's really powerful it lets you jump in and hit the ground running.

And then you don't have to build your own build tool, and you don't have to figure out how to transpile ES6 if you want to use ES6, you don't have to decide where to put your files, or how to deploy. All of that stuff is sort of pre-packaged and ready to go, which you could absolutely do with any of the (mumbles) or your own home grown thing. You can absolutely do all of those things straightforwardly, I mean these are known solutions. The problem is you have to do them. You then are maintaining and required to maintain all of that code. And all of that whole solution basically forever until it either stops working, you leave, or you have to rewrite it in something else. Right, so I think that's one of the real powers of Ember, it's like a community of developers building all the things that we all have to build and create and ship, and you know, so that each of us individually don't have to build our own bespoke systems separately, and we can all focus on just building the apps that we actually care about.

KYLE: So on that point, just to drill in a little bit, since it was invoked earlier with Rails, I was never a Rails direct developer but I know many that are and talked a lot, and one of the characteristics that I got about the Rails community was kind of like there's one right way to do each task. Like there's one Rails module that's kind of everybody uses for authentication, and one that everybody uses for the caching and one for testing or whatever. Is that similar in the Ember world, where it's not a lot of choice, it's kind of like we've already figured out and so just pull these Legos in, or how do you manage the choice in a big ecosystem?

ROBERT: So the phrasing is slightly odd, sorry, so there's a few things. Firstly, most of the things you're talking, like most of the things you're gonna wanna do have been solved, the generic things have been solved by add ons, what we call add ons. Those are just npm packages that know how to plug into certain hooks and number CLI. There is a great website, EmberObserver.com that you can go to and get a ranking, and they evaluate the tests, and sort of tell you categories of things to update the document title or things to do authentication or like that kind of stuff. Similar things exist probably in every ecosystem, and I probably don't know them all, but it's a great avenue to explore.

I think that the idea that there's only one way to do a thing is generally not true. It is generally a thing that puts a lot of people off. I think that there are, in a lot of cases, there is a few really good contenders for how to do specific things, like network requests or you know API structures or things like that. And, the fact that you can just pick one, pick the one you like, you know look at rankings, figure out what people are using, and just go to town. I think that's the kind of thing that I'm talking about.

MATTHEW: Yeah, and to add to that, there is an emerging tradition that started really only in the last year of independent solutions that are independent add ons npm packages, solving a similar problem, coming together to take the lessons that they learned and come up with one solution. And what's kind of cool about this is it's been very much a butt 'em up thing so Luke Malia gave a talk at last year's EmberConf that was great about a deployment strategy and he had talked to a bunch of other people who maintained different deployment tooling for Ember CLI. And, I got them all on board with the idea of creating one tool that summarized all of their knowledge and made it easy to use. And they've done that over this year and they have their own kind of structure of a team that maintains this thing and tries to solve the harder problems in it by bouncing ideas around between people who know the domain really well. We're seeing that now with accessibility happening in Ember, where there's another team that's popped up to do that. The translations libraries have worked closely with each other to try and see if there's a path for them to merge. So it's kind of cool from the bottom up to see these people trying to say that they want a single solution, even the maintainers. They don't want to maintain their own bespoke thing, they want it to move forward.

KENT: I think that's a really mature attitude. So, one concern that I have with like all the decisions being made for me, and I think this is a pretty common criticism of convention over configuration, is the times where this tool was built totally out of the context of my application, so it might not cover my use cases properly, or I might have a weird end point that I just have to hit because it's a vendor end point or something like that. So how often do you find yourselves having to break outside of these conventions, and how easy is it for you to do that?

MATTHEW: Yeah that's a good question for Gavin. I feel like Robert and I probably have the cursive knowledge on that one.

GAVIN: Right so, I guess I mean don't let the idea of convention over configuration scare you or interpret it as meaning that there's only absolutely one way of doing things. So first of all, like Robert touched on the Ember Deploy team, they coalesced to form one add on that does deployment, but internally it's got a plugin strategy so there's all these different plugins that fit in there, so it's actually it's not a convention, it's now a higher level API, where people are now contributing all different types of strategies, and it's an ecosystem of solutions emerging there. From InterCom, the InterCom app perspective 'cause we're quite a large app, there are many, many people working on it, so over the last two years we've been working on the Ember, our Ember application we've had to dip into lower level APIs or private APIs from time to time, or even just bypass Ember altogether. I mean it's JavaScript running on a browser. It's got access to the DOM, it's got jQuery, you can use jQuery plugins if you want you can very lightly wrap them with components and reuse them, so you got the benefit of encapsulation, reusability and testing and all that.

We've also noticed, when we do, from time to time, dip down that's the time when we might have to put in a little bit of work as the framework upgrades, and that's the kind of trade off you have to make. By bypassing the conventions where necessary we're not part of this shared understanding of what an Ember application is, so we just need to shepherd that through as the framework progresses. But interestingly, as we dip, as we find small areas or pockets of areas where we have to go lower than what Ember provides, or to bypass the conventions, quite often there's an interesting problem there when it asks as some solutions emerge from that. I'm not sure who it was, but someone tweeted a couple of days ago, a week ago, they said, "Ember is a community from which a framework emerges." And I just think that's spot on. Quite often the interesting when you struggle with framework or toolkit or anything like that, especially your framework, if other people are having similar problems, that's just an opportunity for us to get together, figure out what it is actually we're trying to do, build a nice API in an open way with an RFC, and that's how the framework moves along. And in our time with InterCom, we've done that a number of times. We've bypassed one of the conventions, we've created an add on, we've noticed other people have the same problem, we talk about it, sometimes create an RFC, and then this either makes its way into Ember, or people coalesce and agree upon one particular add on, and that moves on in to bound leap.

KENT: Iheanyi, did you have--

IHEANYI: Yeah, yeah. So I guess one of the things with Ember, so with Angular I guess you would be able to sprinkle Angular n to like your HTML tags to refactor (mumbles) like piece by piece. We've seen the same story about React by going piecemeal on one small component of an application and then building outwards to a larger application. What's the story around refactoring like, an existing server-rendered application or just like maybe Vanilla JavaScript with some jQuery sprinkled into it to an Ember application? And is there any conventions around that? Or I guess any good resources on learning about that for a new Ember developer or just a team that may be looking to use Ember for their product?

MATTHEW: Yeah, so there is... I think there are two strategies. There is not unfortunately, I can't think of a single guide or something that summarizes all of the knowledge that exists about this. I think it's characteristically the kind of knowledge that happens internally at companies and that they gain and then they immediately throw away because once they've used it (inaudible)

IHEANYI: Yeah.

MATTHEW: But the first strategy is to use URLs, which is gonna sound low tech but works really well for a lot of different kinds of applications. You basically are migrating page by page and then you use URLs to navigate between them. And everything just works like it should because Ember apps have really great strong URL brevity. But the second strategy, which is I think more what you're getting to, which is more fun technically is figuring out how the Ember component to drop into part of a page is a lot more exciting. There is an add on called the Ember Islands written by Mitch Lloyd who I work with who is a fantastic really capable developer. Ember Islands lets you, I think it pairs very well with the Rails app but basically you are able to drop in a payload of data for components and declare where you want the component to go. And it's very specific implementation of that solution. I certainly implemented it and other people have on top of a different library called Ember Wormhole. And Ember Wormhole works a little bit differently. When Ember renders you know when Ember's render tree actually happens it of course just makes a bunch of DOM nodes. Ember Wormhole uses its magic trick where it says, "Well, I just rendered a bunch of text nodes or elements into the DOM, so now I'm just gonna take them all off the DOM and then put them back on the DOM in a different location that's outside of my app proper." Which is kind of a cool magic trick that lets you do lots of really interesting things of that component.

So I think there are a couple strategies out there, I just gave a talk to EmberConf on custom elements, and how you can consume custom elements from inside the Ember app and how you might invoke Ember components from a custom element. So I'd like to see us experiment a little bit more with custom element strategy. But I think, at the end of the day, all that stuff is good but for Ember at least, it's an interim step. And I think that is a slight difference. If you're talking about building Angular one app certainly maybe not two. But a React app you really are maybe saying, "I'm gonna sprinkle this in, and that'll be fine." That's my end game, and that's definitely not what we want your end game to be.

KYLE: So if we go back to you know, back in history a little bit and I realize half our listeners probably weren't even in our industry four years ago. (laughs)

KENT: That's me. (laughs)

KYLE: Go back a few years ago, we had Backbone was a pretty popular "framework." Certainly a lot of people are inspired by the MVC pattern or MV* pattern to implement on top of that. And I personally was a fan of it because it was very modular. You could sort of pick and choose the different pieces that I liked and there were certain things that I thought were awful and other things that I thought were great. But the problem with Backbone that I think some of these other newer frameworks have tried to solve is that if you lined up 10 different people that were Backbone developers, you'd get 11 different answers for what a Backbone app is. Because it was so wide open. So I think we saw a move to sort of constrain down to do a thing you just have to understand this one concept, and this is the flow of the stream, so if you go with the flow of the stream it works. And so if you think about Angular that notion is declarative markup and the idea of how we separate out our controllers I don't even remember all this terminology. in React, it seems like the virtual DOM, and especially with Redux like the single flow of data and that sort of thing. So for Ember, what's that one set of core concepts that I would need to learn, so that I could do Ember the idiomatic way, the way that goes with the flow instead of trying to come up with my own thing from scratch?

MATTHEW: Robert is already unmuted so I'm looking at him.

ROBERT: Yeah, so, I mean so the nice thing about Ember, like a few of us have said, is that we're generally always emerging the way that we look at things and we think about problems. We saw React coming forward and doing some really awesome things with the idea of the (inaudible) and not and we've absolutely wholeheartedly gone onto that, and let them do our research for us and learned many, many things from them. And that's still very much the right way to build an idiomatic Ember 2 app. I think in addition to that, other things that are very important and you should always keep in mind, is especially when you're building an app and not just a widget that's interactive on the page, is that your app essentially is owning a given URL, and that URL is like the single frame of reference that people are going to jump into your app and link to and jump around. And that thing is canonical, that is where, that's like home base. Right, that's where your thing lives, that's one of the most important parts of the app.

And this is also a thing that many, many apps hopefully non-Ember apps actually get wrong. You know like how many times have you been on a really nice slick website and wanted to copy a link and paste it to someone and the link doesn't actually open to where you were. Like that kind of thing is really, really annoying and it basically is breaking the web, conceptually. Like the idea of the web is that you can link to things. And Ember works really hard to make that structure very simple from a user perspective to implement and follow. So I guess my answer would be those are the two main sort of guiding principles. Go from URL forward, structure your app based on how you want to present it, and you know, essentially determine who owns what data and only allow that thing to mutate the data basically.

MATTHEW: Yeah, I think the direct comparison to it's difficult to make the direct comparison to what is the model compared to something like React. I think in Robert's answer, what I was hearing a lot is talking about routes, and I think that's the classic thing where not classic, but it's rather indicative of the fact that Ember's scope is a little bit larger. So we could talk about what the unifying characteristics of the templating engine is, but that's not the bounds of what we're trying to build for people.

KENT: Very cool.

IHEANYI: I had a question around I guess, I don't like that it's (mumbles) to go and talk about in the show so I wanna hear more around the story about server rendered Ember applications and talking about FastBoot and perhaps the future of that, if y'all know that. 'Cause I think it's really, I know that they announced that at EmberConf, I know that there was a lot of hype around that. I'm wondering how far along maybe progress is around having a FastBoot application that also will be able to maybe do the initial boot, then rehydrate your app so you can then continue using it.

ROBERT: Okay so I will start from the beginning of time or of FastBoot.

IHEANYI: All right. (laughs)

ROBERT: And, so yeah so Ember CLI FastBoot is a library that you can install in an Ember app today. It currently works with stable versions of Ember, so you can kind of just drop it in and use it and it renders. And it works actually really well, there are a number of things that you'll end up fighting or dealing with with various parts of your app, and any extra libraries you pull in. Things that might assume things about the state. Like, assume that they have document or assume that they have Window which aren't actually things in the server. You know so you'll have to figure those things out. But basically the entire Ember community is also going through this path with you. And you'll find or at least I have found as I've built these sites, other people are also discovering things and we chat, there's a nice lecture where we talk about it. And you know people are fixing other add ons that they don't own and going through and just dealing with all those things. So that's the first part, and that very much works today.

I would call it more like beta-ish, right like it's not perfect, there's a lot of things in the ecosystem like other add ons that you might pull in that need some assistance. Some things are actually really complicated in a server rendered page. So the things like Off right like how do you track Off, how do you, like in the app in a browser, it's a very well-known thing, and in the server it's a very well-known thing but how do you go between the two right? How do you bridge the gap with the same library? Those kinds of things are the things that are currently actively being solved. And, there is a specific team within the Embersphere, the FastBoot team, they have regular meetings. You know, I think their meetings are actually published as well.

MATTHEW: They're actually in a meeting right now.

ROBERT: Right now, yes. So, the, so that's sort of the first few bits. The last part, and this is the tricky part, as if the rest of it hasn't been tricky so far. Is actually rehydrating the app, so when you get the HTML emitted from the server and you get the browser request HTML, how do you resume that app with the current state? And that part's not done, so right now what happens is essentially we just re-render the DOM, like everything. You know like clearing what was there previously. And in the path forward on that is the implementation of a newer rendering engine that we're actively pushing very, very hard on. It's both faster in most every way and also will give us the ability to start working on the rehydration stuff. So, yeah so that's kind of where things are at. Server rendering right now absolutely works, you can use it to for example run... an Ember app without JavaScript enabled for example, or potentially surf to older clients or whatever. SEO is a great other use case. You know but then once it boots it's still going to sort of clear that server render DOM and re-render from scratch. You know but we're actively working on a way of a plan forward. I don't give timelines for open-source projects.

IHEANYI: Yeah, definitely.

ROBERT: But it's definitely a thing that's very high on our priority list.

IHEANYI: For sure. So with this FastBoot story, that means that you would probably move away from rendering your Ember application within like the context of your back end, like within the context of a Rails application, you can move it to its own separate server to actually have that true separation of the front end application from the back end that could just now be your API servers.

ROBERT: Yeah, so right now, a lot of people confuse or get confused in general when we talk about "server-rendered," we are not saying that your API server is the thing rendering your HTML.

IHEANYI: Yeah.

ROBERT: Right what we're saying is you're actually using the same Ember app that boots in the browser, you're going to use that and spin up a node instance, or a node process whatever, and render the Html in node-land with the same exact code that runs in the browser. So that means that it's going to be, on the server side, communicating with whatever other outside processes have your API, or you know all of that stays exactly the same. And, the nice side effect is even if you didn't want to do the rehydration stuff or you didn't want to send the HTML to the client, you now have ways to for example discover what all the data for a given page load is going to be, and pre-load that for them. Right, those kinds of things are possible even without caring about the pre-rendered HTML.

MATTHEW: Yeah which is actually what LinkedIn is doing for their mobile page now.

ROBERT: Yes, yes.

MATTHEW: Fast code to figure out what API calls that then.

ROBERT: Chad Hietala gave a great talk about that idea and concept at EmberConf as well, I can link that in the show notes.

KENT: Yeah. That'd be great thanks, so I wanna ask about some of the challenges of rehydration, 'cause it's not an easy problem. So some of the things that I can think of is maintaining focus, so in the time that the user gets the HTML and then they can start messing around with the app and if they have a slow network, it takes a while to get all the JavaScript down and then rehydrate, like they can tab into different input elements, and if you totally re-render then they lose focus. Another thing would be, I know that Angular Universal I believe that they have this ability to track the things that the user is clicking on and interacting with, and then replay those events when the JavaScript loads and things are rehydrated. So what are some, are you addressing those issues and then what are some of the other challenges that rehydration brings up?

KYLE: To piggyback on that for just a moment, can we actually define what rehydration is? We threw that term around, and I'm not sure that everybody listening will even know what that means.

ROBERT: Yeah I'm happy to define it then I'll kick it back over to Matt. So basically rehydration, so when you talk about sending a string of HTML to a browser, that HTML obviously already has the content in it. Maybe whatever dynamic data that was pre-rendered, like a person's name, or the blog post title, or whatever the heck it is, will be pre-rendered in the DOM elements, right, so in divs or, whatever the heck you're using. And so, rehydration is basically talking about from the perspective of the JavaScript app that's going to boot after that has already been rendered and shown to the user, how do you take that state that's already embedded in the DOM, and seed that state into the running booted JavaScript app, right? The same problems exist in basically anyone that's doing server side rendering. Like you have to figure out how to get the state that's already been encoded into the DOM back into the running app, so you don't have to do things like delete all the DOM elements and re-render from scratch right? So yeah, so that's rehydration in a nut shell, is that process of taking the data, or the current state essentially from the DOM and hydrating the booted Ember app state. Or the current app state.

MATTHEW: Yeah and it is this little thing that some I know I've seen frameworks like Riot being used in the wild where they don't actually do rehydration, people presume that virtual DOM means it will rehydrate and that's not necessarily always true. Yeah, to speak to Kent's point, I think the replay of events you basically described exactly what we would want to undertake. We would do something very similar to what Angular 2 is doing where we just keep a queue of all the things that the user is interacting with and then to play those back. Obviously, that's gonna take a bunch of real world testing to see how that goes. Important goal here though is that if you want to do a server-rendered React app that's definitely totally possible today and you can do it really well. One of the challenges though is that a large part of your server will be very Bespoke, and a large part of your architecture will be very unique to what you're doing. And with Ember's FastBoot strategy, we do want a strategy that's easy enough and simple enough that everyone has no excuse. Like if you don't want to do it, of course you can opt out, but today with FastBoot, you can deploy a built pack to Heroku and boot up your Ember app on Heroku and be done. It should be a two, three-step process, it should not be sending a rocket to the moon in order to run your client-side app on the server.

The second part about some of the challenges in mutating a focus and kind of changing the DOM as you render, so the Glimmer 2 work that we've been doing in Ember is learning a lot from the previous passes that we've done on rendering engines, (mumbles) and Glimmer, every time we learn something new and move forward a little bit. Glimmer 2 has a really interesting architecture; when it ships down templates to your client, it ships down a series of Op-codes that run on a virtual machine in your browser. And as we execute those Op-codes we build up the DOM for your screen, but at the same time we're emitting a different set of update Op-codes. So if we need to re-render that logic, we don't actually run the initial Op-codes all over again because there's a bunch of wasted work that we don't need anymore, all we do is run updated Op-codes. So that the key for us to do rehydration and do it really well is that when we on the server render your application in FastBoot, we keep track of those update Op-codes on the server-side, and then we just ship all of those Op-codes down to the client. So we don't even need to walk through the DOM to check that everything is correct. I mean barring browser quirks which maybe not come into play. We just ship the update Op-codes and then we're done. You don't need to go and change the input to be some kind of new input or something like that. Everything just stays the DOM that it was.

If you wanted, if you want to learn more detail about how the Op-codes in Glimmer 2 work, it's a fascinating architecture. Yehuda has a different talk Yehuda and Godfrey Chan have a different talk from EmberConf this year a few weeks ago, where they go into some detail. And then Gavin Joyce actually has an excellent interview that he did with Yehuda a month and a half or two months ago that goes through the architecture in a lot of really deep detail with a lot of code up on the screen.

KYLE: In the React world, one of the things that is touted is the integration with React Native, that you learn one set of coding practices and now you can switch over and work in the Native world. Can you speak to what strategy you would use if you were kind of all in on the Ember side of things, and you had an app that was running on a server and then you wanted to start trying to use that same code and target a Native client, for example?

MATTHEW: Yeah I think the, so, yeah the Native strategy is an interesting thing to bring up and talk about. Technically, this is totally plausible. This is definitely a thing that we of course that we can do, the Glimmer 2 architecture is basically completely isolated. Similar to Angular 2 where they talked a lot about how their rendering engine is completely isolated from the DOM itself so they could for instance to rendering on a web worker, then ship the extra work back over to the main thread so that you're not blocking the UI thread when you're rendering. Glimmer 2 has a lot of those similar facets. So that I think technically, it's very, very plausible, and I know I have personally discussed it with a couple people the idea of what an Ember Native would look like.

I think the bigger fight though is that we're trying to take the fight to Native apps themselves, we think that the web is a viable platform for you to publish what people consider app-like experiences today. And that's really the end goal for us. The end goal as a framework, as someone who maintains a framework and tries to think about where we're going and what we wanna do with it, is that we are in the position of privilege where we get to make the web what we want it to be. JavaScript is really powerful, and we want the web to be a viable platform for those things. We don't wanna have to have you go and download a 30 megabyte 40 megabyte app in order to see your Pinterest page. This is a joke. This is not what we want to be doing in five years of 10 years. And so the fight really is not about how can we use web developer expertise on Native things. I understand that that's a big priority for Facebook, that's a big priority for Google where they have that kind of transfer of knowledge that they want to happen on their very large teams. And I don't think that Ember as a community is against that. I just think as a framework, our reason for that is to focus on the web and to make the web great. And so I'd like to make great mobile apps possible is the real goal, which slightly misdirects away from your question which isn't the intent. (laughs)

KENT: Yeah, so you're kind of focused more on the progressive web app story. You know, making the actual web application feel native but actually be, you know, just a web app.

MATTHEW: Yeah, it was a big focus at EmberConf and is something that as a framework, we've been pouring into FastBoot and we've been pouring a lot of work into Glimmer 2, and we've been pouring a lot of work into just on API which is a great abstraction for being able to get cacheable entities that actually guarantee that you have all the data about the data model when you go to the client-side and things like that. So, all those things are, the cool thing about Ember is kind of like with Ember CLI, it was a big mess for a long time and it didn't look a lot better than what anyone else was doing. But we managed to piece together and create mature solutions even though they took longer, and then suddenly, we have Ember CLI and it's great. And it didn't come out of nowhere it was a lot of directed work that we knew there was an end goal we wanted to get to. I think a big goal this year, this summer, this fall is going to be mobile apps in that progressive web app experience. And we have that end goal, it's just we need to take the directed steps to get to where it is.

GAVIN: Tom and Yehuda's keynote from EmberConf about three weeks ago is a good summary of a lot of that.

MATTHEW: Yeah that's your SDK for the web, which I think is a great one.

KENT: Cool, yeah let's make sure we get that link in the share notes please Gavin, thank you.

KYLE: So, my last question, just to kind of bring this all full circle is, I'm excited by the cool stuff that it sounds like Ember's working on. There's a lot of really interesting problems that the community seems to be tackling and that's awesome. I think one of the things that we've seen from, for example, the Angular world was that Angular 1 came out, and everybody got super excited and jumped on Angular 1, and they built all of their apps in it. And then Angular 2 came out and the world looked a whole lot different and there was a lot of pain. So my question, and I don't mean this to sound snarky but my question is, is it maybe too early to jump on the Ember train if there's all this amazing stuff that's coming out and still being developed like for example the maturity around FastBoot, the stuff with Glimmer Two sounds mind blowing. Are we too early to jump on that? And what I mean by that is if we build an Ember app the way it is now, how locked in are we to that where things could be very different six months or 12 months from now, similar to what we saw in the Angular world?

MATTHEW: Yeah I'll just say one or two things, I think this is a topic that's near and dear to Ember as a framework worked, I think both Gavin and Robert will probably have pretty interesting things to say, so I'll try and keep mine short. But, one of the things you get by buying into Ember as a framework that is truly independent is that you have the ability to influence what happens to it. We are not working on the internal product, the adds platform at Google internally that's our main use case picking up, which is not meant to be a slight against Angular team who takes many use cases into account. But it is actually our bread and butter as our framework, we all, like I work for a small consumption company that's worked with a bunch of various companies. Robert works at an Amazon-owned bigger company, Gavin works at a medium size start up and we're all here talking about the experts in this framework, 'cause even though we all have very, very different use cases and desires in the day to day. So I think we keep that close to our minds and by participating in the Ember community, you have the ability to continue to shape that direction.

A year ago there were so many people who worked on Ember at huge companies and this year, we have like PlayStation Now and Yahoo is a really big buy in and LinkedIn is a really big buy in and all these big companies. And you can see in the framework how that shifted our focus. So, I think that's when you participate in open-source, you are able to decide what happens. If you're just consuming something blindly, then you don't have that opportunity. So I think there's always change. Ember has a value of stability without stagnation that we focus on semantic versioning, having smooth upgrades to major versions where there are no actual breaking changes, we just remove features. And I think that that will continue because our focus is on real applications from people in the wild. But, Robert and Gavin please.

ROBERT: Yeah I think the key is just stability without stagnation idea. And there is a great talk that Yehuda just gave that sort of went through the progression of that. And I think that the idea of it, if you wrote an Ember... an idiomatic Ember 1.5 app, or something this was a long time ago. I can't even, like a year and a half ago or something, you could relatively straightforwardly get that app up to date with the current version of Ember which is 2.5. You know and most of that is with the tooling and the work flow processes that we've put together to help you figure out, you know we don't remove things without deprecations, even private APIs. You know, things like that, so if you can jump up, you see the deprecation, you read the docs the deprecations all have URL links to tell you what to do. You know all that stuff is exactly what where we're going.

We've just recently released our first LTS, which is, if you're not familiar, Ember itself has a train model similar conceptually to what Chrome has done. So we ship a new version, a new minor release every six weeks. If that's a little too fast for you or you don't want to try to do that work each time, if there is any work, you can always just stick on the LTS and those are roughly four months, I believe. And, and the idea is that the deprecations and whatnot will always be a good landing point at the various LTSs so you can see things, you know what the path for it is and whatnot.

So, I think unlike with, especially initially with the Angular 2 announcement, they didn't necessarily have an upgrade plan, that wasn't the goal, the goal was to build the best framework they could build. And I think it's great actually. And, I think that, but I think it's a little bit reversed for us. Our goal is to build the best framework we can, but make sure all of our users can get there. And, at every step of the way we're always planning migrations, we're planning the stepping stones to get to where we want to be. And in the end it's just the long game right? You know you take the right angles, you do the right things along. And since Ember is really as Gavin said earlier it's really a community, you know like leaving people behind just because an individual company or a core stakeholder needs a given thing or needs to change the path isn't an option, right? Because we're all made up of many different companies, many different users and the whole community itself sort of drives the direction of where things are going.

GAVIN: I think you'll see what Glimmer 2 wanted is there'll be some point release later in the year and Glimmer 2 will be enabled for everyone, and it will be relatively, it will be an easy upgrade because it's compatible with the Handlebars template syntax, and all the helpers go along with it, and all the hooks into Ember will be work the same way. So by design it will just happen, your app will magically become faster, leaner, and that's certainly been our experience. Even going from one to two which obviously, frameworks, you release the one, you do all sorts of things, you change, you learn from the community, people start using it. The 1 to 2 transition hasn't been painless and a lot of lessons have been learned, but it hasn't been very painful. And, I looked at what happened when Angular 2 was announced and just for a moment thought of what that would've meant for us at InterCom, in terms of just even dollars. If that had happened... if that had been Ember's approach to upgrading, and it just would've been, I would've felt embarrassed. I was so thankful that these are some of the things that I... the reasons that I was able to convince people at InterCom that we should make a big bet on Ember, and I'm so happy to see that actually is, it's all on trail exactly like that and it remains a big part of what Ember is.

KENT: Awesome. Thank you for that. We are really down on our time, so we do have two questions on Twitter. If you do have a question if you're watching live, you can Tweet #jsAirQuestion, and we'll look at those. So the first is from Scott Chapman, and this one I think the answer will be anecdotal at best but might be interesting. The question is, "How do Ember dev salaries compare to other front end dev salaries?" Definitely an interesting question. (laughs)

MATTHEW: Yeah. I don't know if they're competitive. I mean, devs get paid pretty well a lot of places. I know that San Francisco pays better than New York. I know that London is more expensive it doesn't pay as good as San Francisco. But I've never quite heard anyone say that they got paid more for working in React versus working in Angular or you know, UJS versus Ember something like that so. I know there is certainly a lot of demand.

GAVIN: We have people, we have engineers working on React at InterCom, we have engineers who work with Backbone, and we have engineers who work on Ember and we're all treated the same. (laughs) In many places.

KENT: (laughs) That's probably good. Awesome, and for our last question this is from Eric Henget, and the question is, "Are there some features not in Ember you'd like to see added from other frameworks like React or Angular?"

MATTHEW: I can definitely say at least one. So Angular, I'm not sure that I agree totally with the API, but Angular's their new template syntax in 2.0 allows you to, in a way that not even React allows you to do, it allows you to say exactly that you want to set a property or an attribute or add an event handler to a DOM node. And, I don't like their micro syntax. I think it's too micro syntax-y, and too magical. If you learn it, it's great, but if you're picking it up and walk into a project, there's no way you know what bracket parentheses something parentheses bracket means. But I think that that would be a great thing for Ember to be able to do better at, especially like I said we've been looking at web components, custom elements a lot, and in order to interact with those we need a better way to decide exactly what I want to do. I want to set in attributes, I don't want to where I want to add an easy event listener. We have, there's an RFC for element modifiers, which is something I was working on a few months ago that I'm gonna be pushing on again in element modifiers would probably help with that solution.

IHEANYI: I think what me what I'd like to see in Ember, personally, or at least Ember CLI is first class support for importing from npm modules, and not having to use something third party like Ember browserify 'cause I guess at a previous employer, I was using React with Web Pack and it was nice being to import npm modules, but now right now as it is, Ember doesn't have first class support for that. You can use Bower Library but it would still be nice to have npm, 'cause there are a lot of libraries are on npm, that aren't necessarily on Bower. So yeah, that's my one wish.

ROBERT: Yeah the good thing is that we're actively pushing towards that. We set our Bower dependencies from around 15, maybe 16 down to I think four right now. And, they're slowly pushing towards that future. Once we've dropped the requirement of Bower for new apps, then we'll be able to begin working on out of the box, making the require from npm packages work. In many add ons today for example will take a known library, like there's a great fetch polyfill, right? There's an add on that takes the fetch polyfill and wraps it and augments and adds nice utility functions to use in Ember and whatnot, and that all comes from npm. So it's definitely possible, it's just a lot more annoying than it needs to be. And you know, so I think that it's definitely the path forward.

I guess I'll go since I'm already talking. S I'd really like to see us continue to push the barriers of developer ergonomics and making things better. And I think that this will actually help the entire ecosystem. (inaudible) just Ember CLI, and you know so as we make improvements and extractions and make the world better there, at least both frameworks get better, and likely many others. So the things to me are just from a developer perspective, what are the hitches? What are the places where the gotchas and the things you trip up? And I'm not sure that... any every framework has them, so I'm not sure that I'm stealing this idea from another framework so probably not answering the question properly. But that's one of the biggest things that I'd like to see fixed.

KENT: Cool, we just got another question. Yeah so this is from K2G, and the question is, "Ember is not typically a framework of choice in Java-based shops, do you see that as well in consulting projects?" And then maybe is there a reason for?

ROBERT: So, I know of a number of fairly large shops using Java on the backend and Ember apps on the front. I'm not sure, I think the (inaudible) you know there's integration points that could still be made better, and whatnot. But there's nothing inherently different about Angular or Angular in the concept of what your backend is written in. So I don't think there's any barrier. It just may not be a mindset thing. You know, where the people are more exposed to a given platform or another.

MATTHEW: Yeah, I think even in the world of Ruby where I think that's the most immediate, what people most immediately correlate with Ember. But Ember has nothing, just because it's like Ruby it's more like the lessons of Ruby and Rails that we take away, it is none of the actual technology or stack like you don't use the Rails command anymore or anything like that to do anything with Ember. And I think that's maybe part of the jump as well, people are very used to putting JavaScript into their existing server-side stack code base. And it's a little bit of a conceptual leap to jump away from that, especially if you have a Java code base that's probably quite large if you're at an enterprise shop. But we work with Ember apps that use Go on the backend, that use Ruby on the backend, that use Python on the backend. It's all kinds of things.

KENT: Yeah. I think you have that conceptual jump with any modern framework. Where we're just kind of we changed from server-side render totally to client-side render, now we're kind of doing both. And people are still, you know, banging away at the server-side only stuff. So we're all learning and growing. So, that's our questions. So it's time to get into our tips and picks, so we'll go with our panelists and then I'll go and then we'll have our guests go. So let's see, Iheanyi do you wanna go first?

IHEANYI: Yeah, I guess just for my picks I have a link to a series Building a Performant Real-Time Web App with Ember Fastboot and Phoenix, and it's by Mike North. I haven't gone through it yet, but I was just browsing through it scrolling through it and it looks very interesting. It's cool to see how the story around using Ember FastBoot and combining that with another new technology or at least one that's getting really popular like Phoenix and Elixir. So I thought it looked pretty cool, I ask people to check it out. It looks like a good resource for learning both FastBoot and Ember and use them together. I mean Ember and Phoenix.

KENT: Cool. Kyle.

KYLE: Yeah, so, just picks today. Right now, there's quite a bit of discussion that sparked up over the last 24 to 48 hours over ES6 modules and how they fit into the Node and Common JS ecosystem. Bradley Meck and several other people have been doing a lot of work on that and they came out with a draft proposal for what they think it should be and it involves having to name our files with a different file extension. And then a bunch of other people jumped in and said, "Oh, that's terrible." So there's actually at least one counter proposal that's been put out. So there's a good raging debate on that. And regardless of where you sit, I think it would be good for listeners to kind of pay closer attention to that stuff. Because it's definitely going whatever decision gets made is gonna be with us for a really long time in the Node ecosystem.

Two very self-serving picks, first mention is Frontend Masters. Frontend Masters for those of you who don't know is a great video training platform. I have a bunch of my trainings on there, as well as there's 30 some odd other 30 or 40 other authors that have done amazing courses on there. So I highly recommend checking out Frontend Masters. You've probably seen some of those videos get sterilized out into places like Plural Sight and so forth but Frontend Masters is the main platform for that so I recommend that for sure.

And the other self-serving link is the book series that I have the You Don't Know JS books, it has been asked for for more than three years now for there to be some box set sort of pricing for people that wanna buy more than one of the books in this series. That's finally out. We have discounts for purchasing two or more of the copies or a flat price for all six books. And that applies to both print and e-book. So I'm excited to see that come out. And on the heels of that, (laughs) as soon as we release that pricing now I'm gonna be starting up on the second edition revisions pretty soon so. That's my picks.

KENT: Great, thanks Kyle. That's really interesting about that modules thing, people definitely check that out because this will be very impactful on your lives. Okay so I'll go ahead and give my tips and picks. My tip for this week is thank at least one person every day out of the blue. So, I got an email a couple a week or two ago from somebody just saying thank you, and it was just super nice and it totally was validating and it just made my day.

And then today, here's my pick, I got a Tweet from David Wells, he just published a blog post entitled JavaScript Community Thank You Letter, which was just super, super nice of him, where he's thanking several people in the community that's helped him out. And so, yeah, thank people and they will be happy.

Also, TeleDoc. So I am sick right now and not feeling super well and the last thing that you wanna do when you're sick is leave the house. And so, even to go to the doctor. And so for the first time ever I tried this TeleDoc thing, and I was able to just do the appointment on my phone and get a prescription, and it was awesome. So yeah, 2016 is a great time to be alive. So, yeah those are my picks. Gavin why don't we have you go next?

GAVIN: Okay, so, my tip is I've come across this saying a few times, I believe it's from Steve Jobs. Normally, it's on a poster on a wall in some software shop, and it's, "It's not done until it ships." And I think that was true back in the day when shipping software or hardware meant putting bits on a CD and putting in a box and putting in a shop to sell. That was done back in those days, but I think we can do better. I think shipping is just the beginning is a better thing to put on a poster and I encourage people to do that.

For my pick, it's a musical instrument called Ableton Push. Something I've been playing around with and thinking about a little bit recently I'm planning to do a series of YouTube videos, I just did the first this week on using JavaScript to control it. I'm hoping that this ends up with actually building a runtime in Ember for the Ableton Push, and hopefully get to present that at maybe Ember Fest in October. I've submitted the talk and if it gets accepted to end up there and possibly with a live performance.

KENT: That's sweet! You should add a link to your YouTube series that you were talking about, that'd be sweet. Matthew, we'll have you go next.

MATTHEW: Yeah, I didn't think I had anything, and then all you guys had great stuff and now I have stuff. I want to (mumbles) to Gavin's thing, the Yehuda during the keynote he said it really, really fast so I know a lot of people didn't hear it at EmberConf, but Ember has a six week release cycle which is akin to browsers, but when we did the 1.0 to 2.0 jump, it's kind of like the first time you had a six week release cycle based thing, but then also had a breaking change as part of it. And I think that's part of the big opportunity for the lesson was this kind of unique event. And we hope that other libraries pick it up and we can all learn more.

I guess I'll do my tips first. A quick tip for code review, I think you should always assign code review to someone. Don't just open a PR and let it go into the void, put someone on it and make them responsible for it, so that they need to follow through and you can ping them and nudge them if you need to. Avoid using pronouns and don't use words like "you" or "we" and things like that. Try and focus on the code and talk about the ways that you would differently structure the problem instead.

I think for some picks, I use a cool tool called Teammate sometimes, which is kind of like tmux which is a terminal multiplexer, but Teammate lets you share the section over SSH, which is great for remote pair programming when you don't have great video and you can just use audio and then you can use the share the terminal. It's also really good for doing (mumbles) because you can share read only sessions where people can just everyone in the room can see what's going on in your terminal without needing to look at a projector or something like that.

There's a conference called WickedGoodEmber that consulting company in Boston DockYard runs that's coming up this summer, it happens on Thompson Island. So it's really fun, it's in Boston. And it was a great event last year and I think it would be really fun this year. So you should check that out.

And last pick would be to if you're interested in Ember and you think some of the things we talked about are neat, you should find Alex Matchneer's talk on Ember concurrency. Push that hype. Ember concurrency is basically what Alex kept coming to the core team and saying, "Look at Rx, look at observables." And like, "we should put this stuff into Ember." And he got heavy, heavy push back on nobody thinking that the API was something that people actually really, really mastered, and really take home. It's a very intimidating thing to learn observables, and you kind of need to wrap your brain around them first. If you're talking about "I have a team of developers and I just wanna manage my async properly," it's overwhelming to ask them to learn observables just to do that. So he nailed a beautiful API that uses ES5 generator syntax to get people to just naturally write code that feels good but also handles async in a way similar to observables. So I highly encourage that you check out ember-concurrency.

KENT: Cool, thank you, and Robert.

ROBERT: All right so tips, so basically, the first tip dovetails, I thought Matt was gonna steal my tip actually. But it dovetails nicely with Matt's tip, and of always assigning code review to someone. My tip is always automate the menial tasks. So, essentially, you know, in Ember, we do release cycle, we do individual beta releases every week for both Ember and Ember CLI and Ember Data, and all of the projects. It's a lot of work that's happening every week. You absolutely have to automate as much as possible in those cases. The same is true in your company though, it's not just an open-source project thing. The same is true at every job you have. There are tasks that you do, sometimes it's deploying after master emerges or something like that right? All of that stuff should be automated. Free yourself from doing that sort of routine manual labor and buy yourself time on the things that are actually you're getting paid to do, hopefully. And, you know move those things forward. So that's my tip.

My picks are gonna be weird. So, the first pick and I don't know how you pick this, but I'm gonna pick it, is the April update for Destiny. Destiny is a video game I play on PS4. It is awesome. I am assigned the duty of playing video games as a chore to not do too much open-source, and this update was the best update that they've done to the game. It's been really great. And, it's been so much fun.

So, the second pick is don't work too much, or yeah basically. It dovetails with the first one.

And then the last one is, always get involved in the community that you're working in. Don't just assume that you know this is a faceless walled garden of software development and letting everything happen sort of over there and not being involved. Get involved. Jump in. Like Ember has a great slacker room. There is a few thousand people in there. And, you know, you can ask questions, there's help channels, there's channels specifically for all sorts of things. Every community has this, and you're gonna get way more out of any framework or language or anything you're doing if you can jump in and actually talk to people and meet that community that we've talked so much about. So that's me.

KENT: Awesome, thank you. So, I think we're gonna wrap things up. And so just to give a quick shout out to our silver sponsors, they are O'Reilly Fluent Conf, Auth0, and Trading Technologies, check them all out because they're awesome and support the show. Thank you, thank you to them. If you have suggestions on future shows, or topics go to suggest.JavaScriptAir.com. We appreciate your suggestions, and if you have feedback for this show or other shows, go to feedback.JavaScriptAir.com, and I will personally read all of those.

And then we have a newsletter for each show, we give some highlights from the show and post it in the show notes and stuff. So go to jsair.io/email to see previous newsletters and to sign up for the newsletter in your inbox. And then remember next week we're gonna be onsite at ng-conf so the time will be different, so just be aware of that live viewers. And we're gonna have a bunch of people, it's gonna be fun. And, yeah as always follow us on Twitter, Google+, and Facebook to keep up with the latest. And that's it. So thanks everyone for showing up, and I think this was a really great show. So thanks. And we'll catch you all next week!