054 AiA Immutability with Angular with Minko Gechev

02:06 - Minko Gechev Introduction

03:57 - Immutability

05:11 - Why is immutability interesting to Angular developers?

React

09:19 - Side Effects

12:18 - Are immutable data structures in conflict with large quantities of data?

Persistent Data Structures
Immutable.js
angular-immutable

16:18 - How does the track by syntax help/affect you?

19:05 - Angular 2 and Immutable Data

21:30 - Immutable Data and Observables

25:14 - Getting Started

26:26 - Minko’s Background with Immutability

27:36 - The Evolution of Immutability

28:52 - Functional User Interface

29:29 - Data in, UI out

Victor Savkin: Building Angular Apps Using Flux Architecture 32:30 - Case Studies and Examples Where Immutability Has Worked IdeallyPicks

The Little Mermaid Musical (Katya)Primitive.io (Joe)Douglas Crockford: The Better Parts (John)DuckTales (John)Camp Pluralsight (John)Cell Phone Tripod Adapter (Chuck)NeewerHandheld Video Stabilizer for DV GoPro Mini Cameras (Chuck)Michael Feathers: The Deep Synergy Between Testability and Good Design (Minko)

Transcript

JOHN: Player 2 is joining the game...[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]**[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.]**[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures” you'll get a $10 credit!] **CHUCK: Hey, everybody! Welcome to Episode 54 of the Adventures in Angular podcast. This week on our panel, we have Joe Eames. JOE: Hey, everybody! CHUCK: Katya Eames. KATYA: Hello! CHUCK: John Papa. JOHN: Hi! CHUCK: I'm Charles Maxwood from DevChat.tv. We have a special guest this week, Minko Gechev. MINKO: Hello! CHUCK: I know I said that poorly. Do you want to introduce yourself? MINKO: Yeah, sure! My name is Minko, as you said, I'm a freelancer and, in my experience, I love doing opensource, blogging, I used to teach JavaScript[incomprehensible] in Sofia University, and organizing some community events here in Sofia, Bulgaria. CHUCK: Awesome. MINKO: Yeah, basically that's it. And I have some interest in computer science software engineering, not only the practical side, but also the theoretical. JOE: What community events do you organize? MINKO: SofiaJS, and I found out that it's easier to organize BeerJS, actually. You invite people to a bar, you find a company to buy a beer, and it's just much easier, much simpler and people are happier. CHUCK: Cool. I have to ask, what time is it in Bulgaria? MINKO: It's around midnight. CHUCK: Wow! That's dedication. MINKO: [Chuckles] CHUCK: It's just after 2 pm in Utah. JOE: Whatever! His day is just getting started... CHUCK: Yeah. KATYA: [Laughs] JOE: He's a programmer. CHUCK: [Chuckles] MINKO: Yeah. JOE: He still got a good 4 more hours before it's time for bed. CHUCK: That's right. MINKO: Yeah, I just finished my coffee. [Laughter] CHUCK: Yeah, Monday night, I started working on a problem at 01:30 in the afternoon and got done at 06:30 in the morning the next day. JOHN: Oh my god! CHUCK: Yeah! JOE: Was it no fun? Or, was it like awesome? CHUCK: No! JOE: Because it's one or the other... CHUCK: It was no fun. JOE: Oh. CHUCK: It was an emergency deal. JOE: I knew this guy -- it was this back in the day, I'm going to date myself here, FoxPro -- Visual FoxPro just released and I remember the dude stayed up for like 48 hours because he was so [incomprehensible]. CHUCK: [Laughs] JOHN: That's a really interesting story, Joe. But, why are you dating yourself? [Laughter] CHUCK: Oh, dear. JOE: Oh... [Chuckles] Gosh! KATYA: [Laughs] JOE: Can we move right along? CHUCK: Yes! The topic today is, Immutability in Angular. Do you want to give us some idea of where you would go with that and why it's useful to think about it? JOHN: And before you do that, would you mind explaining, for everybody who may not know, what is Immutability? MINKO: Immutability, it sounds super unpractical, initially, I believe so, because you're creating an instance of a data structure, which you cannot change, you cannot mutate over time so you're creating lists of developers, for example, and you cannot abandon your developers to the list. Basically, the concept comes from the purely functional programming languages, and it has broad applications in the modern frontend web development, I believe. JOHN: Do you mean that the data structure is immutable? Or, do you mean that data itself in that structure is immutable? MINKO: The data structure is immutable. And if this data structure is immutable and the sounds inside it, they could be immutable, too. But in our case, we're going to talk only about the immutable data structures, which eventually, mutable items. JOHN: Could you explain why is this big thing? This is a topic that a lot of technologies are focusing on lately, it seems. So, why is Immutability something that, particularly, is interesting to Angular developers? MINKO: I can tell you how I decided to break immutability to Angular 1. Initially, it started by working on React project. Maybe, Sync React in Angular podcast is a dirty work... CHUCK: [Laughs] JOE: [Laughs] No, not all of us... JOHN: We've already cut you off, it's already cancelled. MINKO: [Chuckles] Alright. So, I started working on React projects maybe a year ago. I really like the way they compose the user interface into different components. I also like functional programming languages. In my spare time, I do some Haskell. So, I started thinking about these components as functions because, basically, they can accept some input so they give you an output -- basically, that's what the function is -- and the output is, basically, the rendered UI. So, if you start thinking about these components as functions, it's much easier to get this obstruction. You can go one level above this. You can start thinking about these components as pure functions. Basically, functions which do not produce any side-effects, which do not modify any global immutable state or anything, they just receive their input, just send computations, and produce an output. JOHN: And that's what a pure function is? MINKO: Well, there are 2 things which the pure function should ask: it should not produce any side-effects, and each time, which the function is called with the same set of arguments with the same values, it should also produce the same results. JOHN: Sounds like a basis for Unit Testing, too, huh? MINKO: Yeah, it's perfect for Unit Testing as well because you don't have to handle any mutable states, global mutable states as well. And in React, basically we have this method called "Shoot component updates," which is called each time something changes. Basically, if you have this pure function and this function accepts some input and this input are the properties, basically, you can decide whether the component should update only by comparing the previous input of the function with the current one. And of course, if the input is different, you need to perform a deep equality check. If this input is different, then the component should re-render itself. That's with mutable data. With here, the immutable data comes: when you create an immutable data structure, it cannot be changed. So when you try to modify it, this will lead to creation of a new immutable data structure with the modification of bytes, with the mutation of bytes to it. So, you can decide whether the inputs or meters of the component has changed only by comparing preferences. This makes the shoot component of date method much faster. I thought, well, maybe, if you can take advantage of this in React, maybe, it makes sense to apply the same thing in Angular 1 for speeding up the digest loop. Because the digest loop does something a bit similar on each iteration of the digest loop, it states all Watch Expressions, it evaluates their values in the appropriate context. After that, on the next iteration, it just does the same by comparing the current results of the evaluated expressions with the previous results. If you're using, for example, Watch, and the third argument of the Watch method for adding such listeners is, through you're going to perform a deep check. But if you are using immutable data, you can only perform a reference check, and this is going to speed up your Digest quite a lot. That's why I decided that it might be useful in Angular 1. KATYA: You mentioned side fffects a while back, can you explain what those are? And, link what's some examples of them are? MINKO: Side fffect, this is more related to advantage you can take of the immutable data structures in Angular 2 or React. But basically, if we are talking about Angular 2 and stop talking about React now, if we start talking about Angular 2 and given component performs a side effect, this would be, for example, modifying some global variable or just using mutable data, and one component this way can modify the parameters pass to different components by owning preference to the data used by the other component, these are two examples of side effects. JOHN: Again, why is that such a bad thing? MINKO: In the case of Angular 2, it's quite a bad thing because you can't decide when you need to re-render your UI. JOHN: And, that's a bad thing, right? MINKO: Yeah, definitely. It can make the performance of your app much more... JOHN: Right. In Angular 1, for example, if you make any change, it has to go once to the digest and changes, and it has to go second time and look at all the data again to make sure that none of the data change because of the first change that happened. So, always has to do two passes, right? MINKO: Yeah, that's true as well. And also, the way you compare the data, if you are not using immutable data structures, it is much lower because you need to perform a deep check. Although when you are using immutale data structures, you can perform only a reference check; you only can compare the current reference, you can check whether the current reference of the result of the expression goes to the previous one. CHUCK: And that's because changes occurred by creating a new object? MINKO: Yeah, exactly. That's why I saw that this is maybe not the most efficient way to speed up your digests. The immutable data structures, well, they have some over happened. First of all, we are not completely taking advantage of all the features, which all the good things which the immutable data structure has provide us. And second of all, well, it seems like hack is solution to speed up your digests by creating a new reference to meant this seems quite unpractical. So, I decided to try something different in Angular 1, and it was to make it possible to compare only a few fields of these data structure in order to verify that it's different from the data structure gotten from the previous evaluation of the digest group. And, well, I untackle a little bit deeper into the implementation of the digest method, so this is quite possible so I created a better solution for Angular 1, which does not use immutable data structures. JOE: Aren't immutable data structures conflict with large quantities of data? MINKO: Oh, yeah. JOE: Say, you have a big, big, big list and you need to add one item to the list, isn't there a fight between the fact that it's easy to compare and understand that, "Hey, this list has changed because the reference is now different." But on the other hand, to create the new data structure, which is the copy of the older one which is already big, to copy all those elements and then add the other new element when you create the new data structure. How does that work? MINKO: In Angular 1, it's unpractical, you are correct in this. For my test, I use Immutable.js, and they are using some smarter way for implementing immutable data structures. They are not copying the entire list, in the case here, you suggested, they are not copying the entire list; they are using something called "Persistent Data Structures", which are, well, we can think of them as smarter way for implementing immutable data structures. So, they are not copying the entire list; they are bringing some complex algorithms in order to achieve the same effect. On the other side, it is much cheaper to create -- if you are creating in fairly new data structure -- it is much cheaper to create it compared to the other option, which is to re-render your entire UI. JOHN: Let's compare that a little bit to a scenario because I'm following where Joe is going. Let's say we're in the UI and we take the list of all the results made and somebody, let's say two new items need to be appear, which was sockets connection or through a re-run filter, if it needs to update data structure, from hearing you correctly, we have throw away the hundred objects that we had in that list, and then we re-render a new list that had the 102 in there. Is that what you're saying? MINKO: Well, not exactly. Because here, the Persistent Data Structures come into play becasue there [is] a way to do this in optimized way. There are some very interesting lectures and OpenCourseWare by MIT, which could be checked out. They introduced the Persistent Data Structures and different ways for implementation... JOE: Could you give us links to that that we could put in the show notes? MINKO: Yup, sure. So, exactly one of these ways for implenting Persistent Data Structures is used in Immutable.js, but yeah, you have some performance to work yet when you change given immutable data structures because you need to maintain this Persistent Data Structures in order to get the appropriate result. So, you need to perform for sure application-specific benchmarks in order to verify that this over has this work. JOE: You had said that it's faster to do that, to create the new data structure, even if you are copying data than it is to render your whole UI. Can you explain how it is? Let's take John's example, I've got 100 items, I add 2 more for some reason, now I've got 102. How is it that when I change that data structure to a new reference, I don't end up needing to re-render all 102 new items? Or, 102 items as new and I know that just the 2 that were new are actually new and that's all that gets adjusted when we re-render. MINKO: This depends on how you have decomposed your components. Maybe you have some component which is called, for example, Lists, and you have item components, which are job components of the list. If you pass a new reference with the list, basically, it was going to require re-rendering of itself. And if it's going to pass the separate items to the list items it owns, most likely, you're going to end up only with rendering the two new items, not with the rest 100. JOHN: Can I get back to Angular 1, how does the track by syntax help you or affect this in any way? MINKO: Well, in Angular 1, I don't think we can apply exactly the same strategy. In Angular 1, my optimization was mostly connected with a way to optimize the digest tool only by comparing preferences rather than doing deep check, [incomprehensible] check, or shallow check with watch connection. What was your question again, sorry? JOHN: Like today, let's say we're not using immutable data for now, one possible scenario we could do out live -- we did have 100 rows of data with 10 columns each -- well, that could be slow sometimes where modifying one row or adding one new one somewhere, so one of the things that introduced -- Joe, correct me if I'm wrong -- was like Angular 1.3, maybe, 1.2? MINKO: Yup! JOHN: Where they had a track by on the ngRepeat, which would effectively, as long as you gave the ID that it was tracking by and say, "Hey look, those elements in the DOM shouldn't change, leave them alone, only add or remove the ones that don't match," which was a significant UI performance increase. Now, that's not immutable data structures; that's helping the DOM render where things are going. But I'm wondering if there's some combination of using immutable data structures and that kind of strategy, the track by strategy, that could really help improve performance. MINKO: I haven't got deeper into this. I think it implements in ngRepeat. You will have troubles using ngRepeat with immutable data structures so you cannot use ngRepeat with immutable data structures at all because, well, immutable data structures already know something which ngRepeat knows about. And, I haven't done profiling who are using track by in immutable data so I can't state my opinion on this. JOHN: Right, right. And I'm just kind of pushed the envelope a little bit and think about what are some of the biggest combinations we have with large data structures. It's not usually just one large data structure; usually, it's a list and the most common places those appear are in loops, obviously. So, I'm just wondering if you had seen or thought about anything that could track both, not the data structure performance, but also the DOM rendering? MINKO: I saw that in Angular 2. They are doing some pretty awesome things with [incomprehensible] there, they have special [incomprehensible] for optimization exactly iterating cover large data structures. This could be an interesting read just to scan their implementation of the.. JOHN: Sounds like we've got a great topic to ask one of the Angular [incomprehensible] later, too, to see if something, maybe, that could be extended there. MINKO: Yeah, sure! JOE: Can we talk a little bit more about Angular 2 and Immutable Data and how well immutable data works with Angular 2? MINKO: Well, I was inspired to talk about Angular 2 when I saw the notes after the meet up between the React team and the Angular team. In this meet up, in the notes, I saw that the Angular team is going to implement support of immutable data structures in the core of the framework, which was fun. So, I exchanged some emails with director from the Core team and, really, they have some awesome clouds there. Basically, this is the same concept so we can think about the Angular 2 components as pure function the same way we thought about them in the React's components. If we know that this component accepts some inputs, and with the same input, it always return the same output, we don't need to re-render this components if we pass the same parameters to it. Basically, we are sure that we're going to have the same output by the component, basically, the same DOM, so we don't need to re-render it or anything. We can just skip the entire subtree components subtree. JOE: Interesting. Do you think that we're going to see a lot bigger adaption of immutable data once Angular 2 comes out? MINKO: Yeah, for sure. Victor has some awesome blog post about using observables and immutable data structures in Angular 2. I already saw that DirectJS is in the core so you need observables in order to -- you can use obervables in Angular 2. And probably, next couple of months, we're going to see Immutable.js as well, but I can't be sure on this side, I don't have any additional information, but most likely because we have huge performance benefits. They reduced the number of digest iterations to only one by making Angular 2 only a new directional data flow. They removed the additional rounds of the digest stop, and the only way to increase performace even further is just to not perform this digest at all. And it is possible to reduce it by using immutable data structures. JOE: Hmm.. You mentioned observables... Can we talk about the relationship between immutable data and observables? We're seeing both of those things a lot now and this newer frameworks we've talked about. MINKO: Well, I don't see much [incomprehensible] between them, or I haven't thought about this, maybe. They are closer to promises and callbacks, but with immutable data structures, you just can simply view more funtional UI, which is actually the same for observables. There is a nice library called Cycle.js, which takes advantage of these concepts so I can't [incomprehensible] as well. JOHN: Observables were interesting because one of the first earlier SPA frameworks that was at there which is the data binding templating and all that and is still pretty active is Knockout.js. A lot of that was based upon the concept of observability, and obviously, that's not saying it's built into the language. But curious that, things have come full circle, go back to observables even though they're now more native in the ES6. Do you see more frameworks heading towards observables in the future to support this kind of concepts? JOE: Or, they're heading towards observables and immutability or one or the other? MINKO: Yeah, most likely. Basically, Observalbles, basically the entire observable pattern, it is in core of MVC and in each MV whatever framework, they got very popular recently. But, I believe we've used them, maybe not with the extension which Direct.js introduced, but we've used them last couple of years without getting that much attention to them. JOHN: What's interesting to me, too, is that, with everything, there's a cost. There is no, "Hey, this is a better way," and there's nothing about it that makes you lose anything, at least in technology it always seems, and always, that's your way to approach the cons. But the thing with observability, I always liked it, but the one thing I really liked with Angular, the digest cycle, one is that we had no worries about sitting up special properties, setters and getters, to figure out how to observe our properties. We can literally just take a raw JSon object, map it into a JavaScript, set a code in the controller, and bind it up to a View and, bam! We've got data binding that all sorts of stuff going on. With observability, we now have to monitor and watch observe, literallly, those kinds of properties. Do you see any similar things in immutability that we talked about the positive sides rather than any cons that we had to be aware of with immutability. Or, maybe, not cons, but anything we just had to be careful of? JOE: It's got to be the same drawback, like, you can't just take any raw JSon and it's now immutable; you have to put it inside of a special immutable data structure. Is that true? MINKO: Yeah, or you can freeze it with ECMAScript 5 Syntax Object.freeze. JOHN: Is that enough? Is it simply enough to just use Object.freeze? If so, then, why do we have Immutable.js and all the other tools? MINKO: No, I wouldn't say that. It's exactly the same, which I think the biggest drawback of using immutable is actually maintaining the persistent data structures, the other half of creating the new object, which is what you need is just to do some applications to see the benchmarks in order to verify that using immutable data is the best thing for your application or not. I need a lot of benchmarks for this, and it turned out that in Angular 1, using immutable data structures, it's actually not the best thing you can do when you have collections below 500 items, for example. So yeah, there is some performance or work happened. You need to be aware of it. CHUCK: If people want to start playing with Immutable Data in Angular 1, are there good places for them to get started? MINKO: Yeah. I have 3 blog posts for Angular 1 and Immutable Data Structures. I did a lot of Benchmarks using Benchpress and I published my research at my blog. However, they can take advantage of them, of immutable data structures in Angular 1, and they have to be careful how exactly they are doing this and do same applications with benchmarks, as you said, because Angular 1 does not have also support of these immutable data structures out of the box, so I created a few additional libraries in order to fix this. But, I would recommend to play with immutable data structure with more component-based UI, just like React and Angular 2 providers. CHUCK: Are there good examples of this with Angular 2 then that people can actually go and explore and play with? MINKO: Victor has good blog post in this topic. I haven't seen any sample applications with this... CHUCK: Okay. MINKO: But, it is a nice week end project. CHUCK: Alright, we'll see you get the links to those in the show notes. MINKO: Yup, sure. KATYA: What's your background with immutability and how did you get into it? MINKO: First, I started learning Haskell, maybe, 5 or 6 years ago, and that was the first place I saw what is immutable data structures are. I don't think I really understood how you can take advantages of them. I only knew that it is a purely functional language, you cannot change anything, then the data structures should be immutable as well. But a few months ago, when I started working on my React user interface, I saw that it might be useful to apply the same techniques in Angular 1. I came up with this idea also because I dug deeper into Angular 1's implementation and saw how exactly the digest loop from very simplified version of [incomprehensible] to make sure that I know how everything wires up together. That was the moment when I say, "Well, maybe, using immutable data structures make sense in some cases," and that's it, that's the long story short. JOE: Immutablilty has been around for a long time and I know that years ago, we saw immutability start making its way into languages like Java and C#, and now it's becoming a popular topic in JavaScript. Do you think that's because a lot of people are coming from those worlds into JavaScript to bring it over? Or, is it a reflection of the fact that people are realizing, "Hey, we want to push things beyond what they can do, and we need new ideas"? MINKO: In Java and C#, you can take advantage of the immutable data structures because they are very friendly for concurrent programming. In most new environment, it is good to have immutable data because you cannot have any inconsistent state of the data structures because, basically, you cannot change them. In Angular 2 and in the modern wide UI, I see how you can take advantage of them in a different way, more like the way we use them in the functional programming in order to build a functional user interface, which we can easier reason about and test and also increase the performance by using different framework specific techniques. JOE: Can you explain that a little bit better, that concept of functional user interface? MINKO: I'm not completely sure that everyone uses this term for what I'm talking about, but this is the same thing while thinking about your components as functions and as pure functions, which accepts the input and return the output when they are called for the same input. JOE: So what are the inputs and what are the outputs then? MINKO: For example, in the lists example, the list component who accept list of items and it is going to pass each list item to the item chart component. And, none of this component has any internal states; it only accepts the input and returns the output, just stateless components. JOE: I hear people when I read about React and mess around with React, I hear people talking about during React, there's functional and that the data goes in and the UI comes out. So you can imagine anytime you change the data, now that UI has changed, but it's a very one-way thing, data in-UI out, whereas other MVC frameworks, Angular is a great example. Thus, we think of the UI and the data as this circular; the data changes the UI, then the UI takes actions that changes the data and back and forth in a circle. Is this different thought process of UI data goes in and UI comes out and it doesn't make a loop, which is a Flux, embodies this whole idea, right? Is this something that is important to understanding and dealing with immutable data when it comes to these frontend MVC frameworks? MINKO: Basically, you're talking about Flux and MVC, for example, right? JOE: Uhmm-hmm.. MINKO: Well, in Flux, it's not mandatory to use immutable data structures. There is a broad definition of both Fluxes. According to my implementation, it's not strictly necessary to use immutable data structures. However, I've seen a lot of benefits from using this data structures because of the reasons of improved performance and easier testing. I definitely like this on the directional data flow. There are a lot of people who are applying the same strategy in Angular 1 even, and there is going to be such a topic on Angular Connects, I believe, which is going to be super fun. Also, Victor again, from the Core team, he wrote a blog post how we can use Flux in Angular 1 projects. JOE: Interesting. I haven't heard about that. MINKO: It's fun. I had a lot of troubles by dealing with this cascading updates when you happen to see the View throws. Well, that do not talk about exactly about Angular 1, but MVC in general. Just the model throws an event, the view captures it, the git throws an event for change of the model, like model captures it, and just a wild loop with throwing just random events, which can get quite mazy sometimes. JOE: Hmm.. MINKO: That's why I'm using Flux very recently, and I'm just exploring it and taking advantage of its simplicity. JOE: Cool. Are there any other interesting points that we haven't covered? Any topic? MINKO: I think we already said that there is no beauty in support for immutability in Angular 1. JOHN: Right. JOE: Is Immutable.js, is that the library to use if you want to start learning and dealing with immutabiity inside of JavaScript? MINKO: Yeah, pretty much. I think so. JOHN: Nothing is as good as an endorsement as if you've got some awesome use case or whatever so I know when I go and try to sell ideas, first people will say, "That sounds awesome!" Is there somebody already doing that and see the case study or just an explanation of how that helped them? With using immutable data structures, do you have an examples of places you've used this that's like the hallmark of this made an impact by doing XYZ? MINKO: Based on the benchmarks I did in series of blog posts I co-wrote, you can reason about your applications if you have the same environment asking the benchmarks using huge collections and intensive digest loop iterations, you can definitely take advantage of immutable data structures. And in Flux, I haven't actually seen a new directional data flow in Flux. In Angular 2, it's included in the picture as well. I haven't seen any case studies of the topic. However, the testability is definitely getting much easier when using immutable data because you don't produce any side effects... JOHN: So, what kind of applications have you used that benefit personally? MINKO: We're just building a complex user interface single page application, which is actually quite heavy and it needs to be optimized for performance. And also, you need to have some stable architecture, which is stable to evolve in the future. JOHN: Are these like extraordinary facing applications that you've created and done this with? Or, these internally like more line of business type internal apps? Can you describe what kind of applications that might be ideal for this? MINKO: I think any applications with complex user interface like a lot of components compose together like.. JOE: Like a to-do app? [Laughter] JOHN: Exactly! Exactly! JOE: The perfect most complex app you could possibly build. [Chuckles] MINKO: Yeah. To-do app or either something like with conference communications and chat inside and also some, let's say, to-do's and things like that. Basically, a lot of components, which use a lot of data and strength to optimize actually the user's experience for this. To optimize a performance side of the application. JOHN: Cool! Thanks! MINKO: Yeah. CHUCK: Awesome. Well, let's go ahead and do some picks. JOE: Let's do it! I really like picks. CHUCK: Katya, do you have some picks for us? KATYA: Little Mermaid. I got to see it perform in Hale Centre yesterday and, it was amazing. CHUCK: So, the play? KATYA: Yeah. The play, "Little Mermaid". CHUCK: Awesome. JOHN: I love Disney stuff! CHUCK: [Chuckles] KATYA: Doesn't everyone? CHUCK: I know, right? Joe, do you have a pick for us? JOE: Yeah! I'll also pick "Little Mermaid". I enjoyed watching it. There's some new songs in there, one of which I thought was actually really, really a good song. So I will definitely pick Little Mermaid as well, the play version of Little Mermaid. I also want to mention that I'm going to be doing some training for Primitive.io. It's going to be a 2-day remote classroom, small classroom training on Angular. If you like to level up your Angular skills, this is a great way to do it. I'm excited to do some classroom-type training instead of big, large group training. So, only having less than 20-ish people in a virtual room to talk to. You can register on Primitive.io, and I can give you a big discount for it now. We will be doing it in September. I'm excited for that! Those are my picks! So, I guess, I'm picking Me! [Chuckles] JOE: I pick myself! Pick me! Pick me! CHUCK: Yup. John, what are your picks? JOHN: I've got a couple of picks. For technology side, I want to pick -- Douglas Crockford has a great keynote called "JavaScript The Better Parts". It's basically a new keynote he's been putting together and using recently. I got a chance to see it, and it's really awesome! He talks about how he made the book originally and how it has taken off and have been a best seller for years. But more importantly, I feel like he has made some updates and so he meant some of the things he said and it's something you got to check out. So, check it out. We'll find out if this up on YouTube or not, but if it's not, definitely try to check out Douglas Crockford and the next event he's speaking at. And for the non-technology side, I'm going to pick "Duck Tales". CHUCK: [Laughs] JOHN: It's a TV show I watch when I was a kid, dating myself, Joe, like Joe is. My son has been watching a lot lately, just reminded me a lot of things that I used to watch. It's amazing how it hasn't aged because they're still completely immersed in what do this thing is. And finally, I'll pick -- Pluralsight is doing a Summer Campfire, I think they're calling it. Is that right, Joe? JOE: I have no idea. CHUCK: I said something about it. It look cool. JOHN: Yeah! I haven't really been paying attention. I do write for them, but yeah, I'm tuned out for a while because I was busy at work and I looked up and they're going crazy! They're actually giving away like couple of dozens other courses all summer long, it's a contest. Pretty cool idea! JOE: I can remember what they call it. Is it Cold Campfire, is it what they called it? JOHN: Something like Summer Campfire or American CampFire. I don't know which one it was. JOE: Yeah. But they're giving away 30 different courses or something. JOHN: Yeah! CHUCK: Camp Pluralsight. JOE and JOHN: Camp Pluralsight! JOE: Way to go, Chuck! JOHN: And free learning is always good. JOE: The guy who isn't the Pluralsight author is the one who identified what it was. KATYA: [Laughs] JOE: Speaks well for John and I. JOHN: Yeah, I guess we're persona non grata now [laughs]. CHUCK: Yeah, my Google skills are faster than yours. [Chuckles] JOHN: What's Google? CHUCK: I'm sorry, Lykos. JOE: [Laughs] JOHN: Get off my lawn! JOE: [Laughs] Oh, man! CHUCK: We have some guys talking about how old they were. JOE: Yeah, Lykos! Wow! You didn't even go for something like Ask Jeeves. You went all the way... JOHN: Yeah! AltaVista. JOE: AltaVista. At least, that, a little bit more well known. But, Lykos... Wow! That's... JOHN: Lykos. JOE: That's really way back there. CHUCK: Yup. Alright, I'm going to make a couple of picks here. I had to do some video recording for my sister's wedding on Saturday, just recorded people at the reception, and then recorded her and her new husband at the temple where they were married and stuff. And, I got a couple of things that helped out. One is, I got this clip that holds your iPhone or other Smartphone in place so you can use it as a camera on a tripod, and they worked really well. It costs like eight bucks. So, if you're looking to do some videography and you're not doing big honking, awesome camera stuff, then that will work! The other thing that I got was a video stabilizer. This is something that attaches to the bottom of your camera just like a tripod does. What it is is it has a weight on it so that you can hold on to the handle, and as you move it around, it keeps the camera smooth and steady. It was pretty handy as well. It's hard to describe what it looks like, but I'll put links in the show notes. And then, if you're going to be doing some free hand video shooting, then you can go check it out. JOE: It's like a steady cam for your cellphone? CHUCK: Yeah. JOE: I can just imagine you with a big harness on your hip, and at the end of this big long thing is a cellphone. KATYA: [Chuckles] CHUCK: No, this thing, it's all just in your hand so there's nothing that goes back to your core or anything like that. JOE: Hah! Funny. CHUCK: Anyway, it works pretty well and I was pretty happy with it, so I'll put a link to that in the show notes as well. Minko, do you have some picks for us? MINKO: Yup, sure. Yesterday I watched awesome talk by Michael Feathers who talks about the relation between Testability and Good Design. I want to share this with you. With enough imagination, you can see it's a topic of immutability in this talk. CHUCK: Awesome. I'm a fan of Michael Feathers. Definitely, good pick there. Alright, well, thank you for coming, Minko. MINKO: Thank you for having me. CHUCK: If people want to follow up or see what you're about or anything like that, how do they do that? MINKO: I'm mostly active at GitHub and Twitter so they can find me there. CHUCK: Alright, cool! Thanks, again![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!]