 Sorry? I'm timing. Okay. Okay, sure sure. How much time do I get? 30 minutes. Okay. Perfect. Yeah, no, that's fine. I think that's perfect, yeah. Yeah, it should be fine. That's fine, correct? That's fine. So, hi. My name is Pratik. I work with Avinash on support B and we are basically a single-page application or customer support software, very much like Gmail. So, the background is if you're building, let's say a Gmail where there's a listing and then pages change. And so, most people think of single-page apps as apps which are just like one page, right? And everything happens. But then, I like to call it multi-screen single-page apps, just to be more clear. The screens are still changing. So, you still have a complete change in the screen, but as such, there's no page reload. So, that's basically what I'm going to talk about, how to build applications like that. So, for example, when you open a new email in Gmail, right, the URL changes, the screen changes, you can bookmark the URL, you can open it elsewhere. If you go into, let's say, all tickets, sorry, all email screen or if you're going to start, there's a different URL for that. So, basically, how do you structure applications like that? So, just to get a quick sort of idea of the audience, how many of you guys have built a single-page app? Okay, cool. So, I'm assuming backbone or something. How many of you guys have built a single-page multi-screen app where the screens actually change, not just things being dropped around? Okay, so fewer. So, but most of you can basically appreciate the context, right? So, how do you do that? And so, I've written, you know, blog posts on backbone and I've met a lot of people and I think the biggest problem is, you know, it's not about using backbone as such, I think it's about how to think the single-page way. Like, right, how do I structure my application? How do I basically manage that sort of like complexity, right? Because most of us come from server-side background role, in JS, we've just done small JS stuff. So, we don't know how to, for example, desktop applications very well understood how to build, but not single-page apps. So, we'll just talk about that quickly. So, and these are just four or five small lessons that we've learned and told me this is not an authoritative talk just to get some ideas going. So, one thing we figured out was that URL should be the entry point for every scheme and what I mean by that is, so if you guys have used like the backbone router, for example, so, you can you can call the router and you can change the URL and do an action anytime you want in your application. So, you could click a link and you could ask something on the screen to be changed and then you can change the URL of the history, so it gets bookmarked, right? But what you've seen is the other way is much better which is whenever you want to change the screen it's always better to change the URL and then let the routing kick in and do its thing and the benefits of that is so, for example, in support we've set up these routes right when the application starts. So, we say let's set up a new router, let's set up an open ticket route which is just slash ticket ID, let's set up one which is label, label name and let's set up a default listing some of the routes, right? And the benefit of that is now let's say to change the screen you just have to change the URL you don't have to know to open a ticket you don't need to know where which function has to be called so, for a simple application where you are just you know, you just have a couple of screens a few click buttons a few links, you can do it either way doesn't matter. But here, for example, now if I through my search, some logic, I want to auto complete and hit enter all I need to do is now know what is the ticket URL just change the URL and wherever the routing is already configured will kick in. But if you do it the other way around, you always have to manage the complexity yourself. So for example, to open a ticket I can just, you know, this navigate is essentially nothing but just a wrapper to change the URL and you can pass it some parameter and so you just like put the slash model is to slash three or slash four or whatever and the routes that we set up before will kick in. So I think always for a bigger application, it's better to sort of center it around URLs so the navigating is still using the history API to change the URL yeah, it's using the history API to change the URL but it's not triggering yeah, it's not like calling the function and so in backboard you can do it two ways you can execute the logic and then you can call the history thing just for preserving the back button thing. This is the other way around actually the URL change and then the router kicks in so that's the point the other thing that we realize is that when you're building such applications you can let's say you have a main div where most of the stuff shows you can just call a show on that you can just say in jQuery you can just say okay taller main div .hkml and you can put whatever you've rendered over there it's just like way better and this might sound obvious probably it took me some time to appreciate this but it's really amazing to create a current view class which actually does the screen changes which is the one which is managing the actual screen changing and things like that and I'll show you why it works better than I've made so for example here in this current view class it exposes a method called set which will basically have its own view and it will render the top-level element .el and show it in the main area of the application and what it will do is it will actually keep a track of all the screens that have been rendered so far it will keep track of URLs so for example as I said we change the URL first and then the other things kick in so whenever it gets a call to change the screen it knows that by now the URL has already changed so it keeps a hash of screen and URL and there's a few other things like sets of keyboard shortcuts or whatever and every time it sets the current screen as the current one it will just tell the other screens that ok now you are not being displayed so for example you could do things like reduce the polling time if you're polling or if you're doing something expensive on those screens or whatever if you want to garbage collect those screens you can do that so it makes for a really clean pattern that way and there are other benefits we will talk about so as I said the current view already knows about all your screens and URLs so for example now let's say I want to say I'm on some screen I want to say just give me the last listing back so now I already have a hash of all the screens I can just go through that and figure out ok which one was the listing type screen and show me that one and again I just change the URL I don't everywhere you change the URL I don't actually render directly so these patterns time very well so you could do things like that you could if you get a request to render a screen you can actually check is it already pre-rendered then don't call render on it because render is more expensive in operation just show it just show the element so you could do things like that so the current view class really helps actually and the other thing we realize is you should use a lot of event binding you should use a lot of event binding I think 2 years into the backbone ecosystem I think it is kind of a common advice that a lot of people already understand but so I have no idea actually how other people do backbone because I have not seen that much backbone code I have not met that many backbone developers building big apps so I am just assuming that these things are important people don't know about that so some of the event binding things are very obvious I think by now people understand it like for example if you have a view and instead you initialize some models or some collections you obviously have to bind to those to know when they are fetched or when the models change so those things are very obvious which I think a lot of people should be doing by now so for example like if you are in the ticket view we say okay if the ticket model is archived if it is spammed, if it is trashed whatever then do these kind of things so this kind of event binding I think right now is like very obvious but what I am talking about is the fact that you can bind to events which are not very obvious so for example again going back to the current view class so what the current view does is whenever you ask it to render and show a screen it will actually bind to certain events on that screen so it will say okay bind to the archive if the event dispatches and archives this for example in Gmail when you click archive it takes I think in Gmail also it takes you back to the previous listing you know if you hit if you are in a ticket and you hit spam it will take you back to the listing so the current view class is actually just bind to these events and now this actual view class doesn't have to worry about telling the current view class that you know what I have been on explicitly having to call a refresh or a page change or something like that so use event bindings between you know when it's not very obvious and you want certain interactions to happen between different screens and basically drawing from that you should also dispatch more custom events so for example like we dispatch like the archived event now we don't worry about who's going to use it the current view class could use it or you know the somebody else could use it so dispatch a lot of current you know custom events we have custom events like fetched and before fetch or before save so you can like extend backbone or whichever framework you are using with more custom events it just gives you more flexibility in terms of doing stuff one thing also you know which we realized is that it's really helpful to use an identity map sort of thing and what I mean by that is basically if you initialize in two places in your single page app you know a model with an ID let's say 10 it should actually give you back the same object and why that is important is let's say you have an application like this where you archive the ticket or you change something on it and you go back to the previous listing now you want that to be updated instantaneously and if you don't use an identity map you'll have a different object even though it's the same ID and unless you're using push to immediately you know change it or whatever it's going to be hard to keep those things in sync so we really like using an identity map it has worked out very well for us you could just quickly throw one together unfortunately Bagmo is not that modular so you have to hack into the guts of it a little bit so and you can test cases for it so for example what it does is if you're asked to create a new model it just checks if there's an old one existing and if there's one existing it just updates the attributes with the new one and just returns you that so very simple there's nothing fancy there so when you want to create a new model you check the attributes if the ID is the map and it's then transparently so that's why I hack into Bagmo not model so it's then transparently to you as a driver I mean you're writing the application don't have to worry about whether there's another instance or not it just returns you the and and so if now the same instance as I said being used all the screens will stay updated but this obviously depends if you're using event binding right so it obviously breaks down if you're not binding so if you're not binding events then the other screens wouldn't even know that this object has changed doesn't matter where it's changed so and this all of this stuff is obviously a lot of complexity I mean so you can write great code or whatever but I think you absolutely have to test write that code I think the ecosystem is really good right now for test driving code so for example we use SinonJS so let's say we want to initialize a group's collection or something it's really simple now so you can say Sinon.mark give me a mark or SP collections give me so this goes into Bagmo but you can do it whatever and in JavaScript unfortunately you have to use a lot of marks because you want to avoid server calls and so for example in Ruby we don't use that many marks we make actual database calls and we actually use factories and we set up and it's still reasonably fast but here it's very difficult to do that because all the calls are being made with a server so but if you see it's still a lot of setup you have to set up a mark you have to set up an expectation you have to verify the mark and you miss out the line where you tear down the mark you know it is still a lot of work but what you could do is so you know we have written some helpers to basically test these so what we've written is like a test with marks maybe just say this class expects this returns this and then on that I expect this and all this should happen when I do this so this takes kind of all the setup verification tear down for you and so this makes it extremely simple how do you make a mark of this STTP server request? yeah so you can use SinonJS which also gives you so it will give you fake XHR request it will give you and we have written something called Backbone Factory which basically helps you so you just give it some attributes you give it if you guys have used Factory Girl or one of the factories so it will give every time you want a new ticket object it will give you with an incremented ID you can even say if the name can be name plus a sequence number so name 1, name 2, person 1, person 2 so it will keep doing all that for you you can very easily test your Backbone code actually so just write these helpers we have actually open sourced all of these helpers the factory everything I will send give links out if you guys are interested and just remember that all the best practices obviously like apply here single responsibility high cohesion in the class create whatever you know and just read the book the clean code this book basically covers 90% of all practices and there's nothing different between the best practices for Ruby or JavaScript that much I mean yeah there's different between event binding and how you pass on things you know using closure or whatever some of that stuff but that's it right and and so yeah these are the resources use Synonges this is the factory factory that I talked about if you are testing Backbone code it's really really useful these are the Synonges helpers which we have written and these utilize the factory as well so for example you could say if I make a call to the URL you know slash tickets give me a response which has three instances of the factory ticket so you can like very easily basically test your code using these helpers and so you guys are feel free to go and check those out and how much time did I take yeah you have 10 minutes left okay so I will just open it for Q&A to give you guys a question about that so I just wanted to give you guys some ideas on how to structure I mean obviously we cannot do a very big like from like scratch to an application so this is the last question one question I have is what has been your experience with Backbone and like today there are many more choices and so many choices so if today you were to write an application would you still use Backbone or you would use something else so to be honest no so I am not like big programming language or frameworks geek really I don't go around exploring that much so I don't even know actually yeah there is Ember you know which does and then there is like you know these things which people have written for Backbone which does Ember kind of thing I think ultimately what really matters is the architecture of the application that how do you and then writing your own sort of custom stuff for your specific domain that can help you achieve these goals faster and more making sure you are the test infrastructure in place so given all the infrastructure you have placed in Backbone I think I would still go back and pick up Backbone because we already have that infrastructure and one more question I have is I saw your blog on jQuery and you know Backbone jQuery mobile right so what has been your experience in the performance with this combination on different mobile devices like scroll so actually the experience has been pretty interesting which is so I spent about a week or 10 days trying to get this iScroller working and it didn't okay and I just said okay you know screw it I'll just like launch it and then I tried on like my mom's cheap 12,000 rupees android phone and it just scrolls beautifully well because android has already done that so I think it's only a matter of time before I think iPhone it's funny but I think iPhone has a lot of catching up to do sometimes an iPhone but I think so it's I think android is getting a lot of that stuff right anyway so you don't have to use iScroller the performance is really amazing and iPhone the performance actually shit here at least my iPhone 4 it was shit here but for us it was clearly like the first launch and for that we were pretty happy with what we came up with again what we wanted to really make sure was that it doesn't sort of so it doesn't sort of hinder what we want to make sure is like we can still reuse the code a lot and as we push out new features it's very easy for us to turn things on and off for the mobile till we figure out a mobile layout or whatever so again we wrote a lot of custom helpers so if I could show you guys some code maybe quickly so so for example we've written this you know sort of looking little helper so we've just written this very simple helper which says I don't know how to zoom in here actually so we wrote this little helper here which says response to which is like you know obviously inspired by rails so you can set certain very much on a server side or JavaScript side to say is this a mobile device, is this a tablet device whatever it is and then you can say so for example now we can very quickly do stuff like okay just do this stuff for mobile for desktop do these other things like you know making the top bar sticky rendering the view, who's viewing less so we can quickly turn features on and off so I think so for us that was more important because as you're moving really fast with the product we don't want to like maintain two code bases and we also don't want like sort of every time have to worry about okay how will this render on the mobile so we only turn on things once we've launched on the desktop they're working and then you know we port it back to mobile so as I said I mean if you're going the single page apps way it's a great idea to invest in your custom infrastructure a little bit open source parts of it if it is generic but definitely I think more than any particular framework I think your custom infrastructure will help you a lot I'm here to back home words of what you know how do you deal with undoing in action so there are certain obviously there are a lot of paradigms for it one I mean you can use the command paradigm where you basically I think pivotal tracker uses that and what they do is everything is sent out as in a command queue and then that command queue can be executed elsewhere or you can do undo stuff here so we don't really have undo right now actually I mean you have to be absolutely sure what you're doing if I'm just kidding but yeah so we don't have undo right now but I would assume that it's just basically the same sort of things you just put actions in a queue and then execute the queue and be able to like roll back the queue you know based on and I would just tell you guys about how it would deal with the object idea that you were keeping in sync how would it deal with I mean you're undoing one screen but that's the idea that if you create an instance it is all the same even if in different screens you're initializing that's the whole idea of using the identity map versus having to actually check is that if you say new model ID5 to you it doesn't matter if there is already one it will return you the same instance back and so everything should go in sync actually yeah I think I wrote a blog post and I had a lot of debates with even Jeremy on and he's like oh you never need you would never need an identity map a lot of people there I think the problem is if you're doing just a single page of one screen you probably don't but if you're doing multiple screens I have not come across a better solution actually but I would be happy to learn of better solutions for sure there are any other questions I saw you using a platform in mobile also so do you prefer using a platform in mobile or mobile yeah sure as I said we wanted to reuse most of our code base and we didn't want to write from scratch so we wanted to achieve at least 90% code reuse and so what we had to do and I wrote a blog post what did we go to their blog and check it out the only thing we had to struggle with for about a week was turning features on and off from jQuery for example we used bootstrap for styling and bootstrap does styling and functionality but jQuery mobile is unique in a way that it also does styling and it also does the functionality bits but if you are persistent enough you can find enough options to turn also for example you could turn off the router you could turn off the styling on the buttons and so far us right now actually does work out pretty well so now we still have that single page less but we could so we could get the benefits of jQuery mobile like our current view class for example the set method change to delegate it to jQuery is change page so we still use the best bits of jQuery mobile which is and we use their custom events like page init to basically refresh the scroller for example after the page is init but we could also still keep using our single page infrastructure which is already test driven and because we had this testing setup we could quickly write tests specifically for mobile as well so on mobile if it's delegating to page change versus actually calling so it does work out pretty well for us now actually now that we know what how to turn things on and off and those we have blocked about so you can go I mean obviously we found it on the internet I didn't claim to invent those things but it was just hard to find because they were all scattered all over the place actually any other question so just quick one more quick announcement I mean so I really love watching demos like frontend and similar demos list piece script really amazing stuff so we run a demo club which we sort of modeled after the silicon valley computer club that used to exist in the 1970s where people would just show up and show what they built so the idea is to encourage people to show stuff that they are hacking on working on incomplete small stuff as little as I built a sorting algorithm to I found this need way to do managing your CSS or whatever the idea is not to show because there are a lot of startup events but so you want to do demo clubs so the URL for that is so we'll do the meet up on 28th which is a Thursday but just go to about me you know just take the URL if you can okay it's demo club BLR about me about me slash demo club BLR and so please show up and show these hacks to other people there as well and encourage your friends to show their hacks I think let's get out of people's head that they have to have a startup to show people something so we are against that we are fighting that trend basically so help us fight that trend so we do a quick break and then we finish with the sashtov okay great how do you want to do an msg again what are you going to do oh yes yes sorry sorry sorry sorry sorry sorry sorry sorry sorry sorry