Using AngularJS at Google with Rhys Bret Bowen | Front-End Developer Cast Episode 4

Craig McKeachie: [0:01] On this episode I interview Rhys Brett-Bowen, Google Engineer, about using AnguarJS to build applications for Google. This is “Front-End Developer Cast, Episode 4.” [theme music]

Craig: [0:19] Welcome to the Front-End Developer Cast, the podcast that helps developers be awesome at building ambitious web applications, whether you’re JavaScript ninja or you’re just getting started. I’m your host, Craig McKeachie.

[0:31] Hi everyone. Welcome to the fourth episode of the podcast. I’m working today on getting my processes down for the podcast, as well as, hiring some help editing the podcast and getting it live on the site every two weeks. So I’ll be able to more easily keep bringing you more great interviews.

[0:44] I’m also getting help designing and setting up a page to sell my book on mastering single-page applications. The book, right now, I’m finishing the last couple of chapters, editing and working through some ember.js code samples. I’m hoping to make the book available for pre-sale at a 20 percent discount in the next few weeks.

[1:01] If you have any interest or you want some more great free content, go to my blog at “funnyant.com“. That’s funnyant.com. Sign up for my free seven day e-course, the “JavaScript MVC Comparison” and you’ll get notified when the book launches.

[1:17] If you haven’t subscribed to the podcast, please do so by going to the iTunes Store on your phone or desktop, then searching for “Front-End” or via RSS by going to funnyant.com. We are also available on “Stitcher”.

[1:29] If you’ve already subscribed then take the time to leave a review on iTunes. This is the best way for other people to find out about the show.

[1:35] Today’s interviewee is Rhys Brett-Bowen, who is a Google Engineer currently using AngularJS to build applications for Google. We discuss his experiences good and bad with AngularJS, and talk about details of the Google technology stack for the project which I found fascinating.

[1:50] In particular, they are using ProtoBuf, which is short for Protocol Buffers, Google’s data interchange format, and the Closure Compiler.

[1:59] Here’s the interview.

[2:00] Hi, I’ve got Rhys Brett-Bowen with me today. He is a Google Engineer at Google in their New York office and has been working with Angular on their most recent project. We’re going to talk through his experience with that, as well as, some of the other tools they use it Google, and the JavaScript, and front-end web development space. Welcome to the program.

Rhys Brett-Bowen: [2:21] Thank you.

Craig: [2:22] Tell me about the app you’re working on. Maybe not from a technical standpoint at first, but what does the app do? So the end-users have a feel of the UI and that sort of thing.

Rhys: [2:33] I am working on a BitManager team. What we’re currently working on is the reporting page. It’s not exactly a quick app. It’s all done in Java and that gets compiled down into JavaScript.

[2:45] What we’re doing now is, and in a lot of places in Google, we’re looking at trying to move things over to using Angular. We’re looking at changing just the recording section at first, to use Angular. That’s what we’re doing. It’s a list of reports that you can run. Different types of metrics, filters. and things that you can choose on the report to run.

Craig: [3:06] Is this “Google AdWords” that you’d be working on?

Rhys: [3:08] No, it’s something called BitManager. It does dynamic reading of prices when the apps go out.

Craig: [3:22] That’s very interesting. Which version of Angular are you guys building this app with?

Rhys: [3:27] The latest one, it’s 1.2.

Craig: [3:32] Was there any browser considerations when you guys made that decision in terms of supporting versions of IE or not supporting that sort of thing?

Rhys: [3:39] I feel like regressing, they’re dropping IE 8. [laughter]

Rhys: [3:43] I don’t think you can really choose Angular 1.2 or 3, we’re going to get that back. Traditionally Google does like to encompass as many browsers because it’s not out there for the ready. Internet use is there for specific clients.

[3:57] We don’t have to worry too much about which browser or IE 8 or all the browsers.

Craig: [4:03] Version 1.2 does not support IE 8 back, is that correct?

Rhys: [4:08] I don’t believe it does. They’re dropping it soon.

Craig: [4:11] You’re dropping it soon. I definitely heard that. I was trying to remember if that’s 1.2 or the version after that, whatever they’re going after that. I’ll look that up and put it in the show notes for our listeners. Can you give me an idea of how long you’ve been working on the app and whether it’s in production or whether you’re still working on it?

Rhys: [4:27] I’ve been there for a couple of months now. I’ve only been working on it for two months,taking it from nothing to where it is. It’s not in production. It’s getting close to a point where we can at least start putting it out to beta users.

[4:42] A lot of the time we’ve spent on it is figuring out how to use Angular going forward for people. Whether or not for the other developers who are going to come in and, as we go on, what are the best practices to use, how we should set up the app, and all that stuff.

Craig: [4:59] You’re setting up a framework for the framework, right? [laughs]

Rhys: [5:01] Yeah. [laughs]

Craig: [5:04] What other dependencies in libraries and so forth are you using on the project?

Rhys: [5:08] We’re working with closure tools which has a compile. We have to make it so that it works with the compiler. The compiler does some things like renaming of variables so and so and places you have to make sure things like new quick keys and objects — they get their strings, if they’re going to be exported to the template.

[5:28] Thing about an Angular application is that all your logic and all your code isn’t exactly in JS files. A lot of them can be in templates. If you want your template to be able to access a property that’s there, you have to be aware of whether or not that property name is still going to be there or is it going to be compiled away.

[5:47] You have to figure out which of those properties you want to export so that you can keep that in line.

Craig: [5:53] It compiles away templates as well. I didn’t realize that Closure…

Rhys: [5:57] Oh, no. It doesn’t compile a template. That’s the problem. [laughs]

Craig: [5:59] OK.

Rhys: [6:00] It’s not that good yet. They’ve done a lot of things around the dependency-injection. Before, when you had dependency-injection — Angular does a thing where it looks at the function of two strings to find out what the class it should inject into the services and so on that they have. That name can get changed when you run it through a compiler.

[6:24] Then that does not match to the string that you’ve got anymore. They’ve done things where, the compiler can look at things like annotations that you put on comments before functions. It looks for the special annotations, called nginject, and that just tells the compiler, “Wait a second, we actually want to inject this.

[6:42] This is what Angular’s going to be injecting into, so don’t rename these certain properties.”

Craig: [6:47] It’s mostly things, either properties or things, being passed in the constructor as dependencies, and you don’t want to rename them because then the code would break at that point.

Rhys: [6:58] Any variables that you’re just using inside a function, that’s fine to rename. The problem is when you’re sharing things like objects of properties or anything across functions or across files.

[7:09] If it gets renamed, you’re going to have a problem because they might get renamed in two different things or maybe one does not get compiled. So then it’s expecting the original name and it didn’t compile that.

[7:20] Closure does a great job of renaming things even when they’re across files, but it only really works if it has all the code to look through. It parses all your JavaScript and figures out what things are being passed to where, so it knows to keep the names the same.

[7:36] Fortunately, with things like Angular, it can’t parse the templates, so you can’t tell what things you’re going to be using in the template. It doesn’t know not to rename those, so you’ve got to tell it not to.

Craig: [7:46] Interesting. Does that make for some noise in the code that, at least I personally wouldn’t appreciate, or you’re used to it and it’s not a big deal?

Rhys: [7:54] I’ve been using Closure for a while now, so I’m used to it. Although, when I originally used it, it was just in one giant application so you didn’t have to worry about the renaming. Usually, it will all work. As long as you give it all the code, it will work.

[8:07] The problem is — it’s not too bad. All it means is whenever you’re defining things that are going to be in the template, there’s a certain comment that you put on it saying, “Export.” Which is to say, “This is going to be an exporter probably. Don’t rename it.”

Rhys: [8:21] There’s the nginject one. As long as you’ve got those two in there, it fixes everything.

Craig: [8:25] OK.

Rhys: [8:27] These annotations that are going in, if you’re doing things with Closure, you want them in there anyway, because the annotations, you can also put things like type information against. When you do your compile checks, it’ll check things like types across files and so on.

[8:42] You know it can catch a lot of errors that way. While you’re doing it, you check on an export saying, “Oh, what’s a type, this, and I also want this to be available to the template.”

Craig: [8:49] OK. That’s helpful. For some people, the concept of a JavaScript compiler is a new concept. I’m maybe oversimplifying what I think about it as minification and combining, but it’s not just that. It’s more complex. The Closure one is more complex than that, right? It is all about making the code small and tight, but it’s doing a lot more elaborate things, correct?

Rhys: [9:14] Yeah. There’s that, and it can increase performance by figuring out where things go. It even knows a little bit about gzip, so it will not only try and make the code smaller, it’ll make it smaller for when you gzip it up. It does check types and so on. –information for you. If you’re working a team, you know what type of types are going into functions.

[9:33] It’ll throw out errors saying, “You’ve created a new function. It doesn’t work with the type that you’ve given.” It does a lot of things. At first it seems a bit scary, [laughs] but once you get the hang of it, it helps speed up. A lot of the problems you come up against JavaScript, you only find at runtime. It’ll find those for you.

[9:50] If you’re passing the wrong type, it’s not going to throw an error in JavaScript until you run it. Even then, it may not throw an error, because you can have type coercion and so on. If you try and say, console-log something or print something to a screen, you might be passing an object instead of a string. You wouldn’t know that. It’ll print an object happily enough for you.

[10:07] It’s just going to have curly braces, and you’re going to think, “Why is that there?” These things can go into the program. They can be deep and they can be hard to find.

Craig: [10:14] This is more about the linting part of the compiler, correct or am I overstating?

Rhys: [10:19] Linting is more how the code looks. It’s not the types and the things you pass through. It gives you type checking which you get from a lot of stronger type languages like Java and so on. We define the types. It’s kind of like that.

[10:32] It’s like typescript, where you can put types of things and it will throw errors if you put the wrong type in the wrong place.

Craig: [10:39] Thanks, I think that helps. Any UI libraries or do you guys stay away from that stuff on the project? For the animations, you mentioned some reporting — D3 or anything like that?

Rhys: [10:50] We haven’t…What we’re doing is we’re currently creating the report. You have another thing that displays reports. Most of the reports that come out of [inaudible 00:10:57] CSV format, so we can cut and send that straight to the boot. A lot of avatars — They like to work with Excel, so we give them that.

[11:07] There will be something coming out with visualizations and so on. We’ll definitely be looking at get D3 to do that.

Craig: [11:15] How much testing are you guys doing on the project so far? What testing stories — both end to end and unit?

Rhys: [11:22] At the moment we’re putting everything under unit testing. Everything we’re creating we’re making tests around. End to end testing is something we haven’t started yet. We’re looking at hopefully trying to use Protractor for that, because it’s at Google.

[11:36] There are also other Google technologies. It’s a bit strange how it’s run and how it’s built. We’ve got to find out exactly…a little bit more fiddly to get the set up there. Everything at Google, they try and do at scale. Everything’s a little bit more fiddly to set up, but once you do it will run for ever. We’ve got to do a bit more research into that and figure out how we’re going run it.

Craig: [11:56] Why not — It’s Google. Why not Karma and formerly know as Testacular? Why?

Rhys: [12:02] We do use those to run unit tests. End to end testing, integration tests is a different beast altogether.

Craig: [12:12] What was the process for you? Were you on the project at a time when the technology was chosen and if so, what was the process for choosing Angular versus other beasts, C frameworks, or other frameworks?

[12:26] Rhys, No, I don’t think I’ve ever been on a project which gets to choose a technology. I usually get called in at a time when people want to fix it up. [laughs] “That’s not working for us. Can you help me out?” That tends to be the time when I join teams for some reason.

Craig: [12:41] Then there’s the obvious thing, that you are working Google. It’s a framework supported by Google.

Rhys: [12:47] Yep.

Craig: [12:48] That’s a pretty good choice. How’s it going so far? In terms of what comment on your experience with the features and so forth. What have you really liked when using Angular? Then we’ll move to the cons, I guess?

Rhys: [13:07] Using Angular, it’s been a bit of fun really. There are some things to try and get your head around, but once you do it does starts to make a lot of sense, especially how things are built. The Angular code itself, if you go and read that, it’s not too bad to figure out how things are working and what things are doing.

[13:25] Most people say background track because you can read it in a day. Angular might take you two days. You can still do it. There’s still parts of it you can go in and realize what’s happening and how things are working. That’s a lot of things I like about it, it works like magic in some places. Sometimes you can throw your hand and say, “Why isn’t this working?”

[13:45] That’s only on the first couple of days if you start using it. Afterwards you realize what some of the best practices are for it and that’ll keep you away from a lot of errors. Even things like when you’re dealing with scope. Instead of trying to use a single property on the scope tree, you want to have an object on the scope, then deal with properties on that object.

[14:06] Using that will keep you away from a lot of scope problems.

Craig: [14:09] What kind of problems have you seen? By putting a property directly on scope as opposed to an object with a property? I’ve definitely heard this before.

Rhys: [14:18] Probably a big example is when you use a directive it may create a new scope. When you try and deal with new…Scope in Angular works like prototypes inherent in JavaScript.

[14:33] If you put a property on a prototype, and use this.something equals in JavaScript, you won’t overwrite…depending on the prototype, you’ll overwrite the thing on the instance. Scope’s the same way. If you get an inner scope and you try and overwrite the property, all you’re doing is changing the property of that inner scope. It’s not going to change the one on the outer scope.

[14:54] You come across things like that with, probably, directives that you don’t expect to create new scopes. Things like the transclue — Anything you transclue, ngtransclue creates a new scope trial. If you’ve got anything within that, a lot of the time that you come across things like…

Craig: [15:10] So, people get scared by the word transclue. Can you break that down for us? It’s rather simple, as I remember, when you learn it, but…

Rhys: [15:16] Transclue is very easy. It means put whatever inside the element. When you have a transclued…

Craig: [15:25] So, there’s no spacetime continuum happening there or anything?

Rhys: [15:27] No, it’s just something not fancy, unfortunately. It would be cool if it did.

Craig: [15:34] If you have an existing dom element and it has some content inside of it, it means leave that there as well as append to it, or it means…?

Rhys: [15:41] It takes the child away. Put in a temporary variable for the moment.

[15:47] Whatever the template is, it puts that template in its spot. Then it looks through that to find out the element that says ngtransclue. That’s just a little marker that says, “Put the content back in its spot.” That’s all it is. It just means that everything in that template you put in also has its own scope.

[16:03] It’s called an isolate scope, because it doesn’t have anything to do with any other scope around. It has its own properties. Then everything within the ngtransclue that you put in, inherits the scope from before, so that everything you put in there works as you expect, except that it’s in a new scope, that’s inherited from the old one.

[16:21] It just gives you another level down in the scopes. All your properties are there and you can get to them, but the thing is, if you try to apply to that, you’re trying to apply on the instance rather than the prototype from the example before.

Craig: [16:38] That’s a good explanation. Thanks. What did you find confusing or problematic when you first started working? You touched on a few things already.

Rhys: [16:49] A lot of people said the documentation isn’t the best.

Craig: [16:54] Comical though, sometimes reading the comments underneath.

Rhys: [16:58] I find that about 50 percent of the time I go looking for answer. The answer I’m looking for isn’t there. You try and figure it out for yourself. I guess if someone wrote the documentation as they were trying to build the Angular update, it would probably be better, because then they would say, “This is the kind of thing I want to know, maybe I can go and add that into the documentation.”

[17:16] That was the hardest thing, trying to figure things out to begin with.

Craig: [17:20] What are the things you really like? Data binding is a common feature that’s demoed. Does the gloss wear off on that after using it for a while or do you…?

Rhys: [17:32] People talk about two-way in data binding. Date binding is extremely useful. — two-way data binding, not so much.

Craig: [17:39] Let’s talk about the differences there. That’s an interesting conversation I recently had with someone. I’d like re-have it here.

Rhys: [17:47] Two-way data binding means any changes you’re making on the view will go and populate itself automatically onto the model and then vice versa. Then any other model come back. Normal data bonding means that whenever you change the model, view update. If you update the view, it’s not going to update the model.

[18:00] It’s not really that big a problem because then you can always put on another directory and say “Oh, when this changes in the view, go and update the model.” You can just pop that on. Two-way data binding isn’t a huge thing, especially done through ngmodel. It’s not done with inputs anyway. It’s not a big thing about it.

Craig: [18:18] In other words, most of the one-way data binding — When people talk about one-way data binding, they usually talk about going from the model to the view. That’s the most useful thing that most people need when building an app. When there is an input, sometimes it’s useful to have it go from the view back to the model automatically. You’re saving one line of code or whatever. It’s not…

Rhys: [18:36] It’s a bit of syntactic sugar. Two-way data binding isn’t as big a thing as people make it out to be. That’s all it is. It means that you’ve got an extra thing that will go back and tell the model to change.

[18:47] Probably the only thing that I found that I still don’t like too much about Angular is that when you put things in the template it has a scope.doublewatch. There is something on scope that’s called “Watch.” Then you pass it a function or something and then it will act to see if there are any changes.

[19:05] It uses an equality comparison unless you add in an optional parameter to that watch. If you are watching an array and you change that with another array object, — or even if you have an array,it’s got things in it, and you add things to it — It’s not going to say that’s changed because the object is still the same, unless you put that true in.

[19:25] That’s fine. I don’t mind that in the code. The problem is when you try and do things in the template because there is no way to pass in that optional variable to watch. Everything is done on equality. This is a problem when you’re doing things like trying to — where if you have a function that filters an array because if you return a filtered array, it’s a different array.

[19:45] Every time it goes through the watch thing or it goes to check if it’s different, it’s different every time because it’s a new array that you have got there. You might have filtered with the exact same elements, but it thinks it’s different.

[19:55] That’s the worst thing that I have found, that you can’t really tell in the template the array is going to be different, but check the elements under the array, don’t just check the array to see if it’s the same array.

Craig: [20:05] Right.

Rhys: [20:06] That’s probably the worst thing that I keep coming against. Every time that comes up saying the watch statement has gone through too many cycles, I know it is one of those somewhere around there.

Craig: [20:18] Right. Have you gotten into any of the browser plug-ins to use to help debug things?

Rhys: [20:24] No, I know there’s better rankings but not really. I’ve found there has been hardly any problems with it. I haven’t found any big bugs I’ve had to go too far into to find out.

Craig: [20:39] Let’s see, where are we here? Let’s talk about the architecture. Sometimes frameworks like Backbone provide a lot around the model, whereas Angular prides itself in plain old JavaScript objects. Tell me about how you’re organizing things in terms of services in factories and your actual model entities and how that’s working in your application. How you’re going to set that up.

Rhys: [21:04] A lot of people who use something called Protobufs. It’s not JSON. They’re different. There are still objects that come through but you have to call, get something, and set something on it. We use a lot of those to do it.

[21:18] We find that using those straight from the server, we can plug in whatever we need. Originally we used Protobuf because you’re using separate languages in Java and so on. Then all you have to do is run whatever the Protobuffer thing is and it will give you the class definitions for, and how it should be, the class definitions in JavaScript, in Java and everywhere else that you want to put it.

[21:39] It’s very small over the wires, as well, because it’s all done in arrays. There are no keys put in because the keys are put in the class definitions that are generated for each language.

Craig: [21:48] Is this a Google specific thing or an open source?

Rhys: [21:50] It’s an open source thing. Google uses it a lot because it’s small and fast. It’s not as flexible as JSON because it has information on it, like types and so on. It works well with stuff like Closure tools because types are already there and you can use it.

Craig: [22:04] Oh. OK.

Rhys: [22:05] It’s an open source thing and we go and use it. The difference is it’s not as flexible because you’ve got all these type considerations and so on. The great thing is you can use it with a Java backend and it will be the same thing going between them.

Craig: [22:17] Right, that’s interesting. Obviously, you guys are using Java on the backend, so that the database is…?

Rhys: [22:24] I don’t know, [inaudible 00:22:23] . I think it’s a proprietary thing. What they’re doing with the database is, they’ve got — they use a big table, the Google thing they use to store it. They’ve got stuff on top of that to store it different ways and do everything it needs to.

Craig: [22:40] OK. We’re here at Code Mash, I didn’t mention. We’ve got some people coming in and out of the area, so don’t mind that. That covers a lot. Maybe you could talk a little bit about what you’re using. Are you using an ID or are you using a text editor bin. What’s your world like there?

Rhys: [22:57] You’re allowed to use anything you want there. I use the Sublime Text, personally.

Craig: [23:04] OK. Sublime Text and they’re OK with it. In terms of building the client side stuff, are you guys using Yeoman, Grunt, or Bower, any of that?

Rhys: [23:14] No, we’ve got a Google-built system. They’ve got their own stuff that they do to build things.

Craig: [23:20] Yeah. That makes sense. Require JS or any AMD-type stuff going on for modularity?

Rhys: [23:29] Closure tools has its own thing for that.

Craig: [23:31] Yeah, sorry.

Rhys: [23:33] It works on name spaces. All you have to do is set up your files and at the top of it you say , “Do dot” — What is it? I don’t have a word for it now. [laughter] [crosstalk]

Rhys: [23:43] Do.provide, I think it is, yeah. You do do.provide, you say, ” What name space you’re exporting from that file,” anything you need unneeded you say, “do.require” and just put that name space in. Then what they have is a runner that goes through, looks at all the files, figures out the graph of how things are dependent, and then adds them in together.

Craig: [24:01] OK.

Rhys: [24:03] That’s all you need to get into your work.

Craig: [24:05] Did you use Closure quite a bit before this on other projects and so forth, because it sounds like it’s a big part of the picture here?

Rhys: [24:13] I did. There was a company I worked at called [inaudible 00:24:16] back in San Francisco. That’s where I got introduced to Closure. Yeah, they were using plain Closure to build their system.

Craig: [24:26] Great. Anything else you think listeners or front-end developers would be interested in hearing about the project that I haven’t asked? We covered everything. What about authentication in your application?

Rhys: [24:37] I think that is still dealt with by the quid section at the moment. We’re trying to replace the single pages within that application as we go. It all runs in route loops so all we have to do is say in the original applications, “For this route, now open up this Angular application’s page with Angular on it.” Angular is a library.

[24:57] You can say “OK, add in the Angular thing.” It will run as it needs to. You don’t have to go in and throw away your old application. That’s the wrapper for it.

Craig: [25:04] Yeah, successful. Thanks for being on the podcast today, Rhys. We really appreciate it and I think the listeners will get a lot from this. I like hearing about what’s happening in the real world, especially inside Google. I’m quite intrigued. Thanks.

Announcer: [25:18] Thanks for listening to the Front-end Developer podcast. Please subscribe to the podcast by going to the iTunes Store on your phone or desktop, then searching for Front-end, or via RSS by going to frontendcast.com, where you’ll also find show notes and a full transcript of each episode. We’ll see you next time.