WARD: It just sounds like a barrel of monkeys.
JOE: It kind of is.
JOE: Hello everybody and welcome to episode 87 of Adventures in Angular. Today on our panel we have the amazing John Papa.
JOHN: Hello, everyone.
JOE: Ward Bell.
WARD: How did we ever get to 87?
JOE: [Inaudible] And my personal favorite, way more than the other two, Lukas Reubbelke.
LUKAS: I was just going to say, Ward we’re talking about the episode number, not how old you are.
JOHN: We are not 87 [inaudible].
LUKAS: [Inaudible] why I’m his favorite. Love you, love you Uncle Ward.
JOE: Oh no, he didn’t.
JOHN: Uncle Ward. [Laughs]
WARD: Oh, goodness.
WARD: You’ve been a bad boy, Lucas.
JOE: And moving on from there…
JOHN: He could have called you Grandpa Ward. [Laughs]
JOE: Moving right along.
LUKAS: [Mimicking old person’s voice] I’m putting my teeth in for this episode. I am.
JOE: We’ve already completely derailed. And I’m your host, Joe Eames. I’m not much of a host because I can’t keep these guys on track, obviously. So today, we are going to be talking about style guides. The Angular Style Guide specifically, right? We’re going to talk a little bit about the Angular 1 Style Guide because everybody has an opinion on it. But we’re mostly interested in talking about the Angular 2 Style Guide, which is awesome because we have John Papa who has been tasked, secret mission, CIA level clearance from the Angular team to create, work on and create an Angular 2 Style Guide. Of course you can see all of the work that’s been going on in the GitHub repository which is public, right?
JOHN: Yes. Yes, yes you can.
JOE: Okay. So guys.
JOHN: I didn’t realize it was a question.
JOE: It was a question. Well, it was more we’re looking for verification than really a question. Are you actively contributing in that GitHub repo? Or are you working outside of it and then occasionally going back to it and then updating it?
JOHN: So, for Angular 2 a lot of my musings about the style guide, I’ve been very careful first of all to not put things out in my GitHub repo that I’m not sure of yet for the style guide. So, it’s kind of sparse at this point when you compare it to the 60 pages of printed Angular 1 style guide. But all the core things that I think we can all agree as a community are important and can be decided right now are there. The things that are not there yet are things that we’re working on with the Angular team to figure out what is the best way to guide people to building applications? Things like naming conventions and folder structures and how lazy loading will work, and all that stuff is being worked out. But the process right now is we have some internal Google Docs that we’re playing with. We map out some ideas. We get some feedback from various members of the community and the Angular team, and then that progresses eventually into a GitHub repo which we’re determining the final resting place of where that will live. And one optional place that it might end up is in Ward’s hands in the documentation maybe.
JOE: Mm, interesting. So, whereas before… was the Angular 1 style guide every part of the Angular 1 documentation or was it just linked to?
JOHN: It was… actually, I don’t think it’s actually been linked to from the main Angular pages. I don’t think I’ve ever seen a link there. But, so I started… a lot of you may not know this but the Angular style guide I think the first one I’ve ever seen was Minko. He created on a long time ago before I did.
JOE: Minko Gechev you’re talking about, right?
JOHN: Yes, yes. And then gosh, I think it was two and a half years ago, something like that, Todd Motto and I were talking on the internet about Angular 1 styles and how we had different ideas. And then we both had the same idea of, “Hey, why don’t we publish this?” And he put his out. And I was talking. “Maybe I should merge mine with yours. Should I do them separate?” And we just in the end decided “Let’s have two different opinions on this and give people options.” So, we both put ours out there I think in the same month that summer. So, at this point now there are three style guides, right?
JOHN: And some people were like, “Oh, that’s awful. You need one.” and some people are like, “It’s great because I get to see different ways of doing it.” It’s really each to their own. But that evolved.
JOE: But obviously, obviously you felt like it was better to have multiple.
JOHN: I really did, honestly. Because my intent all along was not “This is a rule.” I’ve worked for a lot of companies where my job actually was to define the rules by which developers would live, otherwise they’d be thrown into the fire and never let back out. And I hated that. As a developer, who wants to tell you “You must use four spaces for tabs, otherwise you can’t work here”? And things like that bugged developers and I didn’t want to be like that. I wanted to instead say “Look, here’s a [inaudible] method you can follow. And the community is contributing to this. These were defined as a way to guide you down to building good Angular 1 apps but not just tell you what to do but also tell you why so you can learn how to think about the decisions and how they impact the rest of your application.” I think that’s one of the reasons the style guide that I put out there had become so popular, because a lot of people feel like they have a voice in it. We’ve got 140 contributors on it now. So, that’s the soul behind what it was.
JOE: Very interesting. So, we’ve got the Angular 1 style guide. It’s relatively well-known, right? I would say probably a majority of Angular developers know about they style guide. I have no scientific evidence to back that up but I think it’s pretty well known about. And I think a lot of people were expecting an Angular 2 style guide. And were there people talking to you right from the beginning saying “Hey, where’s the Angular 2 style guide”?
JOHN: [Laughs] Absolutely. And you know, the Angular 1 side, I still meet people who haven’t heard about it and they hear about it and they’re very excited because they like having something. And right now, I think it’s in the top 75 GitHub starred repos, so it’s pretty cool. It’s that popular.
JOHN: But the Angular 2 one is [inaudible]. Yeah, the Angular 2 one’s interesting. Angular 2 is not out yet, right? [Chuckles] It’s not released. And what is a style guide? It’s a way to define experiences of how you build applications. Now, who out there has experience at building one or more or many of these Angular 2 applications in production? Crickets?
JOHN: So, it’s… I’m very hesitant to just slam on out there and go, “Hey, look. This is what you do when you do X, Y, Z” and “Well, what are you basing that on, John?” “I don’t know. I just had a great dream and that’s what sounded like a good idea.” That’s how you lose respect and trust, in my opinion. So to me, it’s important not to put something out there until it’s at least been vetted and something I can feel I can stand behind, which is why what’s out there right now and I just augmented my Angular 1 style guides and I just put my initial ideas up there, I created a draft and put the things in that I feel comfortable with right now. But there are still things that I’ve gone back and forth on and Ward and I have batted some of these ideas around, too.
JOHN: Like naming conventions.
JOHN: So Ward, how many times have we changed naming conventions over the course of alpha and beta with Angular 2?
WARD: Well, a fair amount. But what’s interesting actually is that it seems to me to hue pretty closely to what we learned in the Angular 1 style guide. So, I don’t think we had so much churn on that. Do you?
JOHN: I don’t think it was a lot of churn. But I think it was a lot of thought when we did churn. Meaning we might have wanted to change direction two or three times over a year, during alpha stage of Angular 2. But each time we did it I remember very long conversations with you [chuckles] where we bounce around “Oh my gosh. I wish it was easier. I wish [inaudible] would be more descriptive.” For example, we’re proposing in part of the guide and working with the Angular team is if you have a component called I don’t know, developers. The file name for that component would be ‘developers dot component dot JS’. So, you would designate the ‘dot component’ as part of the name of the file. Now, that makes it kind of lengthy. So initially, I was like, “Man, I don’t want to have to type that,” right?
WARD: I thought it should be developers developers developers developers developers develop-… oh, that’s… sorry.
JOHN: That’s if you’re using the Steve [inaudible] syntax.
JOE: It’s components all the way down.
LUKAS: [Inaudible]. And in uppercase. So, you actually have to kind of crescendo into that.
JOHN: And you have to yell and sweat while you’re doing it, yes. [Laughs] But so, we said that and then what if you get rid of the ‘dot component’? If you do that, it sounds great in a vacuum. But then Ward and I were building these sample apps and started building larger apps. And when you do that you realize that I might have a developers data service and a developers pipe or a developers model or a developers interface or a developers component or a developers directive. And you go on and on and when you don’t put some kind of name into the file name and you’re looking at this in a large app with three, four hundred files, it instantly becomes impossible to identify what you’re looking at. Which does bring us back to the Angular 1 style guide as Ward said. One of the concepts in there was I have to easily be able to locate and identify my code. I shouldn’t have to hunt and [inaudible] through the files to figure out “What is that?”
JOHN: So, that’s one of the reasons we landed on and we talked a lot with the Angular team and Igor and them about using some kind of extension on the filename.
WARD: But you reminded me of the tag line for the film Alien, which is that…
WARD: When you develop in a vacuum, no one can hear you scream.
JOHN: When you develop in a vacuum, nobody can hear you scream. [Laughter]
JOHN: You know, I hear that about [inaudible] week when I go the parks, by the way. They play that inside one of the Disney parks. [Laughs]
WARD: So, I think we both have a bit of trepidation, and I think you expressed it, trying to put together a style guide for Angular 2 when nobody has any real experience on it.
JOE: So, let’s circle back. I want to circle back around slightly to Angular 1 and talk about, you built it but at that point how much Angular 1 had you done? And then how did it grow from the initial version to, when is the last time some changes were made to it?
JOHN: So, when I wrote the Angular 1 style guide it was after about two solid years of Angular development. So, I didn’t…
JOE: And in that time, what size of apps had you written in Angular 1?
JOHN: how do you quantify size? Files, users?
JOE: Wait. Pounds. I mean pounds.
JOHN: [inaudible]. It all depends. [Laughs] about 400 metric tons.
JOHN: Of Angular code printed in dot matrix printed paper.
JOE: Rather than any specific metric, can we quantify them as small, medium, and large?
WARD: Well, you know John has small hands but that doesn’t mean his applications aren’t very big.
LUKAS: But they are his own. Ooh. [Inaudible] reference ’90s.
LUKAS: ‘Sup, guys?
JOHN: You know Ward, nobody can hear you scream when I come for you.
WARD: I don’t know what it is with the pop references today.
JOHN: I don’t know. At the time, most medium size apps. I think I’ve written one massive app at that point. A lot of, tons of small ones. A lot of those with Ward playing around. And then a good number of medium-sized apps, too.
JOE: Okay. So, you already had two solid years of experience in Angular on some relatively, some big, some huge, type apps. And that’s when you developed the style guide. And then from that point to the last time a change was made to it, how did it change over time?
JOHN: So, I have something else to add there before I answer that [inaudible] is that it wasn’t just… what I [derived] in style guide wasn’t just from the apps I built. A lot of it was also from the apps that I helped consult with other companies on.
JOHN: So, while I did not help them build some of these apps they were also from talking with XYZ large company who’d call me and talk about their app. I’d come in, take a look at it with them, see what they built, and look at the decisions that they had to make. So at least then, I was able to learn, “Ooh, you know what? I wouldn’t have done it that way maybe. But this is interesting because it solves that problem.”
JONH: So, there were a lot of other things that went into building that.
WARD: Right. And we were talking and I had a whole boatload of these apps that either I had worked on or IdeaBlade had worked on. And we had other people in the community and there were other samples. There were things you could look at. So, you could feel that you had a pretty good survey of apps of various sizes trying to solve different kinds of problems and the things it kind of settled.
JOE: Just to mention something. I was highly disappointed at the time that you didn’t come and talk to me about the apps that we’d been building and the stuff that we’d done. Because some of the things that we’d invented didn’t get into the style guide. I think it definitely would have been way better with my ideas.
JOHN: it would have been better if it was all your ideas, actually.
WARD: So tell us, Joe. What don’t you like about the style? Now you’re on point, buddy.
JOHN: Go for it.
JOE: Oh man. Actually, I think that there was one thing that we did. So, I worked at Domo. We had close to a hundred thousand lines of Angular back, three years ago. So, it was [inaudible] at the time.
JOHN: By the way, before we go further, what do you use to do that? Is there a tool that will tell you how many lines of code you have in your thing?
JOE: Yeah. [Inaudible]
JOHN: Or did somebody actually… [Inaudible] a script to do that.
JOE: Yeah, no, there’s a couple of [inaudible]
JOHN: I’m going to run that someday. I’m going to go google it. Keep talking.
JOHN: That actually came up. I’d heard that several times. People for example would namespace it with maybe the module name for example.
JOHN: Or the feature name.
JOE: With periods, that gets pretty common too. I’d seen other variations of that, the namespacing, which definitely was an issue in Angular 1, right? There is…
JOHN: Oh yeah.
JOE: It’s a big huge global namespace.
JOHN: Yeah, I’ve seen… I know Dan Wahlin. I don’t know if he still does this but he’s a good friend of all of ours and one thing he had done at one point with some of his apps was not the filenames but inside the modules. Like the service, it was developer service like you’re talking about it, he might actually name the service with the namespace as well. So, when you’re doing your injection you can differentiate the developer service from the different modules, too.
JOE: Right, yeah, yeah.
JOHN: So, yeah.
JOE: It’s a similar issue. It’s the same issue, right?
JOHN: Yeah, yeah, yeah.
JOE: You have to consider that. So, we dealt with that. While we’re on the subject, there’s one other piece of your style guide I don’t like, and that is separating the functions from… having the function be separate from the line where you call the controller and create it and you’re just passing in the named function. I don’t like that.
JOHN: You mean, where we say ‘angular such and such module dot controller’ and then right in there you’re doing an inline anonymous function. Is that what you’re doing?
JOE: Yeah. Although we would actually make them non-anonymous by making them named functions.
JOHN: Yeah, [inaudible]…
WARD: But still you would have the whole body in there.
JOE: Yeah, but with the whole body in there. I don’t like that. So, if we’re going to complain about the style guide, then…
JOE: I want that one out there. But that being said…
WARD: Can I just…
JOE: I don’t think that’s [inaudible]
WARD: Can I just tell you why…?
JOHN: By the way, before Ward answers, this is the best thing about writing a style guide and having 17,000 people star it and chime in is I never have to talk about it anymore. [Chuckles] Everybody else has an opinion one way or the other.
JOE: That’s right.
JOE: Yeah, that is nice. Okay, Ward.
WARD: So, first going back to your prefix thing, we used to do that when we wrote COBOL. So, it’s good to know that the COBOL still lives.
JOE: The COBOL still lives. [Laughs]
WARD: But we had a thesis when John and I were talking about using the function names up there and then having the body down below. And that thesis had to do with readability. And our thought that like a newspaper or [tailored content], you want to see what’s going on above the fold. And when you had something that had a lot of methods on it, you want to be able to get a glance what the API for that controller was or whatever it was that we’re creating. And by using the function names we were able to give you that at a glance. And then you could jump down if you were really curious about the details on a particular thing. And that was our motivation. They still [inaudible] about that.
JOHN: Ward, I don’t think he was talking about the function names inside of the controller. I think he’s talking about the actual definition of the controller.
JOE: Yeah, just the definition of the controller.
JOE: [Inaudible] say ‘angular dot module whatever dot controller’ and takes in two parameters. The first is the name of the controller and the second is the function.
WARD: Okay, so…
JOE: The style guide has the function defined elsewhere. And then you just put in the name of the, you pass in the name of the function.
WARD: Which would [inaudible] about what, three lines below?
JOE: Yeah, exactly.
JOHN: Yeah. So, for me it was whitespace and avoiding, what’s that thing called? The pyramid of doom?
JOHN: That nesting. So, that’s what it was about for me with that. But I do find a lot of people ignore that. Not a lot. But I do find a good number of people ignore that rule and do exactly what you’re saying, Joe.
JOE: Well, and I think that that…
JOHN: They like to nest it.
JOE: That is probably one that you would likely see ignored anyway because so many samples are shown with it inline and it’s small. And you learn from the samples. You grow from those, right? And then you get big and then all of a sudden you’re thinking “Crap. We need style guide.” And then you go and look and see and then decide at that point. “Hmm. Do I want to do this?”
JOHN: Yeah, and actually looking at…
WARD: That was one of the most important things about that design, about the style guide design, was that. So that people… [Inaudible] the invitation to please go your own way. The only thing we really think is critical is consistency. But before you go your own way, John says, we’ve actually… these recommendations aren’t arbitrary. And he’s thought about what the consequences would be going one way or another. And you get to see those things so that when you make your own decision to go someplace else you’re aware of the consequences of the decision you make.
JOE: Alright. So, I’ve got to ask a couple more questions based on the same train of thought. One, did you ever consider putting in multiple recommendations for the same thing?
JOHN: Yes. And at some point we had a couple of things that we had that for. And some of those have been trimmed quite a bit for various reasons. So, one example I can think of right off the top of my head was naming conventions for controllers early on. And I can’t remember them all, because some of them are gone. But I’m sure the GitHub history has them. At one point, Ward help me here on this, if you had a controller called developer. We were saying, this is what we see in the wild. You can call the controller, and I’m talking about the symbol, [inaudible] controller developer, or developer CTRL, or developer controller. There were all these different naming conventions people would name the symbol with. And quite frankly I think the rule at the time was pick one, run with it, and forget about it. And I got some feedback. Actually, at one point the style guide grew on its own, which is something we should talk about. It grew beyond, “Hey, I documented this because I wanted to remember it for me.” [Laughs]
JOHN: And it became “People actually like this.” And Igor called me up and said, Igor Minar of the Angular team, he said, “I would love to make sure I can go through this with you and approve it and make sure it’s what we have in mind and endorse it.’ And I said, “Cool.” And he did that. And one of the things he pointed out was “This isn’t going to work,” that particular rule I just mentioned. And I said, “I agree. But I don’t really know what the right way to go here is. I just think consistency is important.” And he had some really good reasons for not using CTRL. He said in his experience from the Angular team a lot of people were very confused over what CTRL was. Is it the control key? Is it a control like an input on a page? Or is it the controller?
JOHN: And this wasn’t just coming out of his head, but people had actually said this to him.
JOE: In Microsoft, CTRL is often an abbreviation of control as in…
JOE: The physical control, right? Visual control.
JOHN: Yup. And not giving it any suffix made it confusing in the context being used somewhere else, because okay what is that now? It’s developer. What the heck is a developer? A model or a what? So, those two were two that he suggested getting rid of and just sticking with the controller suffixing that was longer. IntelliSense autocomplete tooling makes that easy. So, that was one that evolved and started off as being one of those multiple options.
JOE: So, my next question related to that is: what did you do when you came to decisions where you didn’t feel strongly about one way or the other and you almost…
JOE: Felt like you were making an arbitrary choice?
JOHN: I usually grabbed a beer or two.
JOHN: I can’t think of a lot of those. I know we had many. But I’m struggling to find an exact instance of one for Angular 1. I’ll scan the doc and see. But I didn’t like documenting things I didn’t feel strongly about, to put it very bluntly. Because I wanted to be a… here was a… sorry, I’m rambling. But what I’m thinking about is when I wrote something down in the guide I made sure that I had a reason why. And there were several times when I wrote something and said, “Here’s what I do.” and then when I wrote the why, I [inaudible] of “I just do it because I like it.”
JOHN: And to me, that wasn’t enough of a reason so I would delete that from the style guide.
WARD: I think there was a…
JOHN: Because I [inaudible] think that’s not good.
WARD: Yeah. There was some back and forth about whether you register the thing with a module at the top of the file or at the bottom of the file because Dan and you had different practice there.
JOHN: Yup. Dan likes the bottom and I like the top.
WARD: Right. And then there was some confusion I think about what’s the best way to indicate… to beat the minification problem with dependencies. Should I use the array? Should I put dollar inject on the class if I’m going to put it on a constructor function? Do I do that before or after the constructor function? So, these are things that we could have gone back and forth on and I think you just picked something, right John?
JOHN: Yeah. On a lot of those, like the injection, we ended up picking. But we found a reason why, is kind of my point. And for a while we didn’t add injection, meaning the ng-inject thing. And the reason we didn’t is we were trying to figure out… we used it, Ward and I both. And [inaudible] apps. It’s not just me and Ward who were doing this, obviously. But the people who were using it were using it a lot but we couldn’t define why. And then later I realized the reason I do ng-inject even if the tool that picks those up can find it on its own is that I don’t want to have to think about it when I write my code of which ones are going to get picked up by the tool and which ones aren’t? So therefore, it’s really easy for me to just write a template that automatically sticks ng-inject on top of all these guys and just does the work for me.
JOE: I hate…
JOHN: So, that [inaudible]. Sorry, go ahead.
JOE: I hate all that stuff. I hate the… we ended up using, I don’t know if it was ng-annotate. It’s ng-annotate now, right? Is the common tool that people use.
JOHN: Yes. Yes.
JOE: To min-safe their code. But I think there’s a precursor to that back…
JOHN: It was.
JOE: in the day. We used that and then ultimately switched to ng-annotate. I hate writing the min-safe stuff in my code. And I hate looking at it. I feel like it makes my code way less readable. And…
JOHN: It’s ugly.
JOE: if you forget and remove an injection or add one and it’s a dependency, remove a dependency or add a dependency and forget to add the stupid inject statement, or to the array if you didn’t… the array is worse. The inject is better [inaudible]
JOHN: Oh right. The array is awful.
JOE: Because it’s spatially different. But the array just looks horrible.
JOHN: And to be clear, Joe. I’m not talking about the dollar sign inject. I’m talking about actually sticking a comment at, what is it, at ng-inject above the statement.
JOHN: Because I don’t like listing them twice because so easily do they get out of sync.
JOE: Mm, gotcha.
JOHN: So, we inaudible] comment. And actually today I probably would change that. Because when we wrote this, the ng-inject tool, I think it’s ng-annotate you mentioned…
JOHN: It wasn’t great at finding a lot of the situations on its own.
JOE: Right, right.
JOHN: Now it’s really good at finding a lot of those edge cases. And honestly, you know what drove a lot of that was when I wrote the style guide people were avoiding using that. They’re like, “I don’t want to use it.” And then I would see issues being opened up against ng-annotate of, “Uh-oh. My minification is breaking here, here, here, and here,” and the guy wrote it was fixing them all as it went.
JOHN: So, just the mere fact of me telling people to do this because you’re going to run into problems drove a lot of people to try it. They ran into the problems then they listed the issues. And I believe the ng-annotate tool now, I only know of one place where you actually need to explicitly inject or the tool won’t find it. And that’s when you define an object literal inside of a route resolve or that’s not pointing to a function that’s named. And in that case it has no way of knowing that you’re actually injecting.
WARD: May I just introject here and say I am so pleased that the two topics we’ve spent some time talking about here are virtually disappeared…
WARD: When you write Angular 2.
JOHN: Oh, I know. It’s so much crap we had to deal with. [Laughs]
WARD: Yeah. But… or ES 6 I believe. But if you can write Angular 2 in TypeScript, so many of these concerns…
JOE: Just disappear.
WARD: Mostly. Mostly disappear. And certainly the modularity ones.
JOE: That’s a great segue.
LUKAS: Actually, I have a funny anecdotal something I’d like to just bring up because I kind of laugh about it now, is on Twitter somebody actually commended on one of my blog posts that I wrote two or three years ago about isolated scope. And this individual is like, “This post is why it’s so much better to use some other, like paid proprietary framework over Angular.” And he was busy commenting on just how confusing the directive syntax for isolated scope was. And instead of smarting up I actually played the high card and engaged in some conversation. And we kind of arrived at some middle ground. But I kind of had to chuckle because isolated scope in directives was really, really complicated. And right at the beginning I was like, “Yes, confusing API aside this is completely solved in Angular 2.” It’s input. It’s output. And you’re done. And so, going from that confusing isolated scope syntax to just input and output is so much nicer and actually deflates a lot of those Angular 1 is confusing arguments for that reason.
JOE: Right. So, that’s a good segue to the Angular 2 style guide, right?
LUKAS: Where is it?
JOE: Where is it, John?
JOE: When will it be finished?
JOHN: It’s in your inbox, man.
JOE: I want to know when it’s going to be finished, like finished. It will be done. No more changes to it. And why that’s not already done. Why even have that for us six months ago?
JOHN: Well, part of it’s I have a day job.
JOHN: So, let me talk about where it’s coming from, but let me also… I feel like I should qualify this with that. When I originally started writing the style guide I didn’t write it intending it to be what it’s become. And I also didn’t write it intending for everyone in the world to use it as their Angular guide quite frankly. Like most of the time when I blog honestly. And doing the style guide, I did a lot of this because I was working with a lot of teams that needed it. And I found myself repeating the same things over and over again. So, I wrote this for a small group of people and for myself to remember a lot of these things. And by the nature of what it was and being public and open source it just picked up steam. So, it’s not like I set out to say, “Hey, you know what? I’m going to make the one guide that everybody’s going to use.” I just grew there. And I also would be remiss if I didn’t say how influential Ward Bell was to putting this together. Because he really was tremendously influential to making many of these decisions, unfortunately.
WARD: If you don’t like it, it’s my fault. That’s pretty much the way that boils down.
LUKAS: But you love it. Thanks, John.
WARD: Thanks John. And that’s how it should be. It grew organically out of conversations. And it’s true. You set out to try and make sense of the world you lived in and help other people see it the way you did. And suddenly it turned into a beast with its own life. And that was good. And it was good.
JOHN: And the reason I stress all that is the Angular 2 guide, there’s this tremendous amount of… first of all I’m not a guy who gets stressed out but there is a tremendous amount of pressure from a lot of areas to have it already exist and be vetted and fine-tuned, brushed along the whole thing of it’s perfect. And as I said, these things, it’s just not realistic to say that anybody out there including the Angular team has built these massive apps that they understand the best way to build everything. But that said, I have taken on the main I guess task of documenting a lot of this to figure out what are the things that we do know and what things will we know soon that we’re working on so we can put this thing together?
And for right now I’m putting it out into the same GitHub repo of the Angular 1 style guide. But I don’t think that’s going to be the final resting place for it. I think we’re going to try to find a way to pull it into the docs and I’m springing this on Ward right now live. One idea I had is to actually instead of doing some of the samples as Markdown inside of the triple ticks, actually do embedded Plunkers inside of the page to show people “Here’s what you do and here’s how this works.” So, some of these ideas are starting to evolve.
But it’s going to mean that not only are we going to need the community to help us but we’re also going to need people who are building the docs to help us, like Ward’s team, Igor who’s designing Angular, along with the rest of the Angular folks. We’re going to need people building the CLI tool and various other folks as well. There’s a linting tool that I believe Minko’s working on. So, it’s going to take a lot of people to contribute to say, “These are the things we agree with. And this is what we’re going to come up with here to go with.” And then there’s going to be a list of open items too, of “These are things we’re going to have to tackle. But we’re not sure yet what the right way is.”
WARD: Yeah. I would parenthetically add though also, when you think about this you’re thinking about a guide to Angular 2 development with TypeScript, am I right?
JOHN: Yes. Right now, that’s what I’m leaning a lot of this too. If you want to go back and use ES 5 with Angular 2, quite frankly a lot of this stuff is going to be the same as with the Angular 1 style guide because it’s still ES 5 oriented. But I also think it’s really, really, really painful to write ES 5 with Angular 2. I wouldn’t write ES 5 with anything that I could write ES 6 or TypeScript with today, to be honest with you. And there’s my big opinionated stance. [Laughs]
WARD: Yeah. But it would influence many, not all of the decisions, but many of the stylistic decisions. I think so.
WARD: I just wanted to put that caveat around it in case somebody was wondering.
JOHN: [Inaudible] for the TypeScript version of the Angular 1 style guide which I thought about making, but honestly I think it’s time to just put my efforts over to the Angular 2 guide instead. So Joe, is there anything in particular you’d like to see in the Angular 2 style guide that we could talk about?
JOE: Hmm. Well, I think we already talked about naming conventions, right?
JOHN: Yeah. Filenames and symbols, pretty much the same structure as in Angular 1.
JOE: Right. So, we’ve already got that part of it. What about things like pipes?
JOHN: I don’t smoke much, but…
JOHN: So, go ahead, Ward.
WARD: No, I was going to say, Joe, tell us what’s on your mind buddy? You brought that one up.
JOE: Well, I was just curious if there are already recommendations for naming pipes, dealing with pipes, that sort of thing.
WARD: Yeah, you call them pipe.
LUKAS: Dealing with pipe.
WARD: Foo dot pipe. I mean, that part we feel good about. The part that we’re not so sure about is whether and how much… how often you should write…
JOHN: How often you should use a pipe.
WARD: Should you smoke it or not? Now frankly if I were to look back at the equivalent in Angular 1 the filter, I was reluctant to write filters then either because of the performance implications. And I always felt that the logic that was in a filter, especially if it wasn’t reused, belonged actually in the component itself.
JOHN: So to me, there are two kinds of filters, Ward, and there are two kinds of pipes. The filters that I used quite a bit which were my way formatters.
JOHN: Date filters, date pipes, currency filter pipes, whatever. Perfectly wonderful. But beyond that honestly, I don’t use filters or pipes for a lot of that kind of stuff. I felt like it was just too much of a performance hit. And I would just write my own custom logic.
WARD: I think that carries over to Angular 2 where it’s actually very easy to write the equivalent of a filter, to write a pipe. I like to think of them as formatters. And I’m very wary of them. And Joe gosh, nobody knows this better than you from the work you did on the [inaudible].
JOE: Oh yeah.
WARD: How risky it gets when you start trying to use a pipe to manipulate large amounts of data.
JOHN: Yeah. I think the one pipe I’m leaving out of all this too is the async pipe. Because I think that’s a pipe that lends itself to a little bit more of discussion.
JOHN: Or custom pipes.
JOE: [Inaudible] category.
JOHN: Yeah, it really is. But as far as creating pipes go I think they’re easier in Angular 2 because there’s actually… there’s an interface you can follow and it makes it easier to know what you have to do and what you’ve got to transform. But beyond naming convention at this point, I agree with Ward. I’m still hesitant on creating pipes unless I absolutely have no other way.
JOE: Yeah, I don’t really want… this wasn’t necessarily supposed to be a discussion about pipes, but…
JOE: I’ve done a bunch of work with pipes. I’ve seen the problems with them. I wrote the documentation. I asked Ward if I could write the documentation because the existing documentation I didn’t think was sufficient. And I still feel like the documentation that I’d written is not sufficient because there’s a lack of guidance about when and when not to use pipes and really informing people about them. So, pipes are not my favorite feature, not because they’re not a great feature. But because I think they can lead you down into a rabbit hole that you might find to be a lot more bear traps in. That’s a really good analogy. [Inaudible]
JOHN: A rabbit hole with bear traps.
LUKAS: [A rabbit hole with] snakes that bite you with venom.
JOHN: Snakes. Why did it have to be snakes?
JOE: Why did it have to be snakes? Right. So, pipes as formatters. Love it. Pipes as not formatters, I think you got to really know what you’re doing before you start…
WARD: You got to beware, beware.
JOHN: Pipes as filters, not such a fan. Pipes as formatters, yes.
JOE: Yeah. So, that being said. Let’s move on from pipes. What isn’t in the style guide for Angular 2 right now but definitely will be in the style guide but just hasn’t had a chance to make it in there for one reason or another?
JOHN: Well first, if people want to check it out, if they go to the style guide in GitHub they can check it out. And the one thing I’ve made a change on is I actually broke it up into three readme’s. So, it actually branches from Angular 1 to Angular 2. So, you can check out what’s going on in Angular 2. There are some things. I’ll give you some of what’s in there and some of what’s not and that will be there. Some of what’s in there is I was able to copy over a lot of stuff from Angular 1, things like the rule of one. That’s in this guide, meaning we have one component per file, one thing per file, and recommended to be less than 400 lines of code. And I say that because I have seen more code in the last five years that is like 5,000 lines of code in a file. And everybody gives me every reason in the world why that’s justified. But I’m sorry, no.
WARD: Hey, Lukas is just getting started at 5,000 lines.
LUKAS: I only figure out what I’m doing after 5,000 lines. I’m like, “Alright, now it’s time to get down to business.” [Laughs]
JOE: Now, what you are saying, what I’m hearing is it’s okay to have 5,009 lines so long as it’s a single component?
JOHN: [Chuckles] There you go.
JOE: Well, alright to keep with this topic. I think the one thing that Angular 2 is going to benefit from is there is no Angular 1 seed that exists for Angular 2.
JOE: For those who were around three years ago when the Angular seed project existed, it had a whole bunch of actually bad conventions in it.
WARD: Oh, Joe. Don’t worry. There isn’t going to be one Angular 2 seed there are going to be 10 of them.
JOHN: At least.
JOHN: At least.
WARD: They’re already out there. And my only really strong recommendation is don’t use any of them.
JOHN: You know how many of the public Yeoman generators or Gulp generators or the Slush generators I liked using in Angular 1? Close your eyes and what do you see? Nothing. [Laughs] They were all painful because… and there was nothing wrong with them in the sense that they’re opinionated versions of how to do something. But I just felt like people should have more choice.
JOE: Right. Well, I’ve been recently playing with, I guess you would call it a seed project, Auth0 I think made it. It’s Firebase and Angular 2.
JOE: And oh my goodness, that thing is a bear. It is a big beast. Now, it’s great that it’s all set up and does what it needs to do. But it’s, man it is a complex starting point, that’s for sure. And it’s not really a seed. It’s actually a working project. But it’s the kind of thing you’d be like, “Oh, I want to do some Firebase for my Angular 2 project” and it’s the most common one you find if you start googling around for that. You might use that and say, “Alright, great. I’ll just start here rather than figuring it all out for myself,” and you start manipulating it and “Oh my.” It is quite a thing.
JOHN: You know, I think we’re going to have a lot of that stuff come out. The CLI team, command line interface team for Angular is trying to build something that’s not only a generator but it also does the build steps and the testing steps and the deployment steps and bundling, all that stuff. But it would be ideal, and I don’t know where it’s going to lead yet, but it will be ideal if the guide and the CLI match up which is one of the reasons I’m working with them to see where does this make sense.
WARD: I think John and I also, we have frequent conversations about our hope that there are ways to move in small steps and to not have to just push a [inaudible] and get this gigantic structure that you’re wondering, what is all of this? So, there’s a constant tension between the structure that we think you’re going to need someday and what you need to get started. There’s a real temptation to create that one starter set that’s got it all. That strikes us I think as a [inaudible].
JOHN: I’ve heard a lot of negativity about your quickstart by the way, Ward, which you were the author of.
JOHN: In one sense which may not shock you. So, the quickstart your intention was to start you off as small as possible, right? And people could build on it. Well, I’ve seen some negativity lately on it because people have tried to use that as the basis for large-scale apps and they’re like, “It doesn’t really work.”
WARD: That’s the temptation that we talk about, is because…
WARD: You need something that doesn’t overwhelm you but you can’t assume that that something that you learned on is going to carry you to a large application. So, we need to be able to provide the kind of guidance that says, “ Okay, now that you got there and you’ve exceeded the bounds of what that was intended for, how can you move step-wise to something that’s more robust?”
JOE: I don’t get…
WARD: But I see us doing that.
JOE: I don’t get the complaint about it. I’ve used it recently. I’m actually looking at it right now. I’m not sure that I understand the nature of the complaint with quickstart because I guess it’s not a skeleton for an app with 35 features already in it. But if it was to be a skeleton for an app with 35 features, how would you pre-name those features? In fact, even it is already a little bit more complex than you have to have like the typings for example. You don’t have to have typings to start off it. So, it’s already starting you down some good roads. I guess that’s somewhat subjective.
JOHN: The real key is Joe that when Ward and I played around and this is something Ward and I probably spend way more hours on than anybody actually realizes. I’ll bet you we spent two or three weeks [laughs] battling around how should it look?
WARD: On quickstart?
WARD: Absolutely. And that thing has been morphed so many times and we are in constant tension with do we add this one more thing? Because that could break people. And not in the sense that their code would break but it would cease to be quick. It would cease to be transparent.
WARD: So, it’s a struggle. It’s a real struggle.
JOHN: Well, let me give you a concrete tangible thing someone’s complained about. And I see their point. I really do. I want to have, and I’m playing the role of the person here. This one I used to hear a lot. I want to be able to not only put my Angular app in here but I want to be able to have my Node server also in this folder structure.
JOE: Oh, right.
JOHN: And I don’t like my source files to be in the root. I want them to be under a folder maybe called source. So, what they’re simply asking for is instead of making app the folder you put everything in, you have a source folder which then has a client and a server folder. And then under the client folder you’ve got an app folder. Which is fine. And honestly, that’s what I do in my production apps. But imagine the quickstart now. When you generate the quickstart you’ve got three levels of folders before you see the whole world.
WARD: Yeah, that’s exa-…
JOE: And that’s….
WARD: There are two files in quickstart that actually do anything in terms of what you can taste as the consumer of the app. And if it went… I can imagine a quickstart that went ‘source slash client slash app slash’ and now you got something. People will look at me and say, “What the heck are you doing?”
JOHN: Especially since Angular 1 experience. Sorry Joe, Angular 1 experience was you open a file, you write a binding, you put an ng-app in there and you’re ready.
JOE: Right. You link to one…
JOE: You link to one CDN file and there you go. You’re up and running. Well, I think it’s funny with the quickstart that it has one subdirectory app that has two components. Well, the main TypeScript file and a component as well in there, which is crazy to put a sub-folder just for two files, right?
JOE: And from this standpoint we just look at it by itself it’s like, well, you didn’t even need that sub-folder. You could have just put everything in the root.
JOHN: Yes. And you know why that folder is actually there? Because Ward and I went through this part. [Laughs] We were trying to get rid of it but to get rid of it we had to make special arrangements with the SystemJS loading.
JOE: SystemJS doesn’t like to load out of the root, does it?
JOHN: Yeah, we got it to work. But it made SystemJS configuration really ugly. And we’re like, “You know what? I think people will be okay with a folder.” [Laughs]
JOE: There’s [inaudible] that, right? You can either just give it the exact extension in the SystemJS load or you can do it in config apparently?
JOHN: Yeah. Or you can just avoid the extensions and just do them all in the import statements too.
WARD: But the more you do that, you pay an awful price right away everywhere else.
WARD: It seemed the cheapest price when we looked at all the variations like if I just paste this thing in and can start writing, how soon will I have to go back and touch that again? And this was the way to say, do it once and then you’re going to be able to spend many days before you have to go back and look at that again.
JOE: Firstly, I agree.
JOHN: And so, we [inaudible] you’re going to have a folder, right?
JOHN: You’re going to have a folder eventually anyway.
JOE: Personally I agree with that. You’re going to have some sub-folder. But the idea of, “Hey, I got to put my Node server in here,” well how does that help somebody who’s using Java or .NET on their backend? It doesn’t.
JOHN: No, right, right.
JOE: They don’t have the same concern. So, you’re catering to a subgroup of people.
WARD: You know what else I hated there but I couldn’t figure out what to do, is you look at that index.html and there’s a gazillion libraries at the top.
WARD: And the first three of them are just to deal with IE. Now, I didn’t have those there in the beginning. But then people would say it doesn’t work. And you say, “What doesn’t work?” “The quickstart doesn’t work.”
JOHN: Yes. Angular sucks. I’m going to React because you suck. That’s what it was [Laughs]
WARD: Oh, oh you mean it doesn’t work in IE or it doesn’t work in Safari? Oh. And so, I just didn’t want those calls anymore so I throw those things in the top. This is the life of somebody trying to come up with something that is small enough to get you going but [inaudible].
JOHN: And none of these are Angular concerns, right? These are all not Angular concerns at all.
JOE: So, outside of… to no be too nitpick-y here, why do you have your scripts in your head instead of in your body?
JOHN: That sounds funny. Sorry. [Laughs]
WARD: That’s a question that I have tripped over. And what I learned, oh gosh, he’s one of the authorities on browser performance, is that thing about moving them at the bottom, there are two things about that. One, browsers are smarter than when that advice first came out. And so, they do the right thing. So, actually having them in the head doesn’t hurt. The second thing to observe is that nothing happens Angular-wise until you get through those scripts anyway, so moving them to the body doesn’t leave you… doesn’t make the page start any sooner. It just… so, go ahead. Move them. See if it makes any difference. It won’t.
JOE: And since we’re using a system loader, it’s not like people are sticking in more scripts and are going to start filling up the head with slow loading scripts, right?
WARD: Exactly. As a matter of fact, the way we do it yeah, with a system loader basically again for development is you load one file. Then it’s you pay to play. Things load as you hit them.
JOE: And for those who may not know this, the system dot import statement which is in the head, it’s an asynchronous statement. So, it actually doesn’t start loading the file until the document’s been completely rendered and loaded.
JOHN: Yeah. I think…
WARD: Plus… sorry John, I wanted to say one more thing. The other part of it, the point of the quickstart is that it’s there to help you start learning Angular 2. And there have been people who wanted to put performance improvements in and it’s like, “Wait a minute. Wait a minute. You’re so far away from figuring out how to package this thing up and minify it and optimize it and stuff like that.” That’s not what this is about. This is about getting you going. And it’s a very different ambition than to come up with the optimal downstream solution for production conditions that I can’t anticipate anyway.
JOE: So, I want to circle this back around to the style guide by talking about that, and that is that it is difficult when trying to teach people things and give them advice because there are varying levels of where people are at and what their needs are, right? And if you consider people in one category you can potentially ignore people in another. So, people who are just learning, well you give them some advice that’s simple and easy to learn but later on if they keep going down that same road they might have some performance problems. If you give them more complex advice upfront, maybe they wouldn’t… it would be following a better performance pattern but yet have a more difficult time upfront. And that could happen… the same idea with the style guide, right? If you consider how you write the style guide, you’ve got to try to solve problems for the largest set of people, right?
JOHN: You do. And you want to, at least I want to and I’m defining this stuff and I think when Ward was doing the quickstart, the idea is you want to help people, put them on a path that’s easy to learn and won’t leave them in a place where they’re going to run into a brick wall later.
So for example, I’m teaching my daughter to drive right now. And it’s been a fun experience. But I don’t want to overwhelm her with every rule of the road when I’m driving. So for example, we were learning how to take left turns the other day on a three-lane road. And she’s asking me all these questions and there are all these different rules about when you take left-hand turns what you do. And she’s referring to the book. I said, “Look. Do you see the white lines on the road? The white dashes around the turn?” She goes, “Yup.” I go, “Just stay inside those.” Just simple rules in the beginning. And what that does, it puts them on a path to see where they’re going. The other rule she picked up earlier was, I’ll just follow the car in front of me. That works too, right? Now, those aren’t the rules of how you drive. There’s no law that says just follow the car in front of you. But you learn when you’re getting started with these things in Angular or driving a car that it’s easier to learn simple rules first that won’t later on drive you into a lake or off a cliff somewhere.
So, in Angular for example in the quickstart a lot of these things, and a lot of the style guide stuff is to say, “Hey, let’s put you on a path where you can be successful in small chunks.” And then when you want time to grow, there’ll be no refactoring that’s rewrite your app but it’ll be, “Okay, now I want another folder,” or, “Now I feel like I need a service and a component,” or, “Now, I need to do this and split these out.” It’s always let’s just break things up more as opposed to now I got to delete all this other stuff and start over. Does that make sense?
JOHN: I wanted to mention in Angular 2 some of the things that we didn’t discuss that are not yet in the guide which people are clamoring over. [Chuckles] And one of those is, what is the folder structure and how do you define what’s in an Angular 2 app? And I know there are a lot of opinions on this. And there’s no clearly defined great way yet. I have something in my head of what I think is probably going to be the way we end up running with based on a lot of feedback we’ve gathered. But I see many, many seed projects already and Ward alluded to this, where people are defining these folder structures for Angular 2 apps which I think it’s hard to define what it’s going to look like at this point. Because people are trying to take into consideration things like lazy loading. How is that going to work with modules and routes? How do you define features that could be promoted to an npm package later? Where do you put shared libraries? Do you do by feature still or do you do by feature and then by type?
So, there are all these questions that have to come out. And overall, I think the structure is going to look very similar to what’s in Angular 1. But I think we’re going to have to take into consideration some new things because technology has evolved. And now things like lazy loading, we can actually make some different changes that will improve it. But that’s not there right now.
WARD: I know we’re sounding very diffused. And the fact is that there are certain emerging patterns that are Angular 2-ish and we have to pull them together. But it’s still… what you’re hearing is some hesitancy to codify them just yet.
I’ll give you another example. I have a feeling about how to organize to use the router, how to organize your code to use the router. But I don’t want to mandate it yet until I’ve seen enough examples that prove it out. So, there are some emerging patterns there that I think are going to turn into recommendations but let’s not jump the gun.
JOHN: I want to give you some tangible things that are there. So, here’s one in the Angular 2 style guide. I put the link in the notes. There’s this defer logic to services. It might sound familiar from Angular 1. That still stays the same in Angular 2. We still want to take our logic out of our components and move them to services for sharing purposes. And to keep those component slim and trim. Another one might be, “Hey, look. Services are singletons.” So, keep this in mind when you’re building things. However you can also provide services. You can use the injector which is hierarchical in Angular 2 to define services at multiple levels and have multiple instances if you want to. And I define some ways on how you can do that in the guide. But then we’ve got some things that are more stylistic like how do you define your public and private properties? How do you sequence them? So, all that stuff is there as well.
WARD: When should you use decorators? When should you use the metadata arrays that are inside the ‘at component’ decorator? We have little… we have very specific recommendations along those lines, too.
JOHN: And one of my favorites which I haven’t written yet but I’d love to put in here is the concept of a barrel. I really like this. It didn’t exist with the Angular 1 stuff but becomes really important in Angular 2. What a barrel is, is let me describe the problem. So, we have let’s say a folder called shared stuff. And inside of there I’ve got five pipes because Joe likes pipes. There are five pipe files. And then we’ve got components and we’ve got some services and we’ve got some directives. You’ve got a whole bunch of things. They’re all in this folder and they might even be in nested folders under this shared folder. Okay.
So, let’s say I’m building as component in another folder called I don’t know, customers component. And the customers component needs to use seven of those shared things. So, now I’ve got to write seven different imports statements because all seven of the things might be in different files. So, at the top of my customers component I’ve got seven lines of code that’s kind of yucky. That’s a technical term for garbage. So we say, import such and such from this shared folder, import such and such from that shared folder. And instantly your component looks really verbose and hard to read. So, one of the ideas there is a barrel. Wouldn’t it be great if we could just have one import statement of the top of that customer component that says import these things from this shared folder? Well, we can do that by creating a barrel inside of the shared folder.
And the barrel essentially is a file that does two things. It imports everything under the shared folder and then it exports those immediately. So, therefore we have one point in the shared folder that says, “Go find everything under this directory structure and then re-export it.” That way your import statement stays really, really tight inside of all the places that we import shared stuff. And this is something that Angular 2 uses. So, that’s why we can say things like ‘import component from angular 2 slash core’ because they use barrels inside of Angular 2 to make it easier for us to not have to remember where is everything located. Did that make sense? Or did I totally muff that?
JOE: Sounds good to me.
JOHN: Did you guys notice a lot of times you’re writing demos you end up with a component and you’ve got 20 lines of imports at the top of the page? And it’s like…
JOE: Oh yeah.
JOHN: What happened here?
JOHN: So, the barrel is a solution to that, because I got tired of showing demos in front of people and their jaw’s hitting the floor. Angular 2 looks hard simply because they see all the import statements. So, that was a way to help solve that.
JOE: Alright. Well, I think that we’re reaching the end of the time for the episode anyway. This was actually a really awesome episode. I love episodes like this and very interesting for the near future as we see the style guide get fleshed out. So, we’ve got links in the show notes to the style guide. I think it’s also very easy to find. And if you just google Angular style guide because it gets to the one repo that links to both style guides, Angular 2 style guide is in a pretty short form right now of course, right?
JOHN: Yeah. There are only about 20 rules in it right now, or 20 guidelines in it.
JOE: Right. So, great place to check out for more reading. Let’s move onto the picks, shall we? Ward, do you want to go first?
WARD: I’m picking The Warriors. [Laughs] Like you got the Star Wars to follow, I am watching Warriors basketball and I’m loving it. Of course, I’m from here. So, if you’re not writing in Angular 2 then you should be watching The Warriors.
LUKAS: The Star Warriors.
WARD: Beg your pardon?
JOE: Star Warriors. Nice. Nice, Lukas. Nice. Hey Ward, what do you call a Warriors fan two years ago? A Lakers fan.
WARD: [Laughs] Yeah no, I’m a bandwagon guy. As soon as they suck again I’m going to stop [inaudible].
JOE: [Laughs] I’m out. I’m out. They are playing the Jazz tonight.
WARD: They are.
JOE: [Inaudible] Utah, yeah.
WARD: And you know what? They got on a plane at 2am in the morning last night after playing a hard game and they have to play again tonight. It’s not fair but they’re still going to win.
JOE: Life’s rough. Life’s rough for those guys. I feel bad for them.
WARD: I do.
JOE: Yeah, yeah. Crying in my beer over it. My root beer of course. I don’t drink beer. Alright, Lukas. How about you?
LUKAS: So, my pick this week is the NPR Tiny Desk Concerts which you can find on YouTube. And it’s just basically they have people come in and do concerts at the desk of the NPR offices. There are just a ton of really great acts and I discovered a lot of really neat artists that I didn’t know about.
And then my sub-pick is there’s a band called SNARKY PUPPY which also did this NPR concert. And I had forgotten about them but Matias Woloski who is one of the co-founders of Auth0, his brother Marcelo is a percussionist for SNARKY PUPPY. And it’s this jazz fusion band that’s just super awesome. And so, my picks this week are the NPR Tiny Desk Concerts and SNARKY PUPPY. Super awesome music.
JOE: Awesome. John, how about you?
JOHN: I’ve got a couple here. One is I’m really excited to pass along the news that hopefully most of you’ve heard by now. Microsoft is adding the Linux command line to Windows 10. So, we’re actually going to have full Bash. Not [inaudible].
JOHN: But real Bash running on Windows. So some of us, I know Joe you’re a Windows guy, right?
JOE: Yup. Well, yes and no.
JOHN: So, this [will be] pretty cool.
JOE: I’m a Windows and Mac guy. I’m half-and-half.
JOHN: Yeah, and I’m mostly Mac.
JOE: The left half of me is Windows. The right have of me is Mac.
JOHN: Well you know, the reason it’s exciting to me is most of my developers at work actually use Windows. So, this will make their lives a little bit easier so they don’t have to convert over.
JOE: I am a Bash shell guy though. On Windows I only use the Bash shell which when I record Pluralsight courses I’m sure confuses a lot of Windows developers.
JOHN: Yeah. It’s going to be pretty exciting to see where this leads. To even think how monumental this is, me being a guy… I used to work at Microsoft five years ago. And back then to think that they would do this, you would be walked out of the building. [Laughs] So, it’s pretty monumental to see this change.
The second pick I have is something called RAML.org. It’s a RESTful API modeling language. And they [pick] themselves as an easy way to design APIs. It is YAML which I’m not a huge fan of. But it’s a great way to think of… think of it like swagger for APIs. Instead of documenting it so much you can actually design the APIs using a YAML structure and then it will generate some of this stuff out for you. So, it’s kind of neat. It’s something I’ve been playing around with and it’s a nice little tool. Oh, and by the way I’m picking Star Wars.
JOE: Good job. Good job. Alright, is that it John?
JOHN: Yes. Yes, ma’am.
JOE: Thanks for being so respectful.
JOHN: No problem, Joe. [Laughs]
JOE: Alright. Well, I also want to pick Star Wars because I just saw it for the sixth time [inaudible].
WARD: You guys.
JOE: But instead of picking actually anything, there’s one pick that I want to make. And that is I want to pick listening. So, there’s been a ton of stuff I’ve been reading about on the internet. Some controversies in the tech world, other things, and the politics that are going on, the one thing that I keep running into over and over again is a whole bunch of people shouting at everybody else, wanting them to listen to their opinion and being completely unwilling to listen and be respectful to other people’s opinions. And there was a tweet that John, you sent out a while ago related to this. And I just… it’s actually been not just on my mind but actually like a bother to me recently, how incapable people can be of saying, “I disagree but I’m willing to at least listen and hear your side of the story” and in the end make the assumption that you don’t choose your opinion based on the fact that you’re a horrible person but instead that it makes sense to you.
JOHN: You mean, like how we talked about the style guide and how you disagreed earlier?
JOE: Yeah, exactly.
JOE: Exactly like that.
JOHN: I mean, it’s the way you should take it, right? There’s no offense on either side. You just state your points. And why can’t all developers have conversations like that, Joe, huh?
JOE: Yeah, yeah. So, there’s been definitely just some interesting stuff and people getting really upset at other people for the decisions that they’ve made. And just an inability… people being completely incapable of just being able to sit and say, “Alright. Tell me what you think, and in the end I’m still going to do what I was going to do but at least now I understand what you’re saying and why you’re saying it, what your opinion is and what your position is.” And I think that the world needs a lot more of that and gets very little. And I see it all the time on the internet. In fact, it comes from the people who are telling other people that they are not listening. [Chuckles] It’s amazing how little people listen to each other. And I’m probably no better at it than anybody else. But I certainly see…
JOHN: We all do it, man. We all do it and I think it’s important to remember sometimes, how would you feel if you were on the receiving end of what you’re about to say?
JOE: Right. Absolutely. The ability to say “I disagree” but I will listen to what you have to say. You’ll listen to me. We’ll understand each other whether we agree or not. Because people are never… you’re never going to get everybody to agree but at least they can sit and listen and understand and be respectful. And we need a lot more of that in our world. So, that’s my pick.
LUKAS: Well said, Joe. I appreciate that.
JOE: Kind of a rambling statement but there’s my pick. Alright, that’s it for our episode. Thanks guys, for an engaging and fascinating conversation. And thanks for all the listeners. We’ll be back again next week.
[Hosting and bandwidth provided by The Blue Box Group. Check them out at BlueBox.net]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to AdventuresInAngular.com/forum and sign up today!]