 Our next speaker is Vignesh Nandakumar. So Vignesh has been working with the front end for over four years, and as of now, he's the only front end engineer at recruiter box. He's been using Backbone for over two years now, so that puts it at the timeline of when Jeremy Ashkenaz actually made it, yeah? When it just came out and MVC framework started exploding, and he's used it for a variety of use cases. He's made Sudoku puzzle apps, large business applications, and in the course of it, he's used Backbone really heavily, and this talk is about potential gotchas in making a Backbone app, a really quick talk about the things that can affect you when you make a Backbone app based on his personal experiences with doing so. Is it fine now? Like, Sunil said, I'm Vignesh, looking for recruiter box. Without much delay, let's get into it. So before going into the problems with Backbone, first let's have a quick look at why you should be using Backbone, as compared to other MVC frameworks available out there, like Angular, but there are so many frameworks available out there. Why should you be using Backbone? First of all, it's very robust. It's been around for more than two years, and it's pretty mature, and it's very, very small, the minified cup. And Compress version is 6KB. That's pretty much nothing. And you have a very active community out there. There are so many plugins and extensions. There are so many people talking about it, writing, blogging about it, and you have a very active community out there. And most important of all, there's no magic. It's nothing like you write this code and this happens. There's nothing like that. There's no magic. You have complete control. You have the power. But that means with great power comes great responsibility. That means you are responsible for your code, for whatever you write. You can't just go crazy. What does that mean? That means Backbone doesn't tell you best practices. They don't tell you anything about this how you should be doing this. This is how you should be doing this. It's ridiculously unopeningated. They give a very bare minimum framework and it's totally up to you. You can very easily screw it up and you will realize it at hindsight. So you should be very careful when you start writing your code. You should probably look at other people's mistakes and learn from it. Otherwise, learn it the hard way by making your own mistakes. And there's too much boilerplate code. Let's look at some examples. So any typical Backbone view that is tied to a Backbone model is gonna look very similar to this. Almost every view in your app which ties to a Backbone model is gonna look like this. You're gonna write the same lines of code in almost every view that you're gonna write. That's gonna be painful. That's waste of time. And similarly, let's look at a collection view. A view that is tied to a collection is gonna look very similar to this. It's like, these are very simple things that you're doing. You're just listening to a couple of events on the model and you're rendering, rendering it's nothing. You're just getting the template and you're passing the model JSON and injecting it into the DOM. It's very standard behavior which every view has to do. And you're gonna write the same code in every DOM view that you're gonna write. That's not good. So never do this. Ideally, Backbone should be handling this but unfortunately it doesn't. So you should always be writing your base view probably based on your application. Let's say you define an item view and a collection view which takes care of all this boilerplate code and you should always be extending from that. And the next problem, probably the most popular issue with Backbone is zombies. They are supposed to be dead but not really dead. So whenever you go to a forum or a Q&A site, say Stack Overflow and a Backbone topic, you'll find so many problems related to zombies. It goes something like this. Like whenever you hit the same route more than once, duplicative ones are getting triggered. Like one more time you visit the same page, one more instance of the same view gets created, something like that. Let's look at a demo. So let me show you a sample code. So you have a very simple model, a user model and it has some default properties and you have a user profile view. It's a very simple view. It just listens to the change event of the name property on the model and whenever it changes, it just goes in alert. And this is the most important part. The router which handles whenever you go to a URL, this is what that handles it. So what happens is whenever you hit account, it creates a new profile view and renders it and puts it into the DOM, very simple. But let's see what happens when we do this. Let's say this is your sample app. You go to account and I want to change my name. Let's say I put it to Wignesh, okay. Got updated and you got an alert saying name change to Wignesh. Forget the second line for now. We'll come back to it. But let's browse around. Let's go to some notifications and come back and I try to change it again. Let's say to Nanda now. It didn't really change here, but you got an alert saying name change to Nanda. You close it, you get another alert. This time it changed now. So I think it's kind of obvious now what's happening. So every time you hit the route, you are instantiating a new view, new profile, new instance of the profile view and injecting it into the DOM. But when you are moving away from the page, the view is not really killed. That view still exists. It is still listening to the events and doing whatever it was asked to do. So this time we had two and you go away and come back. This time you have three. Let's say something. So this second line is just to make sure that it is coming from different views. So this is a view ID. So now it is view three. Next time it's view four, next time it's view five. So now there are three views listening to the same event. So what you should be doing in this case is never instantiate new views and put them into the DOM, all that in the router. The router is not supposed to do this. The router, let's say you have a simple helper function like app.showView, which is supposed to take care of it. Whenever you are moving away from a page, that helper function takes care of killing the existing views and putting the new view into the place. Let's go back to the slides. Next problem is duplicate copies of data. Let's look at an example. So this is another simple model, an article model. So pass is like some special function in backbone model which is understood by backbone whenever there is a server response that is passed through pass which takes care of passing the JSON and building the JavaScript objects as required. For example, in this case, the article has an attribute called author which is supposed to be a user model and the pass function just takes care of it. But in this case, you're creating two articles and fetching, okay, I don't have the fetch code here but let's say you fetch both of them and both of them have the same author but what you end up is the pass function create duplicate copies of the same author. So if you compare the IDs, they will be the same but the models are not really the same. So when one instance of the model is updated, the other is not. They are two different copies of the same object. Yeah, this is the way backbone is designed. It's not really designed for nested models. So in this case, you should be using, actually, as I said, there are so many plugins and extensions available out there. You should be using some plugins like backbone nested which takes care of these things. So precisely, if you don't really plan well in the beginning, you'll end up in mess. So what is the solution? I mean, backbone is like this. You can't do something about it but there are already people who have solved many of those problems and they are available as plugins. There are so many plugins available out there. You can just go to this URL and pick the ones that you want and my favorite one is marionette and this takes away most of the problems with backbone. It'll just give a quick intro about it. Let's revisit the model view that we already wrote. That's it, there's no render function at all. You just give it the template ID and you just give a hash of the model events that it constantly done. That's it, there's no boilerplate at all. And it takes care of zombies. You don't have to manually kill the view every time you move away from the page. All that is not needed. Marionette already takes care of it. And this is another problem with backbone. Most of the times you wouldn't want to render the entire view whenever some part of the model changed. So the region takes care of it. Inside every view, you define regions and whenever that particular part of the model changes, the corresponding region in the view gets changed and you have something called layouts which takes care of the entire page layout, like where to put what view and stuff. And more than all this, like I said, backbone is ridiculously unopinionated. It doesn't tell you in which direction to go to how you should be structuring your app and stuff. And this gives you a very robust way of building apps. So like this guy, Justin Mayer said, you should never be building a large application. You should always be building small applications and compose them together into a large application. And this marionette kind of enforces it. You always build smaller modules and compose them together. That's pretty much about it. Awesome, we have plenty of time for questions. Questions, MVC questions? So I mean, you talked about the problems and all. Can you show the code for helper function and have you have been written? Sorry, which the show view function. The helper function for multiple views rendering. Sure, I can show you that. So this guy called Derrick Belly, one of the contributors to backbone, has been writing extensively about the problems with backbone and he is the guy who developed marionette as well. So he gives you an elegant solution for this. I'll just show you that, it's loading. So all that you're doing is you maintain a property called let's say current view, app.currentView and you have a reference to what view is currently being shown on the page. So whenever the show view is called with another function, you kill the current view and just instantiate the new view. That's pretty much about it. But there are some problems with sub views. Let's say the page view contains multiple sub views, they won't be killed by default. So you have to take care of things like whenever you kill a view, all its sub views are also getting killed. For that you need to modify, like extend the backbone views a little bit and keep track of all its children and whenever the parent view is killed, you have to kill its children as well. All right, the URL is in the presentation. You can look at it, I guess. Thanks. Yeah, so have you tried using other other JavaScript MVC platforms like Angular, Amber and all and how will you compare this with backbone given the problems that you are, I mean, you have faced in, you have faced in backbone and probably, I mean, we end up using another library inside backbone. So that takes away the advantage of it being very small and you can actually, the code is transparent. You can actually go through the backbone code in a few hours and then you can understand what is happening. But using more stuff on that, that takes away that advantage. So how will you compare that? So the main reason I prefer backbone is because as you said, it's very transparent. You can understand pretty much everything what's going on there. But compared to other frameworks like, let's say, Angular, there's too much magic going on. It's not at all plain JavaScript. You add some special properties, it gives you a specific kind of output. So that's not really cool, especially when you are writing a large applications, you want to be in control, right? So that's why you would choose backbone. But yeah, I mean, you have to abstract away all the boilerplate code and stuff. If you're not using something like Myronet, you will end up repeating so much code in your own application. So it's better to abstract away it in one place rather than writing the same code again and again in your application, right? So it's even Myronet is not that big. Compared to libraries like jQuery, which is so much bloated up, Myronet is nothing. It's not even half of it. Hi, so I just want to ask, since you have been using backbone for two years, so even I was thinking of using backbone for SPA kind of application. The problem I found is you need to, again, implement the server side of it, right? I mean, you have all the code in front end, every templating and all the client-side rendering. But then again, if the user enters the full URL, you have to implement that on server side also. Not sure. I mean, the hash bank kind of thing, right? I mean, so you need to... Hashtag. Hash banks. So you need to have that server support also for that, right? Yeah. Right, I got it. So there are two ways of handling this. The simplest way would be to always use hash URLs. Never use the... No, but the hash banks has disadvantage. Like it doesn't get indexed in with the Google, right? Yeah, I mean, in my opinion, backbone is meant for applications. I don't know why an application would need to be indexed by a search engine, right? I'm sorry? Yeah, I mean, his question is about indexing. How would you index the application with this hash URL? I think you can use a HTML5 push state, pop state to enable client-side change of the URL without using hash banks. And another thing is that you can look at couple of talks where they are talking about having something similar to backbone on the server side wherein you render the application state on the server side in case the user, you know, loads the application in middle of the thing. And GitHub, I think, already does that using PJAX. So they have something on the server side integrated with their ecosystem. And if you look at talk by Airbnb, yeah, they also try doing the same wherein they have that component on the server side. Yeah, yeah, it's still in development, but I think everybody wants to achieve that, yeah. We have time for one last question. Hello? Hello? Hello? Yeah, so here. So there are three things that are happening here. The view rendering and template fetching and model fetching. Do you have any ideas or thoughts on what should be the order and should it be coupled or decoupled, these three things? I didn't understand fetching a view. You always fetch models and collections. No, you fetch models, you also fetch template, right? You might fetch template. Oh, the order in which you include them in your application. Uh, okay. So, so isn't it that you fetch templates? You put, you create the view by merging the model and the template and then render it? Well, the templates you would, I would suggest you use pre-compiled templates. You don't fetch them on demand. That will really slow down your application. So you have pre-compiled templates, which is nothing but a JavaScript file. You include it just like any other JavaScript file before executing any of the stuff. It's the last round of applause for the occasion. Thank you.