Learning AngularJS: The AngularJS learning curve | Episode 7

Full Transcript Craig McKeachie: [0:00] On this episode, Sean Fioritto and I discuss the AngularJS learning curve, and why he thinks it's so nasty. [music] Craig: [0:16] Welcome to "The Front End Developer Cast," the podcast that helps developers be awesome at building ambitious web applications, whether you're a JavaScript ninja, or you're just getting started. I'm your host, Craig McKeachie. [0:30] Hi, everyone. My interview today is with Sean Fioritto, and we discuss the AngularJS learning curve, why he thinks it's so nasty, and how he goes about making it easier to learn. [0:39] We also discuss Angular in the enterprise, and why he thinks AngularJS is great when you're dealing with large enterprise code bases. [0:46] Let's get into the interview. [0:48] Hey, today I'm lucky enough to have Sean Fioritto with me. He's the author of "Sketching with CSS," which you may have heard about throughout the Internets, and he's more recently been focused on doing some AngularJS training. That's why I wanted to have him on The Front End podcast here. Welcome Sean. Sean Fioritto: [1:05] Thanks Craig. Thanks for having me. Craig: [1:07] I also heard that you perhaps may have been lacking some sleep recently. Is that true? Sean: [1:13] Yeah. If I randomly forget words or get words mixed up in the middle of this, it's definitely sleep deprivation. We just had a kid, Isaac. He's our first. He's four weeks old yesterday. Craig: [1:26] I do remember those times, so I will try to edit out any of those parts where you forget to tie your sentences or things like that. I feel for you. Congratulations. Sean: [1:37] It's hard to keep track of anything. It feels like one blurred day since we got back from the hospital. Craig: [1:42] Well, congratulations. Sean: [1:43] Thank you. Craig: [1:45] I wish you luck in getting out of this time. [laughter] Craig: [1:48] Surviving, that may be [indecipherable 1:50] . [crosstalk] Sean: [1:50] I heard six weeks is the magic. Everybody keeps telling me six weeks it gets a little bit better. I'm just crossing my fingers and don't tell me that that's not true. Craig: [1:57] You know what I wish people would've told me? [2:00] My sons are now five and eight. My one's going to kindergarten, but long story short, I wish people would've said it does get easier because it's pretty hard when they're young and I wish somebody would've said, "Yes it's going to get easier." They all just look at me like it'll be OK. You'll get through this, but they wouldn't say it's going to easier because that's what I really wanted to hear at the time. [laughter] Craig: [2:22] I'm telling you it's going to easier. Sean: [2:24] Good. Thank you. Craig: [2:26] Anyway, we're going to talk Angular today. One thing that was interesting when we were chatting back and forth was you talked about the Angular learning curve and I was definitely concurring and remembering the early days, which wasn't so long ago for me either of learning Angular. Tell me what your experience has been like with that. Sean: [2:42] Well, in addition for it being tough for me to pick up Angular...I'm an experienced developer. I've been doing this for a really long time, and I've been doing JavaScript for six years, and working with really big, gnarly enterprise JavaScript code bases. I'm comfortable picking up new frameworks, new technologies, but Angular was particularly tough. [3:03] It's tough for everybody, it's kind of the common denominator, which, quite frankly is why I'm doing Angular training. There's so many people that...The learning curve in Angular is particularly vicious. [3:18] It would be nice if somebody bundled up the hard bits, pulled it together, made some sense of it, and cut the time down to learn it. The thing about Angular that was tough, of course, it goes to their documentation, which is better now than it was in the past. [3:35] I evaluated Angular years ago, and one of the reasons I dismissed it was, A, it was a little weird, because there was all this code in the markup. I was at a Microsoft shop, and I really hated ASPX's, and all the problems we'd had with putting a bunch of code in views. [3:52] I was like, "That's just weird. I don't want to look at it." Plus, it looked really "Microsoft-y," and I was rebelling against the Microsoft-y stuff at the time. So I thought... Craig: [4:00] Right. Sean: [4:01] I get it. Craig: [4:02] I think a lot of people were burnt by the various tags that Microsoft created, data source tags... Sean: [4:08] Yup, exactly. Craig: [4:09] It was like, "Oh, this is a good idea to put your database code in your view!" We can say we've written zero lines of code. We've written a lot of lines of markup, but zero lines of code. I think people still were stung by that and remembering, this is not a good thing, necessarily, right? Sean: [4:25] Exactly, and there was so much magic behind some of those things. It would just do surprising things, and have surprising effects down the line. You'd get something working fast and you're like...oops. And we don't know what's happening. [4:39] Worse, a lot of shops have inexperienced developers working at them, and that was...our company was no different in that respect. There was a lot of code being written without oversight, and things are getting used incorrectly. [4:54] It's real tricky when you have that...that level of abstraction is scary to me, anymore. I've always recoiled when I see something like that, and Angular was no different. [5:03] You look at that first "Hello, World!" example, and it's like, "What is that! That looks iffy." [laughter] Sean: [5:10] It's not like that, it turns out, but the other problem was, when I was looking at it, way back then was that docs were just ridiculous. They were pointless. Craig: [5:20] When you said they've gotten better. I definitely think, not that the training such as my book and your training are still much needed in the space, because it's a complicated topic. [5:30] The funny thing about it is I remember they used to have comments at the bottom of documentation. It was like going back to before stack overflow or whatever where you'd have to read through seven people's comments to actually get the answer to the documentation. I know it was just hilarious. [5:47] They have seemed to have cleaned a lot of that up. It was sometimes infuriating, but sometimes it was really actually funny. Depending on your mood, you would actually think it was funny and then sometimes you just get mad and say, "This is ridiculous. I'm hanging up my boot." [laughter] Sean: [6:04] Totally true. The docs were truly terrible. They're infamous actually for being so bad, but they're better now. The problem is they're not, in my opinion, better in a useful way. Craig: [6:15] They're not pragmatic or practical. Sean: [6:17] For learning, they're not better for learning Angular. It's still a terrible place to start off when you're learning Angular. That's a big mistake to start at the docs if you're learning Angular. [6:29] They're really comprehensive now, which is great. They're still parts, I still even recently found myself looking at code to figure out what was actually happening, but they're good enough to investigate that built in directive to see what you can do with that thing and that's good. [6:44] The problem is they document really well what is happening, but not why they do anything. They're totally missing a lot of context. [6:55] When you're trying to learn something like Angular that has a lot of potentially, depending on your experience, background or whatever, a lot of strange new concepts like dependency injection for example. The first time you see dependency injection, which is what happened to me. [7:14] I looked at it and I kept reading through the basic hello world application and I kept seeing examples of all of a sudden they're including different parameters in these functions. I'm like, "Where did that even come from? How can you even do that? You can't change the API of a function like that arbitrarily and there is no explanation for it. " [7:35] Angular has a lot of gotchas like that. [7:38] The other thing they totally screw up, in my opinion, -- I shouldn't say it like that -- The purpose of the docs isn't to get you from A to B in learning, but even in their tutorials they have also failed to do, is they gloss over this what is the most important thing about Angular, that it's really a very modular framework and it's all designed around creating directives. [8:00] You have to know about directives, how to make them and how most of the basic built in directives work, otherwise you're going to be in trouble really fast. It's just going to be confusing really fast. [8:13] That's the pitfall, that a lot of people get stuck in Angular as you start off just using the built in directives without really knowing, like, how does ngBind work? How does those little " [indecipherable] " work? What's the digest loop, without any knowledge of how that works? [8:30] You can get pretty far with an Angular app that way without knowing what's going on, but pretty quickly you'll run into trying to think through, like, "Where should I put my code? How should I organize this Angular app?" [8:44] Then, you run into performance problems because you don't understand the digest loop and how many watches you have when you're using ngRepeat. [8:52] Most of the problems I see that people run into with Angular, the most common questions come from this failure, at least, of Angular to peel apart the more modular components that it's made of and explain the philosophy of Angular. Like, "How you should be able to use watches and how you should be able to use directives and create your own declarative language in your mark up and that's the power of it." [9:17] No tutorial that I know of, except for mine, actually starts there with those core components. That's, in my opinion, the Angular learning curve is right there because you can get so far with the built in directives without knowing what's going on and they encourage that. Craig: [9:32] Right. You take a more foundational approach, it sounds like, "What is a directive? How do you build one from scratch?" Then there's something that already is a directive that is built into the framework and now you have a better understanding from the core of how that works. That's a great approach. Sean: [9:49] Right. Exactly. You got to understand the digest loop. You have to understand watches. You have to understand injector. You have to understand how Angular pulls all these things together and how to create a directive. Those are the key things. [10:01] As soon as you get that, it's like all the problems that you see people running into you understand why and you can figure it out yourself. Craig: [10:09] How do you like to think about the digest loop? Can you elaborate on how you think about it and how you finally cracked that concept? Sean: [10:16] So, the first time you encounter Angular updating the page automatically, you're like, "Whoa, how's it doing that?" [laughs] Craig: [10:24] Right. Sean: [10:25] I've created frameworks like this in the past at my company. Little mini-frameworks that I've made for myself to create prototypes really quickly, and also to help push my managers into a modern approach for building our web applications to help us eventually solve some problems we were having with our large JavaScript code base. [10:46] I'd built a few things like this before. The way I'd done it was like, basically intervals, or I'd done it with like special models where you have to inherit from a model and then you have to special getters and senders "XX". I wasn't seeing anything like that with Angular, I was thinking that maybe there was an interval. [laughs] [11:01] Maybe they're like, continuous polling my data in the background, but I still have no idea how that's actually happening. It looks like I just have a regular JavaScript object. I was like... Craig: [11:13] How are they getting the data in your model to bind to the UI is what you're really getting at, like "How's this magic happening?" [crosstalk] Sean: [11:19] Yeah, exactly. The really simple way of doing it would be, if you were to implement it yourself, for example. If you would want to have this notion of "Whenever I update my data model, my view knows about it." How do you do that? [11:32] You can do that by having special setters on your model, on all of your model. So anytime you change it, you have to use the special setter and that way it actually updates the view. [11:41] In fact, this is how I explained it in my class as well. Like, "OK, Angular isn't doing that, so how are they doing it?" The way they do it is pretty cool. [laughs] [11:50] In my opinion, I would've never thought about this. It's the notion of dirty checking which, by the way, am I going to be explaining something that everybody knows here, or is this something like? [laughs] Craig: [12:02] I don't think so, I think this is a podcast for people that are new to the framework, or for you, know people who are deep in it. It just depends on which episode that you listen to. The kind of stuff you get. I think even people who have used Angular quite a bit. [12:17] In my opinion, it's always nice to hear from a different perspective, like, the digest cycle or watches described a different way, because when you understand, you know when you think back through your programming career, if you've been there a while, some of the best teachers that I've ever seen, or whatever, usually go to a very low level. [12:37] I can remember when ".Net" first came out. Someone taking a "Hello world" app that was just consoled at right line. It was Jeffery Richter, who's famous for writing very low-level books on C#. He spent the time on this user group I saw him at with IL [indecipherable12:56] , how it was rewriting the byte code and so forth. [12:59] I think, at some point, you don't really need to know that, but, it's like you need to understand it. Once you understand it, then a lot of things become easier to troubleshoot and so forth. So, I really love this kind of stuff. Sean: [13:11] I agree with that. Craig: [13:12] I agree with this kind of stuff. Sorry for the tangent, but I like this kind of stuff. Sean: [13:15] OK. I think you do absolutely need to know how the magic works, and that's the thing that I like about Angular is that there's a lot of magic. But, it's really straight forward in how it actually works. [13:27] It's like you're actually wasting your time if don't bother to figure it out. You know it's better just to figure it out, because it's not that complicated. That's the case with the digest loop, it's like this awesome idea that...You know when a JavaScript app...When nothing's happening. Nothing's happening. [13:43] You don't need to be checking if anything's updating. There are only like a couple times where you need to see if something changed, like when there's an event or like any synchronous callback, you know from an AJAX caller or like a set timeout or set interval. [13:56] Those are the only times where you need to actually see if there's anything in your model has changed and you need to update the view. And, then, of course, as the developer, you know the pieces of your model that are bound to the view. [14:08] What Angular does is give you, in an explicit way, to say, "OK, these are the things that could change and then every time that one of these events happen, where something could have changed, check to see if it's changed". [14:21] Basically you set these watches and you say, "Watch this value on this object," and say "Anytime where there's something could have changed, check to see if it changed." So, Angular remembers what the previous value was, and anytime it hits one of these events it goes through what's called the digest loop and it checks through all the watches that you've set up. That's really... That's it. [laughs] [14:42] That's what's happening with those built-in directives that you bind with the ngBind with the "[indecipherable]". That's all it is, they set up a watch. They're using that built-in functionality. [14:53] The reason that you need to know about the digest loop, if you're using Angular, is because, eventually your code is going to leave Angular. Then what's going to happen is your model will update, but the view won't, and if you don't know what's going on, you won't have any way to figure out how to fix that. [15:10] If you know that this digest loop has to run, and you have to trigger it yourself, then you know, I've got to wrap stuff that leaves Angular and then apply "call" or something like that. Craig: [15:20] Right. That's when you get into directives that you have to understand how to hook yourself properly into that into that digest loop. Sean: [15:28] Sure. Or you're talking to a third party, an API, or you're working with another service or something like that, and that leaves "Angular Land". All of a sudden that the code that was all neatly tucked away in your controller -- which always gets executed when it's first loaded inside of that boot strap function, that happens at the beginning of every Angular loading and whenever an Angular app loads -- as soon as you leave that you're not inside a digest loop so Angular has no idea that anything... [15:54] It doesn't even know to check to see if something's changed. You have to tell it to. Which takes away the magic a little bit, because it was like, "Whoa, Angular is super cool!!", and then I'm like, "Oh, that's all I have to do? Tell it that something changed, and then tell it to watch something?" [16:12] But, you use those built-in directives, and if you don't know how they work, you can get into trouble really fast. Craig: [16:20] No, that was good. That's great. That's a great explanation of that. [16:23] One other thing that we've been talking about is Angular and the enterprise. We were discussing things that you were saying, "Hey, this is a pretty good match up from my experience with these larger code bases", like the one you mentioned before as a JavaScript framework. [16:38] Can you explain some of the things that were missing in your code bases and these code bases, these larger JavaScript code bases that Angular was filling in and you wish you always had Angular's base code? Sean: [16:50] The start of when you're creating an MPC web application, that most of your stuff is happening server-side. You generate a template, you make a call and it returns, it renders the template, turns the markup to be somewhere inserted inside the page. [17:05] As long as you're willing to do a full page reload, that's fine. It starts to get weird when all of a sudden, when you want to do stuff without doing a full page reload, or without rewriting an entire section of the document. [17:17] What a lot of people do, what we did for the longest time was...We had, [laughs] I was going to say JQuery, but we didn't have JQuery at my company. They used YUI 2, which is hilarious, but...Anyways, we used their JavaScript framework or the library that they had. Craig: [17:35] It's funny that you said "You e". I don't know if I've ever heard somebody say "you e" before, but I'm sure that's what everybody calls it, but I've never heard it pronounced, I don't think. Sean: [17:43] Maybe not. [laughs] Maybe that's just how they said it there, because nobody uses it, so how are you supposed to know how other people will say it? [laughing] Craig: [17:52] It's not a name like JQuery so it's the YUI libraries right? The YUI guide right? That's what you're talking about? Sean: [17:58] Yes. Exactly. Sean: [17:59] Yes, exactly, Yahoo's JavaScript library, which way back in the day before jQuery was the de facto standard, was a contender, that's when they were picking libraries. [18:08] They were a little ahead of the curve with the JavaScript library stuff and client side stuff, but a little too far ahead of the curve because they picked the wrong...bet on the wrong horse in that case. Craig: [18:18] Right. Sean: [18:18] What you start doing is you start adding more complexity and more interactions on your page. I was the JavaScript guy at this company. I was the front-end guy, and they would go to me to get these interactions working that they wanted. [18:31] It was really tough working with the system the way they had it set up, because when I asked the server for stuff, I'd get back markup instead of data. [18:40] What I really wanted was I needed some data, I needed objects to work with. I found myself, a lot of times, writing code where I would dig through the document and look for the state of the document there. [18:52] Not only does the server return actual model data which is actually rendered, but there is also this extra state in an application, especially a single page application which is the, I don't want to call it view state because that's got some Microsoft connotation, but you know what I mean? There's like the user interface state, where it's like... Craig: [19:16] View model some people call it, scope and AngularJS... Sean: [19:19] ...what's showing, well, I mean at a more abstract level, like what's showing right now and why at that layer? [19:27] What I found was really frustrating for me was that sort of knowledge, of like, OK, should this menu be dropped down? Should this be highlighted? Should...? In this application that we had there was all kinds of code like that, where it's like...If they've done these four things then they should see these three things over here. [19:45] That's not your model state. That's not product specs. That's state that's happened and built up over time of the user interacting with the application. [19:52] Where does that live? In my case, that state lived, most of the time, in classes. CSS classes that were added into the markup. I ended up writing a lot of code where I'm scraping the DOM and finding what state certain elements were in. [20:10] Of course I hated that. I did not like that state living in the DOM, so I'd pull it out and I'd try and keep and maintain a little separate JavaScript object where then I would use that to do my application logic. [20:22] I started being like, "Why are we doing this? This is a waste of time. Why don't you just have the server return json, render the markup client-side based on the data I get back from the server plus what the user has been doing?" [20:35] "Then all I have to do, I've got this cleaner JavaScript code, where I'm just updating my pure JavaScript objects which are much easier to work with, there's no HTML scraping. There's no longer any data that I care about in the DOM." [20:49] Once we hit that point, in the complexity of the application, where it became a no-brainer for me. At least I always figured at that company that we should be rendering our markup client-side...I never actually managed to convince them to do anything of reasonable size using that approach, even though I had been pushing for that for like five years. [laughs] Craig: [21:11] Right, and if you half commit to something too, it's hard to get there. Right? If you would get some json calls back, but the whole app isn't structured, thinking, you know architected in that way. [21:24] Not that you couldn't take an app and slice it into three or four single page apps. If you're not at least committing, you stepping across the line and starting to commit that way you're fighting it quite a bit. Sean: [21:36] What pushed them over the edge, I think since I have left they actually have some AngularJS running there, which is funny, is that they had an iPad app and they wanted to reuse a bunch of the stuff that they wrote for the web application. [21:53] Of course the managers were like, "Well, we already wrote all that code on the server, you just use it on your iPad app.", but it's returning markup that is several steps away from the data that you need to actually get into your iPad app. [22:07] Obviously, you need something portable across both systems so they ended up writing a separate layer where they could return ask for json if they wanted instead of HTML. [22:19] This company was even crazier because they had an entire layout engine, server-side. Markup in the browser that was returned was actually...they would render it in multiple resolutions and formats to try and get the best fit for the screen, on the server, and then generate markup and CSS to spit back the view. [22:42] Imagine you are working on the iPad team and managers are telling you, "use this call..." which goes through our layout engine and builds up this HTML. Somehow you're supposed to use that insanely brutal code to get data out of. [22:58] It was the same problem I ran into with the JavaScript. It was just the iPad team was a lot more high profile than me trying to get little front-end stuff working. [laughs] Craig: [23:06] Right. Get the iPad app done. It needs to go out tomorrow. Sean: [23:09] Yeah, but it's the exact same problem. This is why I think AngularJS has taken off, and I don't know why AngularJS in particular, there are a lot of frameworks, but it's definitely AngularJS seems to be killing everybody right now. [23:22] Probably because of this, because they're saying "really, you're building apps", and if you have apps on multiple platforms, like iPad or mobile, then you've got also your web app that you need to build. Your server gradually...that's obviously going to start turning into something that returning simple json data. Craig: [23:39] Right. Cool. I think that was a good description of some of the problems. The one thing that you didn't mention but I'm sure you felt was the whole influence of the router and the back button and that sort of thing. Sean: [23:51] We implemented our own version of that at this company. Having the ability to do that in AngularJS that would've... [laughs] Sean: [24:04] Yes, the way that they ended up doing it there was truly terrible and was one of the buggiest things that we wrote, actually. The fact that AngularJS lets you do that, makes that much more organized is much better. Craig: [24:18] Sorry, I didn't mean to steal the thunder there. That's always been my big pain point, sometimes I'd write a page and return HTML to my jQuery or whatever and think I was saving all this time. [24:36] Somebody would be testing the app and hit the back button and it wouldn't work and then you are like kind of stuck. You're just like "Wait, what am I going to do now?" [24:44] This is the Front-End Developer cast, so maybe we should take a quick second or two to talk about "Sketching with CSS" in case it matches up with anyone's interest. Sean: [24:53] It may or may not. "Sketching with CSS", I wrote that for web designers who are coming from a Photoshop background. It's like, if you are trying to leapfrog from doing Photoshop design to designing in the browser -- Is what they call it? -- It's basically all the front-end tools that a front-end developer uses to create the designs that they were doing in Photoshop before. [25:18] How would you go about doing that in the browser? It's all the tools that you would need there. That's not going to be anything that an experienced front-end developer, there's not going to be a lot new in there. Basically, the less experience you have the more value you get out of the "Sketching with CSS" book. [25:34] My AngularJS training is for learning AngularJS and that's it. It's like, jumping the learning curve that we talked a little bit about at the beginning of the podcast. [25:46] My website is planningforaliens.com and the AngularJS training is at training.planningforaliens.com/AngularJS and that's where that is. Craig: [25:55] OK, well thanks again for taking time to come on the show. I wish you luck with the newborn... Sean: [26:00] Thank you Craig: [26:02] ...and, keep in touch. Sean: [26:03] Thanks Craig. Craig: [26:06] Thanks for listening to the Front-End Developer Podcast. Please subscribe to the Podcast by going to the iTunes store on your phone or desktop and searching for Front-End, or via RSS by going to frontendcast.com where you'll also find show notes and a full transcript of each episode. [26:21] If you haven't already, please take the time to check out my book "The JavaScript Framework Guide, AngularJS, Backbone, Ember | Confidently Choosing and Quickly Learning." by going to javascriptframeworkguide.com. [26:35] Thanks. We'll see you next time.