The crew talks isomorphic JavaScript and AngularJS with Jeff Whelpley.

Transcript

CHUCK: Hello! JEFF: Can you guys hear me okay? CHUCK: What?[Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours --  AngularBootCamp.com.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development, Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.] **CHUCK: Hey, everybody! Welcome to Episode 28 of the Adventures in Angular Podcast. This week on our panel, we have Aaron Frost. AARON: Hello! CHUCK: Ward Bell. WARD: Hello! CHUCK: Lukas Reubbelke. LUKAS: Hey, there! CHUCK: I'm Charles Max Wood from devchat.tv with a quick reminder to go check out JS Remote Conf, that’s at jsremoteconf.com. We also have a special guest this week and that's Jeff Whelpley. JEFF: Salutations! CHUCK: Do you wanna introduce yourself really quickly, Jeff? JEFF: Sure! My Jeff Whelpley. I'm a Chief Architect at GetHuman. I've been a software developer for about 13 years or so, working on everything from PHP to Java to .NET to C++. But the past two years, GetHuman kind of focused in on just JavaScript for everything and that’s kind of what we've been building our new platform in. CHUCK: All right. So we brought you on to talk about Isomorphic JavaScript and Angular. And I have to ask -- because I didn’t get a really good idea of this Googling around -- what in the heck is Isomorphic JavaScript? JEFF: So yeah, it's a good question. Before talking about even Angular, let’s just define what Isomorphic is and what Isomorphic JavaScript is. So “isomorphic” is just a term meaning being of identical or similar form and shape in structure. And so we're talking about with JavaScript, it means using the same JavaScript code in different context or containers. And kind of a simple example that is if you just have… let’s just say a simple function of taking in a parameter of a and b, and you add a and b and you return the result. That’s total simple function, and that function, by nature, is isomorphic because you can take that and throw it anywhere whether it's in a browser or NodeJS on the server or in phone gap or wherever JavaScript will run. But with a lot of other things, it's a little bit tougher; like if you're using Angular code, the Angular context is not every place. So when you do angular dot, you need to have Angular bootstrapped before you  can get started. And so Angular by itself, before you do anything is not isomorphic but there are things you can do in order to make Angular or anything else isomorphic so that you can actually run it into those different context. And really, at the end of the day, the goal of Isomorphic JavaScript is sort of creating ultra-DRY code (Do Not Repeat Yourself). And I know we all tried to do that but pretty much everybody kind of inevitably creates either, whether it's a data validation or whatever it is, we end up duplicating code across our environments. AARON: So it goes beyond server side rendering of Angular templates? JEFF: Yeah, that’s the thing is that server side rendering is sort of the thing most people focus on when they talk about Isomorphic JavaScript, but the way that I treat it in… and really when you get into it, you think about it is with all of your code. And render is an important part of that but data is another big part of that; your data models, the definitions and validations involved with it as well as interfaces calling out to API versus the database, as well as routing. Like, server side routing versus client routing is different; you're using your express router versus your Angular UI router or whatever, but in order to do Isomorphic right, you have to create interim or modules that can utilize both of those routing mechanisms regardless of where it is. So it goes beyond just the server rendering. LUKAS: So Jeff, I have seen a portion of this. Obviously I was around the genesis when you started to play around with this idea. In the course of the last year, how much overlap have you actually  got? How successful have you been in this? I mean, it sounds pretty fantastical. JEFF: That’s a good question. If you guys didn’t know, Lukas worked with me on this actually about a year ago. AARON: So that was a softball question. Lukas knows. CHUCK: [Laughs] JEFF: Well, sort of. So at the point where he was working with me, we were in like iteration one of this. And we had figured out some things like the data side was something that we did really good job of while Lukas was there, figuring out how to make all of the data objects Isomorphic that we can use them at different layers. And routing to a degree, but the view layer was still not working and that’s sort of why Lukas was asking that question, I think because we were still duplicating our views. We had a completely separate view on the server versus the client. So the past year, what we really focused on was puling that together. And that was the most difficult part, to be honest, but we finally did figured that out and it's working pretty well now. CHUCK: So I have to ask though, it seems like between the front end and the backend, a lot of times you have different concerns, so is this only the code for, say, certain behaviors that you want to share between the frontend and the backend? So for example, validating something on a data model of some kind. You probably wanna be able to do that on the front end so you can give me the feedback and you wanna do it on the backend so you're not putting crap on whatever database you're using. JEFF: Yes, good question. Even though you're writing everything in this common format, it is true that depending on what container you're running your code in, there are certain things that just, you know, you either need or don’t need. So just as an example of where you might not need something, on the client side, you have a lot of times UI events, user click or some other that is caused by the user doing something; whereas in server, that’s not needed at all. So even though you create a common format for the HTML in the template so that it can render in both places, on the server side, it's much simpler to be quite honest because you're just doing the initial state -- the initial render -- and you don’t have to even worry about the other stuff. Now as far as data validation, that's definitely something that is done in both places, but how it's actually implemented could be different. So on the client side for using Angular, you could utilize the Angular form validation controls whereas on the server, you might have like on Mongo and Mongoose, they have a way of doing validation with Mongoose, right? But you can write your code in sort of a configuration format where you're just writing, let’s say, for a given model, like let’s say the model is called “user” and in your user model, there is a field “user name” that’s required and has a regex and some other validations. You can write that from a developer in a very formatted, totally agnostic of what container it's in just a simple configuration. But then once you have it running within a container, there are adaptors that hook into it. And that’s part of building an Isomorphic framework is that you have to have container specific adaptors so that on the client side, that validation will automatically generate an Angular form validator; whereas on the server side, you were hooking to Mongoose. But from a developer stand point, you don’t even see that stuff. That’s part of the framework itself that actually implements it in those two ways. I'm just writing something in a very generic format. Does that make sense? WARD: I'm still trying to understand the value proposition, Jeff. And by the way, I hope on the show notes we put the link to your PowerPoint or your slides or whatever because that’s very helpful in sort of framing and filling in. And so I'm thinking about what you're striving for and I'm trying to find out when I would need what you're talking about because… of course there are extremes; at one level, there are certain kinds of things that there’s a great slide you have of the eight things that you really target, and I get security overlap of some code and security of data validation, possibly, model definition because you kind of want those things to be symmetric and if you’ve got JavaScript on both sides great. But I can’t figure out why I'm going to bring, essentially, attempt to even fake executing the entire application on the server. Can you tell me why that would be  important to me? JEFF: It's a very good question. You're not faking the entire application right off the bat. It's just a portion of it because you're trying to render just the initial state of a given route. So let’s break this down into two primary motivations for doing Isomorphic JavaScript. One motivation is develop productivity; the other is to make your users happy. So for the developer productivity, it centers around what you kind of started to talk about, Ward, which is you're eliminating duplicated code; you're making things DRY; you're trying to make yourself more efficient. Now, when I talk to other developers about this aspect of things, it sometimes gets debatable because these people argue that just copying and pasting in certain circumstances or having some small level of duplicated code, like the effort to do Isomorphic is not worth getting that ultra-DRYness. In that aspect, I think that in some cases that might be valid. For my own personal experience, the past year of doing this has been my most productive year as a developer because of this sort of approach. So I can’t speak for everybody or every situation, as far as kind of productivity, but I just know from my own situation, the way we've been doing things, there's been a huge increase in productivity from a developer stand point. But the other reason which was actually our primary motivator to begin with. So we didn’t do this initially thinking, “Oh, we wanna be ultra-productive.” We did it actually for our concern for our users. And specifically, that is because we have a consumer facing app, which that makes a big difference whether it's consumer facing app versus just internal. And so a consumer facing up where most of our traffic comes from search engines; most of our traffic comes from people Googling us. They don’t know who we are. We are on the top of search results and they come to our page. And so in that situation in particular, there's the extra motivation for Isomorphic JavaScript because server rendering is so important. And again, there's many reasons why, since we started this, that have been huge benefits but the initial motivation was doing server rendering with an application and combining that with a rich application that also has kind of many of the modern features that you normally have with the single page applications, so we do things in real time and have it as a very rich experience. And so combining those two, you really need Isomorphic JavaScript. WARD: I buy the SEO argument, although I heard that Google has something out that’s supposed to… JEFF: I'm glad you brought this up. WARD: So I want you to get there, but if you take SEO off the table and maybe you know, that initial page load so the application appears to be doing something (which you can do with a splash screen, let’s face it), I'm still not clear about why it's of utility, right? Because once I'm in the app, if it's my bank account app, I mean, I don’t really do SEO over my bank account, right? I'm not interested in having Aaron search in deep link into my bank account. AARON: Why? I got four kids. I need your money! WARD: [Laughs] So I'm curious about it. But, okay, you’ve got a consumer facing app, that’s critical; you need SEO, that’s critical but beyond providing whatever people are supposed to search, how am I supposed to get excited about this and then you can tell about Google solution for SEO. JEFF: Definitely. So it depends on the situation. The one you described as a bank app is not exactly the sweet spot. So the sweet spot for what I'm talking about is when you have a consumer facing app that really depends on people coming there for the first time -- either organically or through ads or whatever it is -- where they don’t necessarily know you are and they very often have a high bounce rate, if you don’t do things right. And in that case, there’s many studies out there about how important the initial page load performance is. So it doesn’t matter once your application is loaded. I mean, this is typically the case with a single page application -- especially in Angular page application -- that after the initial bootstrap and page load, typically it's pretty fast because you're kind of navigating around. But the reality for many websites, and really, for all of ours, is that a large majority of users don’t get past that first page load. Like if you don’t get them on the first page load – capture them somehow -- then they are lost. And so in those cases, initial page load is hugely important. And in fact, Google has done a lot of studies about 250 milliseconds for actually seeing something on the screen, is the difference between whether it's much less than that or much greater has big impact on your user retention. Now you brought up putting a splash screen or something like that and that’s actually a common trick, right? For putting up something that’s not the actual content but just like okay, something is loading or whatever. And that works sometimes -- again depends on the app -- but the power doing Isomorphic JavaScript is when you go to a page that’s rendered on the server and then having the client kind of take over is that it kind of instantly appears. There's a net positive effect to users when they see that kind of pop there and it's just all there. It's not a waiting page or a splash screen; it's the actual content. And then the actual interactions and client side stuff doesn’t kick in until… your bootstraps but as the user has looked over the initial page and it's ready to go. So for something like that, like our use case, it is the difference between life and death or whatever [chuckles]. But yeah, for a number of applications, I can totally see that it doesn’t make as much of a difference. WARD: I understand that. I understand the initial load case and the what you're describing, you know. And I'm going to bracket the question of why it is that a server, at a great remove is capable of composing a page and delivering it faster than I can compose it on the client, when I'm receiving less data. And the block there is how fast can I have the traffic over the network I would have thought. So I think that’s an interesting question in it of itself but let’s bracket that and say, “Yup, if the initial page load is your issue, you may really want to have server side rendering for those initial arriving pages.” Tell us, from an SEO perspective though, which is different, tell us a little bit about that Google business that were supposed to be at the end of 2014. JEFF: Just tacking on to performance, performance is really big for SEO; it's one of the biggest positive signals that Google on page positive signals… that Google takes into account. So even though Google is indeed indexing some client side rendered HTML, the fact that most single page application still take a while for that initial page load has an impact on SEO. So like, you can get around that. There's ways to like make your Bootstrap process faster and optimize that, but for most people starting out, that isn’t the case, right? Now, taking performance aside, one thing I would say is that eventually, there's no doubt that client side render will be totally sufficient for SEO and there won’t be that big of a difference whether you're at the server side or client side app, but right now it's not the case. So if you look at any competitive search terms, especially like ecommerce, let’s say like something you would look on eBay for, it's all server side rendering… websites at the top ranking. Like the moment that a client side rendered application beats one of those server side websites for one of those competitive terms like ecommerce like buying a TV or something like that, then that's like our signal of like, “Okay, we can forget about server side rendering. It's all going to the client.” And I mean, there's a lot of subtleties to like why that’s not the case yet, but really, what it comes down to is that Google depends on our visual intelligence. Our visual intelligence depends on a set of learning data; data that’s learned over time. And the amount of data that it has for client side rendered apps is minute compared to server side rendered websites. So they have distinctive edge just because of the fact that the search algorithm is just… no one understand server side rendering websites so much better, but they’ll definitely grant you that, eventually that will change. Eventually it will be perfectly fine to just [inaudible] a single page app. But I don’t think that will be still for another couple of years, at least. CHUCK: All right, I'm going to change topics a little bit and head us more into the direction of Isomorphic JavaScript and AngularJS. And so how do the two mix? JEFF: Okay. So when you're talking about how any framework kind of implements Isomorphic JavaScript, it can occur like built-in in the framework itself, like React is a good example of the framework; just by the nature of the way the framework works is very good at rendering on the server and doing things isomorphically but other frameworks like Ember or Backbone, they can be rendered on the server and you could have Isomorphic components but they usually require a little extra help. So that’s why Ember, they’ve written a new component called Fastboot and Backbone has another library called Render. And so those extra kind of add-on components help with the server side rendering and some of the other component that go along with it. For Angular, when you try to do that, there's some things about Angular that actually surprisingly make things not too bad; namely the fact that anything is depending on dependency injection. That actually allows you to create something on the server side utilizing dependency injection that kind of switch things in and out. The tough thing, and really the big challenge is the fact that Angular routing depends so heavily on the DOM. Like the templating engine for Angular reads the DOM. It doesn’t read like [?]string like most other frameworks have like a template like a handlebars template that produces [?]string or whatever and that’s much easier to deal with, right? So for Angular, when we started looking at this, there's kind of three phases we went through. One was that (and this was way, way early on. I mean, before Lukas was working with us) that you can try to I could just put Angular in a box, like using a headless browser and kind of just let it generate as if it's on the client side with something like PhantomJS and capture that HTML and reuse that for your server side. And that works to a degree. And that’s what like sites like Prerender.io use, but there's lots of problem with that mainly the performance is terrible. It's something that you couldn’t use in real time and at runtime, you’d have to cache the pages and then you run into lots of issues on how you manage all your cached HTML and that type of thing. So that thrust wasn’t going to work. And so the next thing is try to do something like Ember is doing now or like with Render and Backbone, which is to build something kind of within the framework  work alongside it. And actually, this is something when I talked to Matias about this about a year ago, he was strongly an advocate of doing things this way. And I tried to do it. I tried to essentially override certain components within the Angular framework in order to render stuff on the server. And maybe it's possible I guess, but I eventually stopped after I realized that I was going to practically rewrite the entire framework [chuckles]. It just was getting too messy and just was not going to be something that would be sustainable. So we ultimately ended up on -- which has worked out extremely well -- is to have a sort of preprocessor. So what that means is you have your code in a NodeJS format so like a server side format and then you utilize an adaptor, (what we call a “transformer”) to essentially build your build step the Angular code. So essentially, all the Angular code that we use on the client side is generated; auto generated from our kind of common format. And obviously, that common format has an adaptor on the server side that knows how to handle it. So that just kind of understanding that like all of the elements like data and routing, we were able to come up with easy ways of translating one or the other. The tricky part again was with the view rendering. The key for that came by creating our own template abstraction that is called Jangular, which looks a lot like the react.dom functions for rendering in React. It sort of looks like that. It basically functions that mimic or match each of the different kind of HTML elements and you can string them together. And by utilizing that and having our templates in this Jangular format, that gives us the abstraction we need to make that sort of switch of building out on the client side, a Angular template and Angular code and then the server just kind of naturally building that in the way that can be used in… well, really whatever server side framework you're using. We happened to be using Happy.js on the server but you really could use whatever. Does that make sense? AARON: Yeah, it does. WARD: It did to me. And looking at that code snippet that was on your slides, that one really reveals it and it does look very React-like. I guess React wasn’t around when you started. I hear something about mixing Angular and React. Did that ever occur to you or was it just too late? JEFF: Yes. So like two years ago when I started, it wasn’t around and there really wasn’t any good Isomorphic framework around. There’s Derby, Meteor, but like they weren’t that good at it, even though they sort of did it. So I decided I was going to just make it work with Angular and since then React just come out. And there was a time where I thought about switching, but I did a really deep analysis and what I came to the conclusion of is that all the stuff that they were doing in React, you can pretty much do it in Angular too. So I tried to essentially take the best of both worlds and take the best pieces out of how React works and sort of bring it to Angular. WARD: Yeah. I can see how that might be, because unlike in React on the client, you don’t have to worry about detecting DOM changes and caching that and all the trickiness that they do, you just have to render it once and send it, right? JEFF: Yeah. WARD: Yeah, that’s really the hard part -- the scary part -- about React is all the work they do to compare fictive, imaginary DOM images. And fortunately you don’t have that. So that made sense even though it made me feel squarely about putting logic in JavaScript. JEFF: What's interesting with that is I did actually… there's a way to actually do a virtual DOM diffing in Angular. Like it sounds weird about that, but to be honest when I tried it out, I didn’t find any performance gains. It wasn’t worth it. So I do have certain kind of constructs in there to do something somewhat like a one-way data flow like in React, but I still use data binding; I still use a lot of the Angular constructs, so it's really kind of a different hybrid of different stuff that I'm kind of bringing together. WARD: That makes perfect sense. Were there any stumbling around… I always try to imagine how to do it. From my perspective, the things… because I don’t do stuff that’s consumer facing, but I do care about having the same data validation and some model definition and utility. Some of the set of things that you mentioned that have value on both sides, when I call them for the browser’s side, I’m usually tied in to the whole Angular framework and all the components and modules and stuff like that.  How easy was that to transport or execute on the server? Did that get out of your way? Was it in your way? JEFF: Actually it worked out great because all of our data, we almost write no code for on a daily basis as we're making changes and that type of thing, because we rely on… maybe it's a [unintelligible] but we use this resource file, not an internationalization resource file, like a file that basically contains a configuration for your data objects. So it will contain these fields and it uses these validations and it even has like security stuff in there -- all in just a big config file format. And then you have a bunch of adaptors that kind of work off of that resource file. So just like an example of some of the stuff like on the API side, we have an adaptor that works off the resource file and automatically generates API end points. Similarly on the Angular side, we have the Jangular process that generates all the Angular code, will look through this resource files and automatically generate API clients. And in that way, when you're using the Angular code, it will use the similar interface or the same interface, really, that’s on the client server and just behind the scenes, it will know that, “Okay, I'm on the client, I'm making an API call,” versus on the server, it knows among the server, I'll call the database. And so for validations, specifically using the Angular validators, that auto generation process has a thing that looks at the validations and will automatically generate a series of custom Angular… well, not all of them. Sometimes it hooks into the built in Angular validators but for a lot of stuff, it will build a custom Angular validator and then in our forms and that type of thing, in our templates rather, you can reference those just like what you normally do in Angular. Does that make sense? WARD: Yeah. And at least that's a clue and I can go look at your stuff and see how that works. By the way, are you publishing your stuff? Is it available out there where other people can look at it? JEFF: It's all available right now. I don’t think it's ready for other people to use quite yet, so it's something where… and I'll put it in the show notes and people can certainly kind of look through and even try some of the parts out, especially the lower level libraries like the stuff that is pretty solid like the template generator is pretty solid and couple other pieces, but some of the higher level stuff a little bit probably too much influx to utilize. But yeah, I'll maybe put some links in there and make sure I update the documentation, so if anyone wants to check it out, you can see what I mean. WARD: That's cool! Hey, Jeff, have you talked to the Angular team about what you're doing and have they thought about what they are going to do to cover this ground in 2.0? Do you have any insights on that? JEFF: Last time I talked to them was ng-conf last year and the message I got then from when I talked to Brad and Misko was that during the 1.2, when they were building Angular 1.2, they tried for a while to build out a server side rendering component within Angular core, and they sort of gave up on it just because it wasn’t turning out to their liking; it just went against some of their philosophies I think. And also I think just Angular as a whole  is trying to push really for the client side stuff. They want the web to really move towards being client side only. And that’s fine for them and they are trying to kind of push that just its general philosophy but kind of the reality of [inaudible] this is still very relevant for a number of companies, which is why… and I explained kind of what I was doing and they were very encouraging but I didn’t get any sense that they were going to do it themselves. And as far as in 2.0, they are not definitely doing server rendering from what I've seen but I’ve talked to Igor a little bit and some of their components actually are built in a way that can be used a little bit more Isomorphically. So one example of something that I'm trying out now that seems to be working is the new dependency injector for 2.0 is actually to be able to use on the server side as well. So that’s kind of cool. I built my own dependency injector to use on the server side for now, but I might be switching over to theirs once 2.0 is more solidified. WARD: That makes you the man for now! JEFF: [Chuckles] AARON: The DI [inaudible] part of 2.0 it's all ready. We're using it for some app at Domo. And so their dijs, that’s actually ready for people to begin using and dropping in. JEFF: That's cool. AARON: Yeah. CHUCK: Yeah, that’s good to hear. All right, anything else that we really need to cover before we get to the picks? JEFF: One last thing I was going to mention that we didn’t talk about is there is one kind of cool side effect of all this, not for everything but for a certain code, I'm able to test what's really client side code on the server, and you know, again, it depends if you need to… sometimes you want to have the client side dependencies when you're testing so that you actually run it in the context of the client, but for certain things you don’t need to. And because everything is in this common kind of server side format even though it’s ultimately client side code, we can run our tests without Karma or kind of the browser and that makes them faster; makes them easier to run. And we've seen it kind of make our code like more stable. So that's kind of the one cool side effect that we didn’t talk about. CHUCK: All right, let’s go ahead and do some picks. Aaron, do you wanna start us off with picks? AARON: I’m going to pick woot.com because I’ve just got a new TV and it's almost in town and I'm pumped about that. So that’s my pick. CHUCK: All right, I forgot to ask, we usually ask Joe if there's any news about ng-conf. AARON: Ng-conf, I don’t know about news. It's going to be amazing. If you wanna like host a remote viewing party, go ahead over to the site and sign up. By the time this podcast is out, there will be a map for people to go and like see all their local remote viewing parties if there are any, so maybe you can go join one and get a t-shirt while you're there. The site is going to be updated with a lot of those ng-conf extended updates so that you can discover the meet ups around you. And also, if you don’t have one, be confident in creating one, knowing that there's not already one in your area. So that’s the only real announcement that we have. Other than that, if have tickets, book your hotels because the hotel rooms are almost gone. CHUCK: I also wanna point out… I don’t know, this might be a little premature, but Joe finalized things with me at least so that we could do an Angular episode at ng-conf. We will be doing that [inaudible] one of the days. So keep an eye out for that. If you like the show, then you can like it at ng-Conf. AARON: Yeah, that would be awesome. CHUCK: Yeah, I’m excited. AARON: Got to use stickers with you, man. CHUCK: Stickers! Yeah, I do. Of course one other thing, and I just want to kind of give a pat on the back to the ng-conf organizers -- Aaron, Joe and the rest of the gang, as well as the organizers of the Mountain West Ruby and JavaScript conference -- they actually scheduled themselves around each other which is very convenient for me since they are all in Salt Lake and I usually attend Mountain West. So Mountain West JavaScript is two days before ng-conf and Mountain West Ruby is Monday and Tuesday the week after. JEFF: Chuck, that’s actually when I met you for the first time is at Mountain West JavaScript last year. CHUCK: Awesome! I thought you sounded familiar. JEFF: [Chuckles] CHUCK: All right, Ward, what are your picks? WARD: All right, from a technology perspective, I wanna say that I'm finding Gulp increasingly part of my life, and it's kind of interesting, there’s a Gulp 4 on the way. [Laughs] Because just what we need is another version of something, right? But by the looks of it, it handles a very important problem which is parallel tasks, coordinating parallel tasks and also, it's not a hard conversion and John Papa will be talking about that at some point. But it's there on the horizon and it looks good, but you'll be able to keep running your Gulp 3 and Gulp is really good stuff. My non-tech thing -- and this is really odd --  is a kid’s movie, Paddington which I saw with my niece. And I have to say that that keeps an adult entertained while it gets the kids absolutely riveted to the screen. Nicole Kidman is a little on the dark side, which is the way I like her but… CHUCK: [Laughs] WARD: But totally scared the kids. CHUCK: Very nice. It's not as dumb as the previews make it look? WARD: No. It's got some cleverness. Remember [unintelligible]? They always had lines in there for, I mean, I say it's like that but they always had lines in there for adult that the kids missed but made it tolerable for us to sit next to an eight year old and watch something. CHUCK: Awesome. All right, I'm sure I have pick. Oh yeah, Slack. So, I have a new client that wanted to use some kind of chat room which I've setup for clients before, but they never actually used them. This client seems to actually using theirs and we're using slack and it's awesome. I've also used Flowdock, IRC, I've looked at Gitter and a whole bunch of other ones out there but slack is just being awesome. So I'm going to pick them. They also have a Mac app and an iOS app, which means that I can kind of keep tabs on what's going on that with that contract as I go. So anyway, that’s my pick. Jeff, what's your pick? JEFF: I’ve read an awesome article on Medium the other day called What I Learned About The Future By Reading 100 Science Fiction Books. Basically, this guy just read lot of the most prominent science fiction authors, a lot of their most recent books. And he not only kind of coalesced a lot of their predictions in the future into this kind of one overarching, “this is what's going to happen in the future” which is kind of interesting, but then he also talks about how the process of creating science fiction is actually important for envisioning and building the actual reality of the future. So it's just a super interesting article and I highly recommend it. CHUCK: All right. Well, I don’t think we have any other announcements. I am toying with the idea of putting together kind of an in person meet up out here in Utah, probably in Park City or something. So if you're interested in coming to something like that where we just kind of get together, have some dinner together for an evening and then maybe rent a  conference room or something somewhere where we can kind of a hack night or just chat, then shoot me an email chuck@devchat.tv. Otherwise, have a great day and we'll catch you all next week![This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]**