Evolution of JavaScript MVC: AngularJS and Backbone | Front-End Developer Cast Episode 2

brian-genisio

On this episode I interview Brian Genisio, AngularJS and Backbone expert about the evolution of JavaScript MVC Frameworks and his experiences coming from building Rich Internet Applications (RIA) with Flex and Silverlight into the JavaScript single-page application world.  This is front-end developer cast episode 2.

To subscribe to the podcast, please use the links below:

Click Here to Subscribe via iTunes
Click Here to Subscribe via RSS (non-iTunes feed)

 Show Notes:

Resources

Twitter: @BrianGenisio
CodeMash presentation slides for Brian’s talk Angular Directives Demystified slides

Full Transcript

Craig McKeachie: [0:02] On this episode I interview Brian Genisio, AngularJS and Backbone expert about the evolution of JavaScript MVC Frameworks and his experience coming from building rich Internet applications with Flex and Silverlight into the JavaScript single page application world.

[0:16] This is Front-End Developer Cast Episode Two.

[0:22] [music]

[0:31] [background music]

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

[0:44] Hi everyone. Welcome to the second episode of the podcast. Me personally, I have been working hard on my book about single page applications. I took a trip to Orlando with my family recently and escaped the winter weather where I live in the mid-west United States.

[0:58] I have a lot of great interviews coming up including an interview with Tom Dale, who helped create Ember, so if you haven’t already please subscribe to the podcast in iTunes by searching for front-end developer and we are available on Stitcher, the Stitcher app or by RSS at funnyant.com were you’ll find show notes and a full transcript.

[1:17] One of the things I wanted to do with this show was get the voice of the people in the trenchers with real-world experience developing with this newer technologies, but not always people who are Internet famous, because of their open source contributions or blogging. Well, I think I hit the jackpot when I interviewed Brian Genisio, who works at Care Evolution.

[1:36] From our conversation, you’ll find out that he worked with BackboneJS and has evolved to AngularJS in his current work. One of the harder parts of AngularJS to  master is directives, and he really gives some great insights on this interview. Without further ado, let’s jump into the interview.

Craig: [1:52] I have with me Brian Genisio, is that correct [pronunciation]?

Brian Genisio: [1:55] Yeah, that’s right.

Craig: [1:57] Great. He’s joining me. His over 14 years of software development experience, everything from embedded systems to Silverlight  and to a bunch of experience recently with the different JavaScript MVC frameworks that we’re going to talk about. I’m happy to have him here today on the program to talk about these things.

Brian: [2:18] Thanks for having me. [inaudible 0:02:18]

Craig: [2:23] Usually I’ve been trying to get the real world experience out of people, but I thought it would be good to first have a conversation about of sort of what your mental model of the JavaScript MVC frameworks are and after using different ones…We were talking a little bit before we got on air here about that. How do you categorize the…You said first generation, second generations, and so.

Brian: [2:46] Sure, I guess when Backbone first came out; they were doing something new that we hadn’t seen before that was this synchronous model that they gave us where you could just new up a person model and just synch it with the server by saying save and get

[3:06] It was really quite amazing. It was ground-breaking at the time because all of a sudden you had a really good way to structure your code and you had kind of an MVC style in your code .

[3:18] Things were really nice, really exciting but I think even as that was happening we felt like it was stepping stone like. We knew something bigger was coming. I see like a Backbone and Knockout and things like that have been my first generation of JavaScript SPA style frameworks.

[3:40] Over time, people started building things bigger with them. We got Marionette and there was like hot towel and things like that…

Craig: [3:48] Marionette is a sort of framework that is an add-on, the plug-into Backbone that helps people, maybe mix-up more frameworks and less labor like?

Brian: [4:00] Yeah, kind of it. It kind of sits on top of Backbone and abstracts away a lot of the boiler plate that we were finding with the Backbone. You are occasionally creating CollectionViews and ItemViews over and over and over again.

[4:14] It got really old, and so you find yourself wanting to abstract that away. Marionette comes along and pretty much does that for you. It never really thought like it was a major shift until when we got things like Angular, I remember.

[4:31] They come along and I see those kind of being like a second generation of these frameworks. There are higher level abstractions that let us be more productive and write us code to do the same things that we did with the previous frameworks.

[4:46] The thing I see about the second generation frameworks that I don’t see in the first is I see a path to the future for them, for web components for instance I see how Backbone and Ember are going to be going towards that. I don’t see that…I am sorry; I think I said Backbone and Ember. I meant Angular and Ember have paths to the future with web components, but things like Backbone; they don’t really without putting a new layer on top of it to give you something like that.

Craig: [5:17] No, that’s a great point. That path to the future; I’ve heard that made a lot, so directives and Angular are equivalent of what may be code. They are informing web components in the future and what is called components in Ember, is what’s informing the future of, sort of the apple-to-apple comparison to web components.

Brian: [5:40] Yeah. Exactly. I don’t know, I find these frameworks to be something that…If I’m going to start a new project; I’m not going to go to Backbone anymore. Even though I’ve shipped about six projects with Backbone.

[5:55] I’m not going to probably start the new project with that anymore because I’m just finding these next level frameworks to be more productive. I come from the Silverlight and Flex world where other they ran in plug-ins, their development experience was highly productive.

[6:13] I still haven’t developed as productive in the web with any of these frameworks as I ever did was Silverlight and Flex, because they deliver feature quickly. We’re getting closing there, now with the things like Angular. I have got more experience of Angular than Ember, but I can produce my features almost as quickly as I did a couple of years ago when I was using those frameworks.

[6:40] Since, you can see where they’re going. In fact, the Ember kind of bureaus, the Rails philosophy because that community did that, where Angular feels like Flex and some of the developers on Angular came from the Flex community.

[6:56] You can kind of see where that goes, and you can see that these frameworks that did provide high level of productivity are highly influencing these frameworks.

Craig: [7:07] That’s a great overview for everybody. I think we’re going to drill into some of your more deeper experiences, but I thought that when we were talking before that, that was something that would be really useful to people, because that’s sort of my current mental picture of the landscape of SPA or JavaScript MVC or MV* good frameworks right now. I definitely concur…

Brian: [7:28] I’m interested to see what happens on the third generation.

Craig: [7:30] Right. [laughs] Exactly.

Brian: [7:32] Tool we made. Better tooling maybe, I don’t know.

Craig: [7:34] Yeah, interesting. Let’s talk about some of those apps you built with Backbone and…When you are working on it…For example, maybe describe one of the more complicated apps did and how the user experience was more from like how the screens lookand things like that.

Brian: [7:53] Sure. One particular app I worked on was a…It was a language learning tool using film. You would watch a movie that was…The native language was not English, for instance, and you wanted to learn Chinese.

 

Brian: [8:15] You would watch a Chinese movie and it would be completely augmented from the user experience on the website to be seen, to learn things about it.

[8:22] It would stop you and you would pause and it would tell you about what they just and said and the cultural context and things like that. There was an entire pedagogy to how they did those.

[8:40] The company was really good at language learning. We use Backbone as the framework to produce the screens and everything like that and all the user experience.

Craig: [8:53] That sounds…It’s a very interesting app that it surfaced, right?

Brian: [8:55] Yeah, it was fun.

Craig: [8:58] Did you start off with the app and say, “Hey, this is going to be a single page app,” or was it, you got into such a mess of jQuery code you felt like you need to do it. How did you involve into it?

Brian: [9:08] This particular company had all of their assets in Flex before this. They knew that Flex was not a direction they want to go in the future. With this new app, they said, “We want this to be web.”

[9:23] They hired my company — at the time at least — to do this and we had experience of Backbone at the time. Angular was too new to use and to feel comfortable on introducing. There was solid Backbone now on our team. It was just really a good feat for what we were doing. The routing fit well with what we’re doing and the data model from the server. It worked really well too.

Craig: [9:52] How much sort of unit testing and the end testing that you do if any with that Backbone application?

Brian: [9:58] We had a lot of testing in this application.

Craig: [10:01] Did you do like unit testing and how did you approach your testing in Backbone? How testable is Backbone?

Brian: [10:09] We did our best to kind of separate views from controllers. We were using Marionette in that project and so we tested our controller’s very unit test like.

[10:21] Then when it came to testing views, we kind of used some techniques to create the views in isolation and poke them with like click events and then go check using jQuery that the elements had changed to what we expected them to be.

[10:40] There were two different. There were plain old unit test. Something that would be more like a functional integration test, but not as high level as  a Selenium test for instance. It felt more like a unit test, but I’d call it more of an integration test because it is actually testing that it’s working against the DOM properly.

Craig: [10:59] Through layers. A lot of the unit tests, were they more on the views or on the model or a little bit of everything?

Brian: [11:05] Yeah, everything. If you had…The controllers and the models, they got the normal unit tests and then the views; they got more of the jQuery poking tests. We abstract some of that away so you can just say I want to create this element and attach this view and test that it’s doing the right thing.

Craig: [11:29] Do you have third party controls? It sounds like you had a video player of some sort. Did you have to use jQuery UI or calendar control or anything else, other libraries that you had to bring in to that project and work with?

Brian: [11:42] We were using Bootstrap as the basis. This particular company had a designer that created a beautiful design and so Bootstrap was the basis and then we tweaked it to look exactly like the designer had said. We’d bring in the libraries as we needed them.

[12:02] For the most part, there weren’t a ton of libraries that came in to this particular application, but when it came to the video player, that was a Backbone view that brought in a flash video player, because they had to do DRM.

[12:21] The goal was make it as encapsulated as possible so when the browser does support native DRM capabilities for the streaming that they wanted to do, we would just replace the flash video with HTML but everything outside of the video box was HTML .

Craig: [12:46] Right. I forgot to mention for the audience. We’re here at CodeMash. It’s hard to find a quite place so we got people walking in, walking out. If you hear doors close, no big deal. So that’s helpful. Talk about what was the back end of that application look like?

Brian: [13:04] That was interesting. We didn’t have back end yet. We were using a separated client architecture. One thing that’s kind of interesting about web development is very often when people write stateful clients, single page applications, whatever you want to call them.

[13:25] They’ll write it in the infrastructure that the server is. If they’re in Rails, they’ll put all their assets in the Rails asset pipeline and it’s well integrated, but we don’t do that with any other clients. We don’t do that with iOS apps. We have a separate application that talks to our rest service. We don’t do that with android apps, we have a separate application that talks to the rest service.

[13:45] We took the same approach with this. This is a web app that’s going to talk to a work flow framework. We were using Lineman which is kind of like Yeoman. Lineman has a little server and you mock out all the server calls. What’s nice about this is we were able to develop the entire front end before the server existed.

[14:12] That was a different team that hadn’t started yet. We got to define all the data we knew we needed to produce this UI. We had to say, “This is what we need it to look like.”

[14:22] Eventually when the server team got to it, they looked at it and said, “Well, we need it to be more like this and we just adapted it and it came together and worked well, but we worked completely against a fake server in isolation which was a lot of fun.

Craig: [14:36] Yeah, that’s the dream, right? You pulled it off it sounds like.

Brian: [14:39] Yeah, it worked perfectly.

Craig: [14:46] In terms of the screen, the times at needs to appear to  have dynamic or appeared to save data and so forth, how did Lineman support you in those efforts or was it pretty easy, not a lot of saving and so forth in that application?

Brian: [14:58] Lineman is just really our workflow wrapper around Grunt. Then there’s a server component in which you can just put in your stubs.

[15:10] You put a stub rest service in this framework and you return data and if you need to be able to save something and then get that back, well you just do it in memory. You don’t persist it to a database because you’re testing it against a mock and so it’s very easy to write a rest service that saves the memory.

[15:30] It’s very easy. That’s ultimately what it did. If we needed it to return specific data, we’d just go in there and say, “I want to test it with this data,” OK go. It works really well for that type of thing.

Craig: [15:45] Basically just a full mock rest service and anything you send to it, it’ll send back to you as the collection.

Brian: [15:53] Then when you build the Lineman app, what it does is just kind of treats it like we would have Silverlight or a Flex or Flash app. You get this folder with your assets, you get one JavaScript file, an images folder, like a wave’s folder, a handful of different things that may be there and you say, “Put this on your server, instantiate the class and attach it to your element and go.”

[16:23] In order to host the application, it’s really just two lines of code in your Rails app or whatever; however you’re actually hosting the app in the end. You just import the assets now as kind of a opaque package, like you would flash or…

Craig: [16:42] You know, I’ve got to be honest. I’m not entirely following that, although I really want to understand it. You hear this term, asset pipeline a lot. I know that one thing Lineman or the Grunt tasks do is combine all your JS and CSS and do any linting you need and stuff like that, but in terms of mocking the back end service and the sort of contract you’re making with that back end service, can you describe that one more time for me?

Brian: [17:15] Yeah, sure. Something like Lineman or Yeoman is going to treat your client side application as a separated client. It doesn’t care how it is being hosted. It can be hosted on Rails, it can be hosted on .net or java or whatever, it doesn’t care.

[17:33] You treat it more like you would a Flash app. When you did Flash, you would get an FLA file or something like that, and you would host it on your web server and then you would embed it on your HTML, right, and it would just work.

[17:49] Well you kind of do the same thing here with this workflow manager, in this case Lineman. With output, an app.js file and app.css file and you would deliver that to the website that was hosting your app.

[18:03] It would then just have like a body and the contract would be new up an app.

Craig: [18:13] The app being the API or in this case…

Brian: [18:15] Yeah, in this case, the application is just created. The main class for the app would just be app and you would hand it the body, and it would just attach the body and go, and take over, but it doesn’t know how it’s being hosted. It could be hosted in with tiny window; it could be hosted in bigger one. It doesn’t know, it doesn’t care, because it just an asset that is hooking in to the host application.

[18:42] You can also give it some configurations, so you could tell the app, “This is where you should go. This is the URL of the Rest service, you should talk to. In the end of the data service isn’t permitted in Rails and the website is hosted in Rails and the primary view does nothing but bring these assets that were created separately.

Craig: [19:11] Thanks for describing that. Let’s dig into…Maybe let’s talk a little more about Backbone and sort of you know a lot of people recommending to use Marionette with Backbone. Can you elaborate on some of the reasons? You’ve talked about the boiler plate code. Was there other things that Marionette brought for you that you felt like were extremely useful? The time…It’s been a while.

Brian: [19:39] Yeah, it’s a little while since I’ve used the Marionette, but they had some engine management stuff that was really nice.

[19:47] Some view clean up the codes essentially. One thing that Backbone suffers from is this concept of zombie views. In that the view gets generated and hooks a bunch of events, but if you don’t explicitly unhook those events, then you get event hanging out there which keeps the entire view alive.

[20:07] Over time, if you go back and forth between different views, you may now have 20 zombie views responding to these events and the app gets slower and slower and slower, and you don’t know why.

[20:18] You’d find yourself in this pattern where you have to then have like a disposed method in your view that will make sure to unhook your events, and then it would have to get called, so the parent would have to call it. Then the parent would have to call them. One of the things Marionette brought in was the concept of…There is a whole child view hierarchy in region management where those children live.

[20:42] Then, if you kill your parent and just kill the children, you didn’t have to think about it. All of the boiler plate hookup that it was easy to get wrong, is abstracted away from…That was one big thing that we found Marionette was useful for in the Backbone world.

[20:58] Another thing, there was the collection and item view pattern that you’re using Backbone a lot. You do the same thing over and over and over again. Maybe, everything is just a collection and an item view.

[21:11] Like entire apps are built up of collection and items, collections and items. You’d write the same thing over again and what you really wanted was a collection view that was abstracted that would be a collection view of item views, as opposed to the boiler plate, that you would write

[21:27] That’s something that Marionette brought to the table that made us more productive. We didn’t use other things that were in Marionette, but one of the next thing’s about Marionette was that it was that like a buffet of options. Just pick what you want and use what you want. You didn’t buy in to the entire idioms that Marionette brought to the table.

[21:47] We didn’t use their module system, for instance. We didn’t find the value in it for that case when we’re building, so we picked and choose. It was a nice framework to sit on top of Backbone.

Craig: [22:00] Great. Let’s shift gears and move it to the Angular project and talk a little bit more about your more recent experiences with Angular? What kind of app were you building in that case, in Angular?

Brian: [22:13] We were building a healthcare analytics application right now. The idea is that between health providers and payers and insurance companies and such, there is just a ton data out there. There are people that want to tell stories with that data.

[22:32] We want to know things like are there gaps and care for, around the patients? How much do certain types of patients cost? What’s the chances that you’re going to get a certain disease giving some previous history? As an industry, we’re just learning how to sift through this data that we have.

[22:57] This is an analytics tool that helps you sift through that and in the end, tell stories about the data you have. It’s a single page application. When using Angular, we use Grunt to manage our assets. We use Bower also to figure out which JavaScript files to bring in. .net on back end, signal our for real time communications. It’s your classic stateful application. Angular is a big component of that.

Craig: [23:35] You mentioned SingleR. There must be some real time sort updates going on there then.

Brian: [23:40] There is. When you’re aggregating large amounts of data, it takes a while to get that data, but this is a single page application, so we want to know how it’s doing. Updates get sent from the server as it’s working on the data and then you want to know when it’s ready.

[24:00] Instead of making a request and having that request, be open for up to maybe, five minutes, you instead send it off and the server will tell you when it knows something new, and you can update the UI based on it. That’s why we’re using [inaudible 0:24:15] for. We’re only using it for a downstream communication. We’re using REST for all other synchronous communication. A synchronous communication

Craig: [24:27] That is an interesting stack. You have got the SQL Server on the back end then probably because it’s…

Brian: [24:31] Yes, ultimately a SQL Server. There’s a entire business logic layer and I don’t spend too much time in the business logic. I spend more of my time front end user experience.

Craig: [24:44] When you first started using Angular, what were the parts of the framework that were sort of the lighter within? Like the one.

Brian: [24:50] I like the record a lot. For 15 years, I’ve wanted the web to have a component of my own. We still don’t have one. [laughs] Maybe, we’ll have one soon, but we still have to wait for the browsers to catch up.

[25:05] In the field of healthcare where I set off to support IE7, that’s going to be years down the road. I need something to probably fill the future. I need something to give me a component of my own, so I can develop real applications and stuffs.

Craig: [25:19] Give me an example of directives you write . Are they…How broad do they go in terms of functionality or like what…?

Brian: [25:24] Sure. We’re an analytics tool, so one particular that’s interesting is a grid. There’s a grid directive. You give it a URL for a data source and it will populate the grid with the data.

Craig: [25:38] Using a third party grid under the hood or are you building your own

Brian: [25:40] No. No, we’re using our own because ultimately it’s not that hard to do. It’s so often you want it to do exactly what you want it to do, and all these grid solutions do kind of what you want to do and then you have to hack them to make them work.

[25:57] It’s easier at these grids to just make them do what you want to do. It’s our own solution for doing grids.

Craig: [26:07] Like paging, sorting or sort of something?

Brian: [26:08] Exactly. Paging and sorting and…yeah. Exactly.

Craig: [26:14] You got a grid component that we…

Brian: [26:15] There’s a grid component that we can step on anywhere we want and any report, on any dashboard, whatever and you just give it the data source URL and it populates the grid and it goes. Another…

Craig: [26:26] You said that it’s on sort of isolate scope down there

Brian: [26:29] Yeah. That directive has an isolate scope and pretty much, lesser is a good reason not to, you always want to isolate your stuff, just like when you’re writing any type of functions, you don’t necessarily want to scope it. You don’t want the inside of functions to be able to modify the outside unless it’s explicit.

[26:52] That’s what ultimately when isolate scope does. Is just we’re going to encapsulate ourselves unless there is good reason not to. Most of these directives are isolate scopes on. Another example of a directive would there in a graph.

[27:06] In that case, we are encapsulating jq plot which is just a plotting library. We’re using jq plot because it supports IE7 and it gives us all the basic pass . Under the hood it’s not Angular, but in encapsulates. You can just say, here’s the grid, here’s the data source URL and here’s the type of…I’m sorry. Here’s the graph, here’s the data source URL and here’s the type of graph I want you to display, and then it goes and tweaks to jq plot and shows you the plot with your data.

Craig: [27:41] What are some of the …I know you’re doing a talk here. Could mention on this tomorrow, but where are some of the gotchas with directives. I’ve experienced some tying to wrap like jq UI account to control so forth and with the whole apply and digest thing. If you could talk a little bit this stuff and…

Brian: [27:56] Sure, I was going to say, I think it’s really important to understand the digest cycle if you’re going to be using any third party libraries to document with Angular. The digest cycle is the thing in Angular that updates the UI. In Angular, you declaratively define how your models are going to display in your view. You use data binding to do that and so by default its mustache style style data binding.

[28:29] What Angular does is that for every time you have a binding, it creates a watcher. What that watcher does is it runs the expressions inside that binding and it compares it to the lapsed time.

[28:40] If it’s changed, it updates that little bit that it cares about. If you had a little string interpolation inside of span, it’s going to update the text of that span because it’s noticed that it’s changed.

[28:54] The thing that’s interesting about that is, how does the watcher know to execute. You don’t want to cancel if you’re running. That will take up your processor. Angular knows that there’s really only about four specific places where something could change the UI.

[29:13] The first one is pretty obvious. Its user input. That’s why the…

Craig: [29:18] Key press events…

Brian: [29:19] Key press events, clicks, things like that. Angular hooks that for you and gives you ngClick, for instance. It will then run the digest cycle after it’s called you back. It calls your function and then it runs the digest cycle. You don’t have to think about it.

[29:36] Then the digest goes and it’s recursive and it goes to each one of watcher and says, “Have you changed? No, no, no. Yes, you have, OK. Update you a little bit and move on.”

[29:46] That’s the first one. Is user input. Next one is asynchronous network traffic, XHR requests. Angular gives you a service called $HTTP in which it knows that after the data has called you back, it’s going to run the digest cycle again.

[30:06] The third one is timers. You don’t call set timeout in Angular. You use the time timeout service which knows that after it’s called you back in and runs the digest cycle. Then the fourth thing that could change the UI is anything else that isn’t about it. Anything else that you’ve written that you know is going to change the UI.

[30:31] This would be something like jQuery grid may change, right. May change your status, and may change something in your scope. That’s when you want to call apply. When something from the outside is changed…

Craig: [30:45] As far as re-binding UI basically with those…

Brian: [30:49] Yeah, exactly. Apply is a higher level function over digest. There’s two things that are important on the scope regarding this — apply and digest.

[31:00] Digest does the digest cycle. It will go recursively from its scope all the way down. Any watchers that may exist on the scope, it’s going to ask. Apply…

Craig: [31:11] I’m following almost all this because I’ve done enough Angular work, but the watchers, any watchers, so there is multiple watchers going on here?

Brian: [31:20] Yeah, for every binding there is a watcher.

Craig: [31:22] OK.

Brian: [31:23] You could also hook a watcher yourself. You can watch something on the scope and run the function. Everything is really just a function call back. Inside of Angular, these bindings are a function call back to go update the property or the node text that is there.

Craig: [31:42] This is somebody clicks the button, we shall repeat this package.

Brian: [31:44] Sure.

Craig: [31:45] Somebody clicks the button, Angular automatically will let you run your code in the ngClick event, and it will call apply for you after that which essentially goes through all the watchers which are an object an associated with each individual mustache or handlebars syntax on the page.

Brian: [32:11] Exactly.

Craig: [32:13] It will say, how does it know whether the data changed or does dirty checking, right?

Brian: [32:20] Exactly. Every watcher knows with the last value was. There’s a digest that happens in the beginning.

Craig: [32:27] Did it change then go ahead and update by self.

Brian: [32:29] Yes, it is. Then, in the case of string interpolation, that watcher is in charge of updating that span or that attribute or whatever it might be, that it’s watching and it just knows that it’s going to do that.

[32:48] Getting back the re-question of what is apply. Apply will run your function with the exception handling if your code or expression accepts, it doesn’t actually throw out a JavaScript failure. It catches them internally.

[33:03] Then assuming it succeeds, it then goes to the root scope and calls digest, because if it’s going to call you back, you may go a service that goes and updates somebody else’s scope somewhere else. You need to go to the root and just traverse the entire tree and ask everybody, “Have you changed?”

Craig: [33:25] In what scenario?

Brian: [33:27] In apply. That will apply to us. Apply will always go to the root…

Craig: [33:32] …And then go back down the tree.

Brian: [33:33] …And traverse the entire tree.

Craig: [33:35] Interesting.

Brian: [33:35] That’s the apply/digest cycles. Apply’s job says go to the root and digest. You can always say scope digest. That will not go to the root. That will take your insisting scope and everything below it, but apply will apply to the entire tree. The entire thing in that root scope.

Craig: [33:59] When you wrap existing sort of UI widget with an Angular directive, that’s when you’ll, then you need to call apply, because it doesn’t know…Let’s talk about a real world case where the widget change something, it basically change data and model or in the view which is it?

Brian: [34:17] Yeah, there would be something and probably a new model. Your controller would have a function that would get an event from third party control. That controller would have a callback that would call a service internally or would set a model property inside of the Angular world.

[34:36] That data has changed, but the UI doesn’t know to change. That’s when you have to call apply. Because the other first three scenarios — the user input, the network and the timeout — Angular knows to call apply for it, but Angular doesn’t know that you’re using jq plot for instance, but you do.

[34:59] When you’re integrating with third party libraries and making Angular wrappers for it, that’s important to know. I think understand the digest cycle becomes very important when you’re wondering why you changed the scope and nothing changed.

[35:16] Something I say when people ask, “When should I use apply?” My answer is, “Make sure you’re using apply only when you know why you’re using it.”

Craig: [35:23] Right [laughs]

[35:24] Because people use apply…Something doesn’t work and then they’ll just go use apply. “I’ll just try apply,” and then it throws a cryptic error that says, “Already in digest cycle.” They don’t know what that means, but it’s because they were inside of Angular already and you can’t apply what you are already applying, because that would cause infinite loops

Craig: [35:42] Like in a jq plot directive, do you have like a drop down or something that changes the axes on the chart? Can you give me a real concrete example of what, towards that a bad example because there’s no and nothing changes

Brian: [35:54] No, something does change. We have a loading indicator. This directive, we want a good user experience while we’re waiting for the data to be fetched. This is a case where a directive actually goes to a service, because we wanted to encapsulate. We wanted to say, “Here’s a graph, here’s the data source URL, draw me the graph.” Because of that, we want a loading indicator for a while, while we’re waiting to get the data from the server.

[36:24] Then, it takes some time for the plot to generate and the plot will tell us when it’s done. I want to start loading to files. I have to apply that. Now, I can be smart enough and say, “Well, I know that this is the only thing I’ve changed. I could actually call scope digest. That’s even more. You got to know what you’re doing, but…

Craig: [36:47] It’s safer. I’ve heard you call apply because it’s got the try catching and very simply.

Brian: [36:50] Exactly. Apply is the idiom. Apply is the area, but for performance reasons, you want to call digest; you could because ultimately it applies just calling digest.

Craig: [37:00] The page logs, you load, you said loading to true or something like that and you want to change it false, what event happens to change it? It’s the XHR request coming back right to the…

Brian: [37:11] Yeah. If I remember correctly, actually it’s the grid; give me an event to that. I’m sorry, the graph gives me an event that it’s completed rendering.

Craig: [37:22] You wire that event, you listen to that event.

Brian: [37:24] I listened to that event and in the handler of that event, I call apply, loading is equal to truth. Then that

Craig: [37:32] You said loading equal to truth first and then call apply or…

Brian: [37:35] No. You can do either.

Craig: [37:37] Oh, yeah. I have read this. I know what you’re talking about now. Go ahead.

Brian: [37:40] You can do either. You can say loading is true, and then say scope apply, but scope apply can take an expression or a function. If you give it that, it will do to a try catching internally and do the right thing inside of Angular.

[37:56] What you do is you really just say apply anonymous function, loading is equal to true and then any exceptions that make it call gap even improperly handle by Angular as opposed to showing a little error indicator in your browser.

Craig: [38:16] I can’t wait for your talk tomorrow, now. That was a very good description. Very useful. I think one of tougher areas of Angular is people to master directives. I can tell you’ve worked in the hardest parts so the error parts are easy now perhaps before you.

[38:29] [laughter]

Brian: [38:31] There’s always hard parts. There’s always easy parts, too.

Craig: [38:35] You really like that model. Sorry, we got pretty deep in there, but I think that was to the listeners. See, if there is anything else we should talk about as we wrap up, I think we’ve covered a lot of the good stuffs. Maybe you can talk a little bit about HTTP and resource class and your experiences with that and talk to services . How’s that going?

Brian: [38:59] As far as I am concerned, the resource service in Angular mirrors the data model niceties that we got in Backbone. It’s pretty much the same concern.

[39:13] You create yourself a class like a person, and you say, “person.gap ID,” and they are doing a synchronous gap. That object will eventually have its property is filled in. If you say, “Save,” it will automatically save to the server. Same thing as Backbone does.

[39:31] There are a lot of people that feel like it’s not enough. They come up…There is like Rest Angular, for example. I have never run into a situation where research hasn’t been enough, but for those more advance situations that people have come up with other plug-in or other modules that would replace resource.

Craig: [39:56] To give a little Backbone comparison, a lot of Backbone’s models power is in sort of inventing around watching property changes and so forth and for that you’ve sort of got the separate watch thing in Angular.

Brian: [40:09] Yeah, exactly. The controller in Angular would have a service that would go or would go to resource and would fetch the data and then it would put the model in the scope.

[40:23] The view would bind to something on that model and then, when the HTTP request is done — because internally inside of resources is just using the $HTTP service — it updates the property, calls apply and now that UI that has bound to that model, just automatically . You’re no longer…Like in Backbone, you would listen to the change events on the model and then you would re-render.

[40:55] Here in Angular, it’s kind of listening to all possible changes and then only we rendering the bit that changes. From a UI re-rendering perspective, it’s more efficient. From an eventing system, it may not be.

Craig: [41:13] A lot more to listen to, a lot more events.

Brian: [41:15] Yeah, but a lot more…

Craig: [41:16] Watchers.

Brian: [41:17] …Watchers. A lot more watching. It’s less than this…It’s not quite listening because you’re not listening to a band necessarily. You are watching in the value of expression execution.

Craig: [41:30] Interesting. Yeah, so sort of the inverse of event.

Brian: [41:34] In the next version of JavaScript, we are going to get some things that will make the watcher a bit actually much more efficient. We are going to get observable in or likely to get observable in ES6 . When that happens, Angular will probably say, “Well, if you have ES6, we are going to use the observable.” Now, the runtime is telling you when something changes, as opposed to having to go watch everything.

[42:02] That’s going to make Angular flop, at least in theory. What’s likely happen with Angular is that it will still have the digest cycle for the browsers that don’t support the observable JavaScript, but it’s frameworks like Angular we need to observe the changes. We need to be able to observe changes that are objects on JavaScript.

Craig: [42:25] Right, and just to sort of fill in the little back story there. In backbone whenever you access a property, it’s truly sort of using the classic observable pattern, but the cost you take as developer is you have to call getting set all the time, so that it knows when you’re getting and setting thing. That’s one of the nice things, but challenges with Angular, but conscious design choices was to allows you to use plain old  JavaScript objects.

[42:54] When you set a property, just sort of do a lot of dirty checking which is what we described with all the watchers. In the future could just turn out to able to have a clean syntax of a plain old JavaScript object JavaScript object for accessing q property, but have a much more efficient in modern browsers, have much more efficient way of implementing that in the framework.

Brian: [43:19] Actually in native implementing as opposed to, because one of the things about the Backbone models is they are not plain old JavaScript objects. In fact, they are property bags, because that’s really the most efficient way to do a generic observable object. Is in JavaScript. Is to have property bags essentially then take all this property change over certain a event.

[43:44] With JavaScript observable there’ll be completely native and so we’ll be much more efficient. At least in theory. We’ll see how it gets implemented, but I have faith in most of the browsers.

Craig: [43:58] Right, exactly. Well, I think I have asked enough questions for today or maybe I should talk about what’s your tool of choice? What do you develop in day-to-day, nowadays?

Brian: [44:10] Well, day-to-day I’m using Visual Studio right now, because this Angular app is directly connected to the server framework, but it doesn’t need to be. If I had my drothers, I would be separated like I was in the Backbone. For example I was talking about, because I like that. I would probably just use Sublime and Yeoman or Lineman to do the build process.

[44:41] We’re using Visual Studio with some integrated Grunt tasks so we’re not using .nets bundler system. It’s just that not powerful enough for us. We are using Grunt.

Craig: [44:53] Seems like people are moving that way now

Brian: [44:58] We’ll see what happens with Gulp. I don’t know if you’ve seen or heard about Gulp, but…

Craig: [45:01] I’ve heard about it.

Brian: [45:02] It’s getting a lot of buzz. Some people are saying that I made very quickly eclipse Grunt, I don’t know, we’ll see. I’m interested to see where it goes.

Craig: [45:12] I just love the names. These names keep coming, right?

Brian: [45:15] Yeah.

Craig: [45:17] All right. We’ll put plenty of links in the show notes. I think we talked about a lot of great things. I think there’s an article if you’re interested that describes some of the digest and apply stuff that I found. I’ll throw that in the show notes. If you know any good resources, we could throw those and as well, definitely linked to the alignment. Sounds like you talked about that, had a good experience with that.

Brian: [45:41] That’s the guy named Justin Searls He’s here at this conference.

Craig: [45:46] Well, hopefully I’ll get lucky enough to talk to him. Thanks again for coming on the show. Brian, I really appreciate it and we’ll keep in touch.

Brian: [45:56] All right. Thank you.

Man 1: [45:56] Thanks for listening to the Front-End Developer Podcast. Please subscribe the podcast by going to the iTunes store on your phone or desktop then searching for “Front-End” or via RSS by going to funnyant.com. You will also find show notes in a full transcript of each episode.

[46:12] We’ll see you next time.

 

Tags: , ,

Trackbacks/Pingbacks

  1. Dew Drop – March 17, 2014 (#1744) | Morning Dew - March 17, 2014

    […] Evolution of JavaScript MVC: AngularJS and Backbone | Front-End Developer Cast Episode 2 (Craig McKeachie) […]

Leave a Reply