BEN:
There's technology out there that's not .NET?
CHUCK:
Hey, everybody and welcome to Episode 29 of the Adventures in Angular podcast. This week on our panel, we have Lukas Reubbelke.
[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.]
LUKAS:
Hello!
CHUCK:
Ward Bell.
WARD:
Hello!
CHUCK:
John Papa.
JOHN:
Hi, everybody!
CHUCK:
I'm Charles Max Wood from DevChat.tv and this week, we have a special guess and that's Ben Nadel.
BEN:
Hello, from sunny but snowy, New York!
CHUCK:
Oh, that’s right, you guys are supposed to get like ten tons of snow, right?
BEN:
Where I am, we got about 3-4 inches but yeah, up in Boston, I think they got close to two feet or something crazy.
JOHN:
Which city do you live in New York?
BEN:
I actually am about forty five minutes north of New York City for the last year, but I did used to… I was living in the city for about the last 12 years.
JOHN:
Oh, I grew up in Albany, New York.
BEN:
Okay. I've been to Amsterdam.
JOHN:
Oh, cool.
BEN:
Yeah. Actually, my business partner lived in Amsterdam for his childhood.
WARD:
[Mimics New York accent] And I'm a New Yorker myself and I could start talking like this if we got to talk like that. [Laughter]
WARD:
[Mimics New York accent] So, how’s it going? How’s it going? So actually, you started this incredible business (I say “incredible” because I've been to the website), InVision and you have an amazing customer list. And can you tell us quickly about how you got going in that and what you do in there?
BEN:
Yeah, sure. So I used to run a consulting company with my business partner, Clark Valberg where we did consulting for software -- custom software -- basically anything anybody wanted. And we were very big into building prototypes before we actually implemented code, but the prototypes at the time were HTML and CSS and JavaScript, so they were very clickable, very interactive. But what we're realizing was that our ability to iterate over our prototypes was kind of slowing down as the projects grew and complexity grew inside, because it was still a lot of code to deal with. And once you start to write a lot of code, you kind of become very emotionally attached to it; you don’t wanna throw it away. You kind of start to, even subconsciously, push back against clients asking for changes because you know secretly, it's going to be a lot of work to change those.
So Clark and I sat down one day and we start to think about different ways to approach it and we felt what if it was just graphical? Meaning, what if it was just images so we didn't have to worry about the code and we could string the images together like image maps. I don’t know if anyone of you uses image maps anymore, but you make a part of the image clickable to another page. And we started to iterate on that idea with just like a single image here and a single image there, and then we start to build some interactivity. And then this was all part of our consulting business and we're only using it as a way to present the work to our clients. And it was actually someone who was working with us that said, “Hey, this is a really great idea. You guys should put it out there and see if anybody else likes it.”
And after some resistance to the idea of sharing it, because at the time we talked about well, this is kind of our secret sauce, right? Like, this is how we were able to iterate on our prototypes for our clients so fast and get to a better piece of software for them than maybe our competitors will be able to. But eventually, we put it out there and we started to get some traction. It was of course written the first time in just jQuery and you know, a lot of server side code. And we went through about one or two iterations and then we got funding and then we got a lot of traction, we got some huge names and then we actually ended up spinning it off as its own company entity, so I'm now Co-Founder and CTO InVision. And we had since, we’ve written basically the entire application in AngularJS and a whole bunch of other technologies like Firebase, which I know you guys have talked about on previous episodes, and it’s just been growing in popularity. There’s some [unintelligible], we're trying to address those but it's been quite a fantastic journey, I have to say.
WARD:
I should point out, I'm just looking at the website here and it's an intriguing idea because I think all of us have tried to sit down with clients and get them to explore the possibilities, and we wish we could present them with more than one design rather than just one design, and there you go.
BEN:
Yeah. It's really freeing. I mean, you still get emotionally attached to design but not in the same way that you know, if you had to sit down and write code for nine hours and then have to throw that away, that’s – to me, at least -- a lot more painful than putting something together in Photoshop or Fireworks or Sketch and presenting a whole array of ideas to the clients. They pick and choose the aspects they like, then we take it, we merge it into a new graphical interface and present it and continue to iterate. And the platform provides a lot of collaboration. We sort of build it originally as a prototyping platform, but then really, the prototyping was such a… it's the core product, but it's such a basic part of the product. Most of it is about the collaboration; the ability to spread the ideas and to get feedback from a really wide swath of stakeholders. People who maybe otherwise wouldn’t have been involved in the process because they weren’t at the meetings or they weren't part of the people involved in paying for the project or what have you. So, it's really the ability and the ease of spreading and collecting feedback I think is what makes InVision really as powerful as it had become.
WARD:
Does that sort of drive your Angular thoughts and Angular sort of woven throughout that in terms of organizing that app?
BEN:
Oh yeah, absolutely. It's AngularJS, has a learning curve and it’s a steep learning curve. And all of the pain that I felt learning that and dealing with the hurdles and kind of ascending and then descending through this life cycle of learning have pretty much become every blog post that I've written in the last two years.
JOHN:
I've found two particular points to be steep: meaning if I come from a different experience; if I'm not a JavaScript developer already, I firmly agree with you that yes, it's steep. Because you're not just learning Angular; you're learning a lot of JavaScript practices. And a lot of folks who are coming in Angular haven’t done these things. They don’t understand how to write JavaScript well the way they did for C# or Java or other things. So I think that adds to the confusion. You need to help there. I also feel like you're coming in to Angular and you’ve got JavaScript experience, then you don’t need to know everything with Angular right out of the gate either. So is it really steep… I mean, when you say “steep,” what is it steep for?
BEN:
Yeah, good question. The way I think about it is the learning curve comes with the fact that Angular, as a framework, makes things very possible; meaning that before I dealt with AngularJS, I used jQuery, I used Vanilla JavaScript, but I wasn’t building single page applications. So, there's kind of a limit to how much damage you can do when you know that your page can refresh and maybe you have a page that has 5,000 lines of spaghetti JavaScript. But at the end of the day, it's just this page and the second someone goes to another page, you clear all your memory locks, you get a whole new board to work with so to speak. Because Angular makes advancing the way you build JavaScript application so accessible, I think it brings you to hurdles that you never had to deal with before such as memory leaks, such as dealing with Ajax for everything, such as dealing with a lot of asynchronicities, such as dealing with cached data locally and build process and what have you.
And with each one of those things that now is part of your world as a developer, even if you have years of JavaScript experience, now you’re solving completely new problems in a completely new context. And so to me, that’s why it's kind of roller-coaster because you can get going really fast and then all of a sudden, you hit a wall and you're like, “Oh, routing. How do I deal with routing?” I've been doing AngularJS since 1.0.4, I think and the router then was poor. I think the router now is still poor. The 2.4 seems pretty exciting. But like, just dealing with routing -- which you maybe never had to deal with before -- that was, for me personally, that was weeks of development just trying to figure out how to build proper routing in our applications and how to do that in ways where only parts of the page can refresh and other parts may or may not have to refresh and how one part would know about a route that’s relevant versus a route change that’s not relevant.
JOHN:
I agree with you, Ben, but let me ask you this: would that be any different if it was Angular or Ember or React or just straight up JavaScript? Does the need to learn routing and that steep curve (because it is steep to learn that), is that an Angular thing or is that more of like generalizing the JavaScript web framework thing?
BEN:
I would assume it's just a general framework thing. Angular happens to be the framework that I know, so I can’t necessarily compare it to Backbone or Ember or React or Flux or what have you, but I would assume that it's going to be the same across the board because again, you're just dealing with new problems that you’ve never had to solve before.
JOHN:
That's where I think I'm getting at is I agree with you that there's a steep curve here, but I think that the learning curve is less steeper in Angular than it is in just learning having to [unintelligible] JavaScript and write apps in a browser that we've never really done that before.
WARD:
I think that’s really a good point, John. And it's really interesting because so much of the time, Ben, when we see application quote you on that, they think you're talking about Angular and they’ll use it in an argument about why some other framework or no framework at all is better because Angular is too complicated. And I'm sitting there myself like John, I’m scratching my head because what I acknowledge completely is this is no longer just spew onto a page; now you have to learn patterns and how it's all going to work to hold it together to build an entire client side app in JavaScript, as opposed to just script across the page. And that’s what I think all of us probably deem as a challenge. And it isn’t that Angular itself -- at least in my experience -- was so hard as figuring out what's the right thing to do. Would you agree with that statement?
BEN:
Yeah, absolutely and that’s why even in our own company, we get a lot of pushback against Angular not because other things better, but because they’ve kind of on the face appear to be faster or easier to do when you look at one particular part of an application. You're like, “Oh, you should be using React because it can build the view very fast.” But you know, no one has the depth of experience – at least that I’ve seen -- to really say, “Yeah, that's true but what about all of the other stuff that Angular does that you might not be taking into account?” when comparing the aspects of different libraries or different frameworks. I think you're going to hate hurdles no matter what you do because almost by the fact that the framework enables you to do new things, you're going to have new challenges. And I think that that’s not a problem of the framework; it shouldn’t be seen as a negative. It should be seen as… I hate to say to say it's a positive, but it is positive that you’re getting to these new hurdles because you’ve been empowered by the tools that you're using.
JOHN:
I think that’s super key, so I agree with you there. There's problems we're facing now that are only surfacing because people now have Angular to thank for removing a lot of the plumbing from their minds because it does all that for you but now we're like, “wait, I've got to figure out how to do all this routing and I have to figure out how to do Dependency Injection and deal with these different modules.” I think that’s really more of the issue was learning how to do stuff I've been doing in the server for so many years or in JavaScript without any help. Now, we're kind of elevated on another level of figuring out how we make it better.
BEN:
Yeah, absolutely. And that’s why I think to some degree, it's not like a lot of times, people will say. “well, you have to know a lot about the Angular internals” or “you have to really understand the way it does the compiling and the linking or the way it does expression parsing in order to build an efficient Angular application.” And they say “Leak abstraction, you shouldn’t have to know about things like this.” But I don’t think that that’s true; that’s part of being able to leverage a tool to its maximum ability is removing that veil of secrecy. Removing the magic and understanding how it works at the mechanical level so that you can then work with it in the ways that are efficient and avoid the ways that you know are not efficient. Like dealing with a manual transmission in a car; if you wanna just drive a normal car and it's automatic and that works well, then that's exactly what you use it for. But if you're going to use a manual car, you need to know how that works so that you know when to shift gears and how to feel the vibrations of the car. I don’t actually know how to drive a manual car, so forgive me if I’m talking way out of the left field there, but you need to know how to work with the tool. They shouldn’t be black boxes because that’s not how you can use them the most efficient way.
WARD:
So, Ben, I was looking through your blog post and I wanna talk about how you do that a little bit later, but I noticed that a high percentage of them concerns explorations of performance characteristics of your Angular app, so I'm curious if you could tell us a little bit about how you think about performance. Because you know, everybody knows that old song about premature optimization, but clearly it's something that’s on your mind a lot. So tell us, how do you think about performance in SPA apps? Are you worried about desktop versus mobile? What's driving your thinking there and causing you to look in certain places? And then maybe you can give a list of your top watch outs.
BEN:
Sure. So all the performance exploration I do is typically based on actual pain that we felt on our application, because as we build the application, we build it with a certain use case in mind. And you know, when you deal with users, the use case that you account for is probably very small percentage of the way somebody actually uses it. You can say “oh, we should never build an interface that has so much data” or “we shouldn’t never build an interface that has so many repeaters or what have you.” But the truth is you don’t necessarily think that someone is going to build a project with your projects and screens that has hundreds of screens. It just never occurs to you that “oh, I'm going to have a user that has a thousand active projects.” So when you build your interface that lists out projects, and each of those projects has a lot of intricacy in the way the UI is rendered, suddenly -- and this is no exaggeration at all -- you have a page with fifteen thousand watches on it.
And you have to figure out how to deal with that, because especially from a software as a service product like InVision, it turns out that the power users are also the ones paying you the most money, so you have to figure out how to make their experience as good, if not, better than the person who’s using the free version of the product. So performance has become a [unintelligible] to us as we've grown because we just didn’t anticipate people using it in such an extreme way, which is great because it means that the product has a lot of traction, has a lot adaption; it's really helping people solve problems but it also means that they’re pushing the limits of what you expected. And then on top of that, it's hard to then go back and say, “Oh, now if we're going to have a user that has a thousand active projects, we can’t necessarily rebuild the UI so easily to say ‘have pagination’,” because now we have features that didn’t anticipate pagination. How do we retrofit that concept into the application? So all the performance that I explore is from pain that I have actually felt in the application that we build.
CHUCK:
I really enjoy looking at the source code behind what I'm working with and you’ve talked about some of the aspects of AngularJS and some of the advantages of understanding how they work, but if I wanted to just get started and sort of find a thread to pull at and unravel, which part of Angular would you recommend that people go for first?
BEN:
I think directives are kind of the Achilles’ heel of Angular while at the same time, accounting for so much of the power. When we first started learning about Angular, it was actually recommended by a co-worker who his instructions were to go to the Angular website, read the documentation about directives then read it nine more times -- and then read it one more time for good measure -because they’re really complex. And it's not fair to say that they are really complex; they can be very complex and they can be very simple. And I think once you can wrap your head around the way that directives work and the kind of different types of directives that can be applied to AngularJS application, I think that would simplify the way that you think about building your pages and the way that you think about organizing your code and I think will remove a lot of the pain points. Because directives, they are just… everything else is function calls and Ajax and learning about promises and learning about just organizing the layouts in your application and routing, but it’s the directives that really are a hurdle when it comes to understanding how Angular fits together and it renders and how it builds your page. I think putting as much time into understanding directives will probably be the most valuable part of an AngularJS education.
WARD:
How do you use Angular directives in your app? I’ve seen a wide range of them; some of them just sort of create new behaviors all the way to somebody trying to build an entire application with directives in lieu of UV model pairs and trying to have directives within directives within directives. So I'm kind of curious about how you use… did you sort of have a few that you sprinkle through that they are critical or is it like everywhere and if so, how do you use it? And maybe John had a similar question.
BEN:
So directives, I mean, I've been building this one particular application for two years and I'm still learning about directives and about how to organize the code more effectively. The easiest directive to learn and to work with is simply just adding some interaction behavior to your application; the ones out of the box like ng-click and ng-show and ng-hide… I guess ng-show and ng-hide are [unintelligible] behavior, it's more like ng-click and ng-mouseenter, ng-mouseleave, these are kind of taking the JavaScript interactions that we've known and used for years with jQuery and regular JavaScript and now just saying, “Okay, lets wrap that inside of a directive.” And if you dig in to the AngularJS source code, when you look at the way those things were implemented, they’re super simple; ng-click are probably like just a couple of lines of code. It's about as basic as you can get. So adding behaviors is one.
Then I do a lot of stuff with defering, because we had interfaces that have so many watch like, we're in pages with fifteen thousand watchers on them and Angular says don't go over two thousand. We have a lot of directives that deal with defering the transclusion; the linking of certain parts of the interface. So if you can imagine that I have a list, an ng-repeat with a thousand things in it – again, not an exaggeration -- each one of those list items can have a lot of directives inside of it. Each one of those directives may or may not have bindings. And then there's the text interpolation, attribute interpolation and so on and so forth. So what we will do is we'll look at that list and say, “Okay, when the page renders, here’s what the person can see and then maybe when they mouse over the list items, they can see something from an ng-show or something that fades in or what have you.”
And what we can do is to say the root of this repeater, we can actually, during the compile phase, we can go into those list items and we can rip out all of the stuff that people don’t need to know about. And then what we can do is we can listen for mouse enter events and when someone mouses into a particular list item, we can then transclude [unintelligible] and clone it and then append it to a particular item. And then if we want to, we can [unintelligible] when they mouse out. And now, you have thousands of watchers that you can remove from the page. So I don’t even know how you would categorize a directive like that. It's kind of a behavior directive; it's not… I guess it's kind of a layout directive. Unfortunately, a lot of things like that are simplified in things like ui-if, and now, ng-if came along which kind of do a lot of the heavy lifting that we were doing back before we even knew that Angular UI module existed.
And then things like we deal with a ton of images because InVision deals with prototypes based on images that are linked together, so we do a lot of lazy loading of images, so we'll create directives around integrating… instead of using ng-source, we integrate source loading with scrolling the page and the visibility of elements. And we do a lot of directives that deal with web socket integration. And this is one of those things where now you get a little bit nitpicky maybe with the philosophy of AngularJS, where we don’t want the controllers and the services to know about the DOM, so where do we bind something that has to listen for web sockets off of… like we'll bind web socket listeners to the root of the page or to the root of a view and then it listens for, or subscribes or unsubscribes particular web sockets and then turns around and routes those to the rest of the application and then we deal with directives that do HTML5 uploading. So what we do the PL upload, which is an HTML5 upload that will fall back to Flash. So kind of integrating that into the application is a directive and… sorry, I didn’t mean to ramble but…
WARD:
Those were really good cases and those are very specific, again, the question of whether you call them a behavior or a layout, but they saw very specific problems in reusable fashion. That makes sense to me as a directive. By the way, you have a whole blog post on that whole transclusion thing you were talking about where you rip out part of the DOM or you delay populating the DOM until there's something to do it, thus eliminating all those watchers. And I was curious about that. It's a fascinating post. We'll put a link in there. But then, I was wondering well doesn’t ng-if do that and so can you relate those two for us?
BEN:
Sure, absolutely. So ng-if does do that based on an expression that you give it to evaluate. And the truth is that we could probably go back and retrofit a lot of what we're doing to use ng-if. But the thing is, you have to find a way to, on the fly, change the ng-if expression evaluation. So I could say “don’t show this element until hover is true” but then I need another directive sitting somewhere that says “okay, but when you hover into it, make sure that you set that hover flag for [unintelligible] so that when your ng ifs will kick in and now you can see those contents.” So it replaces to some degree but mostly it replaces part of the interaction I think not the entire interaction.
WARD:
So, Ben, I’ve been to your… and I urge everybody to go look at your blog because it's really amazing. Each of them is a polished gem; you got a problem statement, you have this incredibly clear discussion of wonderfully focused code sample on a single page, then you do this fifteen minute video and you cross link all the stuff. And you know, having done a little bit of that, like just to give a… you’ve done sixteen of these in January alone and you have over 100 in the last few years. So my question to you is do you have a job?
[Laughter]
Or really, what is your process? [Chuckles] That’s my question.
BEN:
Sure. So my process is that so much of what I do is based again on the pain that I feel at work. So as I go to through the day, typically, I will think of an idea based on a code that I'm writing or I'll think of an idea based on something I see on Twitter. And actually, I would email myself. I have a special subject line that gets filtered into a special inbox for just blog ideas. And then every morning, I wake up at five thirty and they usually sleeps until about seven and that gives me you know, an hour and a half to two hours of kind of me time in the morning. No one else is awake. And I sort of pick take the thing that seemed most interesting or I look at the things that I have in that pending queue and then I just start attacking. And usually, I start with an assumption that I wanna prove or I just wanna know how it works and I start writing the JavaScript for it.
And one of the approaches that I use is in the JavaScript, I use a tremendous amount of commenting in the blog posts in the JavaScript. I don’t use quote so much in production. And I do that because the commenting one I think is helpful for the people reading it. But also, the commenting for me is, I don’t wanna say anything that is not true in the commenting. So the more that I can say in the comments in the JavaScript, the more I actually have to dig in to what I'm saying to actually make sure it's true. So if I say, “oh, this happens because there's… a watcher gets setup in the prelinking phase and then it has to get set… or checked again in the post linking phase” well, I can’t say that unless I’ve actually taken the time to dig into the source code and validate that that comment is actually true. And then you know, hopefully I can get it all out in one morning; a lot of times, I'll kind of finish it up at night and then post it the next morning. But I try as much as possible to always have a [unintelligible] of ideas ready to go and a lot of pain points ready to be investigated.
CHUCK:
Cool! Well, we're kind of at the end of the time, is there anything else that we should cover before we wrap up?
BEN:
No. I suggest just looking into the AngularJS source code because it's fascinating, really and it's incredibly complex. There's always I think a few links somewhere in the community that you people don't need this, like you don’t need jQuery because you can bind your own event handlers. And you don’t need Angular because you can just build a framework and doing all the same stuff. And when you look at the source code and you see how much have been thought through and how many problems are solved “oh, did you even know that SVG elements require a little use case here when dealing with the DOM?” You probably didn’t know that. Maybe your application would never need to know… this source code is fascinating. People who put it together, they are either insane or they’re brilliant, I'm not sure but it's just super interesting to look at!
CHUCK:
Awesome. Well, thanks for coming! You're so awesome that we're going to have you back in a few months.
BEN:
Fantastic!
LUKAS:
Hurray!
CHUCK:
[Chuckles] All right, well let’s go ahead and get into the picks. Ward, do you wanna start us off with picks?
WARD:
I'm bouncing around between the Windows side and the Mac side and I'm losing track over everything. And I also have been bouncing around among IDEs and would it do this and that. And so John Papa has got me into Brackets and I got to say that for reasons I can’t articulate yet, I do find myself clicking on Brackets [chuckles] as opposed to some of the other choices I have. So I'm going to pick Brackets. I'm going to have people take a peek at Brackets and see if they will like that as a way to edit their stuff.
CHUCK:
All right. Do you have a tip for us?
WARD:
Go to Ben’s site. It's really an interesting read. [Chuckles]
LUKAS:
Plus one!
WARD:
Next time he comes back though, I'm going to come with really hard questions instead of all these little softballs I've been throwing at him.
CHUCK:
Nice. Lukas, do you have a pick and a tip for us?
LUKAS:
Yes. So my pick this week is I recently got a GORUCK backpack and it's just super rugged, super awesome. It's definitely worth the investment. And my Angular tip is I just did a blogpost on authentication using interceptors. And in conjunction with that, I'm using a module called Angular Storage, which is kind of like ng-cookies done right, done by the Auth0 people. It's excellent, super easy to use and I highly recommend it.
CHUCK:
Awesome. John, do you have a pick and a tip for us?
JOHN:
I do. My non Angular pick is thingCHARGER. This is one of the really cool new ideas that’s out there. And what it is basically a plug that you can put on top of your outlet and super, super thin and it extends your plug and looks just like a plug, so your wife won’t be upset about it in the house. It's got USB ports and things hanging out at the top and bottom, so you can plug in multiple devices and really not have an ugly thing in your house to do that. And it's at thingcharger.com. And then my tip for Angular is a blog post from a buddy of mine, Kody Peterson, where he's talking about the three types of data binding in Angular, in that he articulates one-way binding different from two-way binding, different from one-time binding. That’s in basically the new Angular 1.3 logic.
So definitely check out this post and we'll put the link up there.
CHUCK:
Very cool. My pick is interviewed.io and I'll put a link into the page about this guy that I know, but basically what it is is it's just a collection of podcast interviews done by different people. So some of the more popular people out there like John Lee Dumas or Pat Flynn if you're in the business entrepreneurial world, you can go in there and you can see where they’ve been interviewed, what shows they’ve been on and stuff like that. I don’t have a great tip. I usually get good tips off of the show, so I'm going to skip that.
LUKAS:
That’s like a meta tip.
CHUCK:
Yeah, there we go. And Ben, do you have a pick and a tip for us?
BEN:
Sure. My pick would be… I don’t know if I'm pronouncing this correctly, GUNNAR Glasses. And I've been using them for about a year and a half now just while I stare at the computer all day. And I don’t know exactly who they work. They cut out some of the blue light or something or it's some sort of light spectrum that irritates the eye. And I think they also have a slight magnification, but they definitely make your eyes way more comfortable as you're dealing with the screen all day, to the point where now if I… I can look at my screen for like a minute or two without them before I get irritated and have to put them back on. The downside is they look really funny on video calls, but the comfort I think is worth it.
JOHN:
Are they funny looking or are they cool? [Chuckles]
BEN:
I'm going to change my attitude. I think they’re cool now.
WARD:
That’s funny.
BEN:
[Chuckles]
JOHN:
You're going to start a trend.
WARD:
They aren’t wacky enough for my taste. They need to have some spangles or something.
JOHN:
Yeah. I'm looking at a picture of Ward I'm like… Ward would be like, “Meh.” [Laughter]
WARD:
“Boring…”
CHUCK:
Snakeskin glasses to go with the snakeskin boots.
JOHN:
Now if you bedazzle it, you're all set for Ward.
WARD:
[Chuckles]
LUKAS:
With the top hat, you're in.
WARD:
Yeah. I'll get some and get my wife to work on it. She can put something ridiculous on it.
BEN:
And then I guess for Angular tips, one for me is very controversial and I've kind of enjoyed that and that's don’t use the isolate scope unless you actually know what it does. Because a lot of people tell you that the isolate scope has to do reusability but this is something that even when you look at AngularJS source code is that none of the AngularJS built in directives use the isolate scope. And you could argue that the ones built into the framework are ultimately the most reusable directives that there are out there. So understand what the isolate scope is, realize that it really has nothing to do with reusability, but it does serve a purpose and just know what that purpose is. My other tip would be I like to avoid using filters in ng-repeat, not necessarily because I have a performance problem but because it makes it harder to then update the UI based on the state of the list; like showing a list if there are no items in the filter or showing different message based on the filtering.
So the more you can keep track of the controller, the easier it is to update the DOM as it changes.
WARD:
No filters policy in my apps.
BEN:
I definitely lean heavily in that direction.
CHUCK:
I know several people who have no filter, but that's a different problem.
BEN:
[Chuckles]
LUKAS:
Every time I talk.
CHUCK:
[Chuckles] All right, well, we don’t have any ng-confers here, so I guess we don’t have any announcements on that, but I'm pretty sure that most of us that are regulars on the show are planning on being there, so if you're going to be there, then let us know and we're going to be doing an episode on Friday during lunch. And then I'm also going to see if I can pull together some kind of meet up after the conference in the evening or something fun. I don’t know. Maybe we'll get breakfast beforehand since I know that there are events afterward anyway. So, thank you all for coming. Thanks, Ben, it was awesome to talk and I'm definitely going to have to go and check out your blog and all of your smarties.
BEN:
It's been a pleasure. I'm honored that you guys included me. Been listening for a long time. I'm a huge fan.
CHUCK:
Nice! All right, we will wrap up the show. 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!]