 three years, and nowadays I am working for Aberdeen Cloud, a virtual clustering platform for BigDrupal. Ethan is technical director at EcoDicto, and he will talk after me. My part is about 25 minutes, so thank you. So, why am I here talking to you about JavaScript and Backbone.js? Because Backbone.js fits into Drupal feature. The big picture is this. In the back end, Drupal 8 will support natively restful calls, and the front end Backbone.js will be consuming that JSON data and rendering the HTML. This is the big picture I want that you have during the session. But before we start to get into details, let's start with the demo, yeah. Why to wait? I was thinking to demo first a simple to-do app, but why not to show a full complex web application that you can see something real. I'm going to demo you the Aberdeen Cloud web interface. We made the decision of building the interface with Backbone.js, and we don't regret it. It enforces you to follow healthy design patterns, and our code has become much easier to maintain. As you see now, all these interactions, the back end is not rendering any HTML. Everything is happening in the front end. Backbone is taking care of the user interface. That means that the interface is much more snappier. This translates into a better user experience for the end user. Forget about refreshing the whole page. That's the point. If Backbone has worked for us, I'm sure that it can help you, too, for your next web application. Now let's see how we have arrived to this point after a decade of web evolution. 2000, who remembers how it was to build websites in 2000? Some HTML, some CSS. If JavaScript was used in that time, probably it was for some alerts and pop-ups. It's normal that JavaScript got bad reputation from those days. But let's jump to 2006. By that time, Google released Gmail, and I think most of the people start to look at JavaScript with different eyes. It was like, why? You can do that with JavaScript? But still, most of the people that is not Google was using JavaScript for small stuff, maybe Ajax. In 2006, also, jQuery 1.0 was released, but that's 2006. Now we are in 2012. Today, many developers are using JavaScript for important tasks. It's not anymore about a couple of JavaScript snippets. The front end is sharing the heavy lifting also with the back end. Today, it's normal to build websites with those sense of JavaScript files, third-party libraries. It's becoming normal to have teams of people only dedicated for front end. Do you recognize this slogan? Who is the sloganist? Yes, Java slogan. As you know, Java has nothing to do with JavaScript. They say Java is to JavaScript as ham is to hamster. But although they are totally different, in a way, JavaScript is becoming the run everywhere language that Java wanted to be. If you think about it, there is JavaScript interpreters everywhere. It's the only language that is shared across all main browsers. It's in almost every operative system. It's in your mobile phone. It's in your tablet. It's even soon in your TV. So it's huge benefits to programming JavaScript, your web interfaces. So JavaScript is here to stay for some time. Who hear programs in JavaScript? Okay, more than half of the people who likes to program in JavaScript? Okay, a little less. Who hates JavaScript? You are in the wrong system. This is a screenshot that shows the top languages hosted on GitHub, the number one JavaScript. But JavaScript is growing in other ways too. This graph represents the last two years of evolution among the top 1 million sites of Alexa ranking. As you can see, the average JavaScript size has increased a lot. So this is further proof that we are not using anymore for JavaScript for small things where JavaScript is not anymore. It's no longer child's play. We keep adding more and more logic to our front end. I don't know, if we keep doing this and growing, growing without applying design patterns, do you know how it's going to end up? If we are going to take JavaScript seriously, we need to organize this mess and apply some structure. Some people say, hey, PHP makes spaghetti cold. But that's nothing compared with JavaScript. Asynchronous callbacks that trigger this callback hell. You know what I'm talking, if you have been there. So we want the end of spaghetti cold. Yeah, lasagna cold. I mean it in a positive way. We want JavaScript in layers, in modules, encapsulated code, decoupled code, you know, all those best practices that you already know, but we haven't think to apply them to JavaScript. So here is where Backbone enters. Backbone gives a structure to web applications by providing models, collection and views, connecting all to your existing API over a restful JSON interface. The author of Backbone is Jeremy Askenes. He's also author of underscore JS and coffee script. I'm sure you have heard. Backbone depends on underscore JS and jQuery. Hey, jQuery. I know jQuery. That's in Drupal core. True. That's where we are using already one framework, why to use another one. Well, they're not the same. Please pay attention now. These are important concepts. So when people talk about JavaScript, in general, it's a mix of these concepts. jQuery covers this area. The DOM events also makes really easy to make Ajax calls. So jQuery is making a great work covering that area and abstracting the DOM API across all main browsers. But here's the secret. The less that you touch the DOM, the better. The DOM is the big bottleneck nowadays in the frontend. Almost all these improvements that you have heard lately about JavaScript getting faster and faster in the browser. Almost everything about those improvements are in the ECMAScript interpreter, the pure JavaScript language. So Backbone is a library that decouples the pure data from the DOM. So it helps you to keep your data in the fast track in the red areas. And only when it's necessary, it will touch the DOM. Remember the red and blue colors. So here is the basic explanation of Backbone. A model is just a simple JavaScript object. And a view takes care of linking an HTML element, holding an HTML. So imagine this. A model asks to the server, A, I need some data. The rest API answers. And when the model has received this data is when it triggers, hey, I've changed. So it's the view who is listening to this event, the one who takes care of updating the HTML. You never touch the DOM directly. You left that work to Backbone. So if there is something that you should remember from this session, is this. The update of the DOM is a consequence of a change in the model. All right. And what about other frameworks? Jeremy released Backbone about two years ago. Since then has popped out many other frameworks adopting some ideas of Backbone. I encourage you to download them, review them, check the small differences between Backbone. But I will share with you my opinion why Backbone is better. For me, one of the main reasons is that it was the first. So today still is the more popular JavaScript MVC framework. What does it mean that? There is more blog posts. There is more tutorials. There is more Stack Overflow questions. Yeah, I know that you. So we are in a sweet spot for developers. It has... It's nice now to start developing in Backbone. And other benefit is that it's small and flexible, so you can adapt it to your needs. It has only 800 lines of code. The other frameworks... Okay, let's say that the problem here is that when you are starting to do a program in this way and apply the same patterns to JavaScript, it's something relatively new. So you need at the beginning a lot of help to try to figure out, okay, how this works. So I think Backbone answers better that question. So why Backbone is going to continue leading for more years? I think so. It's because of its philosophy. Jeremy is not... He's a veteran in JavaScript. He knows how to build libraries. And Backbone focused on only one thing and doing that thing very well. When it's small, it's easy to adapt also to whatever Backbone... Sorry, so many names. Backend. You can easily adapt also to the Drupal Lamp stack. So the author is very concerned about not bloating the library. He has the rule that if a change, a new feature, it will be only added to Backbone if it helps to 80% or more of Backbone users. Finally, if you don't like something of Backbone, just overwrite it. There is no problem. There is no don't hack Backbone. Did you hear what I said before? 800 lines of code. You can compare that with jQuery. jQuery has 6,000 lines of code. So it's quite small. That's good and bad. Bad because here's the truth. Backbone is not going to do much coding for you. It only provides you some minimalistic tools to build your application in a modular way. But it's only the skeleton. You need to understand how Backbone works. If you want to expand it and grow a complex web application, that's why I talk a lot about JavaScript during this part. Because if you are building a Backbone application, you need to know about JavaScript, JavaScript arrays, objects, closures, prototypes, scopes, all that stuff. So if you want really to take the full power of Backbone. But don't worry. I'm coming myself from a PHP Drupal background. I could learn it. I'm sure you can do too. Take it as a chance to learn JavaScript. Some tips at the beginning. Don't complicate your life. If you are going to make only a couple of Ajax calls, you don't need Backbone. Remember when I said JavaScript is everywhere? Well, it was a lie. One place where it has not arrived or still is arriving is to Google bots. So for you, it's important that your web application is fetched by Google. Then don't render your content in JavaScript. Backbone wait takes time to learn. It's not something fast. So I will reserve a couple of weeks to fully understand it. Anyway, you know, we are Drupal developers. We are used to a steep learning curve. So don't use compilers like coffee script until you master JavaScript. In the same way, there are some add-ons that you can put on top of Backbone. But I wouldn't recommend it at the beginning because probably you don't need them and they will blow up your application. Once that you learn Backbone, maybe you can do it yourself or use other add-ons, but don't try to hide your lack of knowledge using add-ons. And finally, don't waste time trying to learn it by theory. It's a model view whatever. The best advice I can give you is that if you want to learn Backbone, then read the source code, those 800 lines of code, and you will grasp it. I understand that you can create some tension between back end and front end developers. Or if you are working in both ends, you can create a conflict inside you. Should I put now the JavaScript hat or the PHP hat developer? When you choose one hat, then do it in the language. What I mean is that in Drupal 6 core, we started to program JavaScript from PHP. If you have worked with a hat properties, you know that they were a pain. This is called metaprogramming. We are doubling the complexity of our code when we do things like this. In Drupal 7, we add more metaprogramming. These kind of things are done with the best intentions. And it's suitable for really simple stuff. Not obstructive behavior. But we are in 2012. And this little sandbox is not enough. So that was my little rant. I have to get it out. Don't do more metaprogramming. I would like to finish my slides with the idea of embrace JavaScript. And when you put your hat of JavaScript developer, do it with JavaScript language. Don't feel bad about, oh, no, I'm not doing it in the Drupal way. Because Drupal way is also changing. Thanks to Larry and his whiskey initiative, we will have Drupal 8 exposing content in a native restful JSON way. And still PHP and Drupal are very important in this paradigm. Still we need authentication, storing the actual content, validation, permissions, emailing. Backbone is only liberating the servers from some pure client tasks. I will tweet later I extended version of my slides with some extra resources. But now let's listen to Ethan coming from United States to share with us his work on backbone module and how to make web apps with Drupal now, not in Drupal 8. Thank you. I don't have so many funny pictures. Sorry. So a few things as we get started. Let me switch my video. There we go. First off, can everybody hear me okay? Okay. Is it too loud? Okay. So a few things. One is just about the presentation, a note that I'm having some issues with some of the video demos. So I may have to just do it live, as we say. And, you know, I'll be covering some of the same things as David, but a lot from a little bit of a different perspective. So there's going to be a lot more code in this section. So this is how to use the Drupal backbone module. I'm one of the creators and maintainers of the module. Cormac requires another. And it's just Cromac. And we've had a few great contributors as well. Subtitle for this would be a deep dive into the shallow side of the pool. You know, I'm not going to be able to get into now every single thing about how to make the amazing backbone app that David showed. You can do a tremendous amount with backbone. But my goal really is to give you enough coming out of here that you'll have an idea of the kind of code that is required to use the Drupal backbone module, how to build basic backbone apps with Drupal and the module, and how those simple parts combine to make really complex, interactive, just stunning user interfaces. The goal of the module is basically to provide some of the solutions and fixes that others would have used backbone with Drupal have had to come up with. There's just ways that you have to work with the different Drupal restful back ends and why have everyone reinventing the wheel, right? So the module basically makes it easier to get started. And then it also supplies some best practices and some standard patterns for using backbone. So some things in a little bit in a way that aren't quite so backbone philosophical where it does a little more for you than backbone does. It makes a few more assumptions. And you can take those or leave those, but the idea is that it should make it easier for you to get started building a backbone application pretty quickly. As we talked about, backbone is great because it's super small and elegant. I would say not just the best way to learn how to use backbone is to read the backbone source. I think the best way to learn how to write good JavaScript is to read the backbone source. It's some of the best JavaScript you'll see. And it's also built to be extensible. And that's really one of the things that the module capitalizes on is extending the base backbone models and views to fit the Drupal application. And it's also really, really fun. The first project I worked on was just, I wanted to have more fun, so I used backbone. And it worked. So let's go. So start with a simple demo. Let's see if the video works. So David didn't do a to-do, so I will. This is made by Stein-Setfick. It's a port of the to-do app for backbone to Drupal. So instead of using, I think the original uses like a SQLite or maybe doesn't even have a backend, this actually is creating Drupal nodes and everything on the backend as these forms get submitted. So if we can find our way to the input. Well, first let's see. So that's just unpublishing that node or marking it complete. We can create a new node just by entering it here. As soon as we hit enter, it's going to get attached to the bottom of the list. In the background there, as David pointed out, it's all asynchronous. So the UI updated automatically. In the backend, it fired off a request to the server, created the node, but didn't wait for that to complete. So the user experience is really seamless. There's no kind of Ajax or AHA, you know, lurch. And then we just kind of refresh the page and now we can see that all of that is persistent because it's all on the Drupal backend. So everything that we marked complete is there. We get the awesome kind of fun Drupal update messages just because it proves that I'm not just lying. And that's me trying to make a Munich joke. So it's a really simple example, but it shows the power, you know, that's a node authoring interface. That's node add dressed up in a to-do application. And that's all using the Drupal backbone module. And it's really, I think it's like 40 or 50 lines of code. It's pretty short. So as we talked about the enemy, so we saw the enemy dressed up as a smiley kid with spaghetti and it was really cute. Let's look at the enemy's real face this time. That's what the enemy really looks like, right? So this is a great slide that I took out of a presentation by Justin Searls. It's conference.js. It's about testing with Jasmine and lots of really great stuff on how to test. But this basically outlines a kind of standard. We have this kind of stuff all over Drupal, right? You know, just fire off a request. When it comes back, do something. Oh yeah, maybe, you know, theme it this way. And sure, we have, we can kind of abstract the theming a little bit, but there's not a whole lot we can do to really clean this up. And the basic question I would pose is you wouldn't write server side code like this. You wouldn't write, you know, this is not the way that we would write code that we thought was important and real and serious. So why are we writing JavaScript code like this, right? And this is the exact problem that Backbone is meant to solve. So Backbone can help. It helps by just, let's break it down into three parts. I had a picture of a cute cat there, but it was not Creative Commons license. So I can break it down into requesting, getting stuff, communicating with the server. That's the Ajax layer that was in that awesome architecture diagram. We have rendering, which is actually putting that stuff into HTML and responding, actually processing user interactions to make stuff happen. So let's start with requesting. With Backbone, creating a node is as simple as those top two lines. We're actually, sorry, loading a node is as simple as those top two lines. We just create a new node model. That Backbone model's node, that's provided by the Drupal Backbone module. So it already has the interface to the node rest back and set up for you. It's all set to process. The data gets back. So all you have to do is create, oh, this is actually a mistake. It should say new. There should be a new Drupal Backbone model's node there. And then we just fetch it. So we create it. We specify the ID and fetch it from the server, I think. JavaScript is really cool. So, and then once we have that object, we can do all these cool things. We can use get to access different properties. So we can get fields on it. We can get the title. We can get the body. We can get collections, multiple nodes, all this stuff. We can set new properties. So we can set a title to something new. And then we could output the actual attributes property of that model. And we'd see a whole bunch of stuff, all very familiar. Same thing as if you were to DPM a node on the server, only it's going to be in JSON because that's where we are now. But we have this full node object to work with in a JavaScript application framework. Creating a node is basically just as simple. Here we're going to create a very simple node. This is actually a little bit oversimplified because the body needs to be a little more complex right now, but we're working on that. But we're going to tell it, say, what type it is, give it a title, give it a body, and then just save it. And again, the Backbone node model prototype just does it all for you. It knows how to talk to the server. It knows how to process the attributes. Boom. And you can do the same thing with users or comments or flags or anything else. In this case, the current most mature backend that's supported by the Drupal Backbone module is the service services and services REST implementation. But there's a REST full web services one in the works. And content API is definitely on the list. So the goal is to support all of the different current REST backends and be interchangeable between them. And it's set up to be for that kind of architecture. So this is a quick, you know, this is basically a different version of the different, the flow that David showed. But it's a little hard to read from this perspective, but hopefully it'll do. But this is basically what happens when you save is the individual model that you're working with. You save that. That runs to JSON model to actually take the attributes and encode them in the way that Drupal is expecting. That passes it to the backbone sync method. So backbone has this kind of global sync which can be overridden. You can have a sync method just for a specific model. You have real flexibility there and how backbone communicates to the server. And we'll see the power of that in a second. But then backbone sync is responsible for basically sending the JSON to the server waiting for it and firing off the call back when it gets back. And then when it comes back, the server sends back any updated fields. And so anything comes back from the server. So for instance, if it's a new node, now you'll have an NID. And so the NID is going to come back through this way and update the model. And when that model gets updated, it's going to fire an event saying, hey, I've changed. And that's really powerful because it's those events firing that let us decouple. So we don't have to listen to that specific model anymore. All we have to do is bind to that chain's event. And that's how we get this real power and much more maintainable, delicious lasagna code. Loading looks very similar. These will all be online, too. So if you want to kind of study them in more depth, but you're basically doing the same thing. It's passing through. If you want to have a very specific model, you can have that. And that will delegate to the backbone default nodes fetch implementation. That will queue the request with backbone sync, which will send the request for the node data to the server. We'll wait for it to respond and do its thing. One thing here to note is this little finish with custom parsing. So backbone runs a parse routine on the data it gets back from the server. And we can override that in various ways. And currently, we just basically pass the whole thing into the model. But the plan there is to actually have a really extensible parsing system that will actually parse individual fields, field types, or a generic parser as you want. So we can ultimately actually automatically parse based on a content type definition into a native JavaScript object. So I mentioned the power of backbone sync. The cool thing about backbone sync is you can point anywhere. So you can point and you can have in the same backbone app, you can have multiple sync methods. One could point to your Drupal REST backend. One could point, say, or maybe receive information from a WebSockets backend. Another could point to a RESTful CRM API, like a Salesforce or something like that. So you can do or any other system. So you can have what kind of promiscuous client-side applications where instead of having to write these middleware layers in our Drupal program, these modules that take in information and cache them for a certain amount of time, and maybe they hold them, maybe they don't, they don't know what to do, now we can just actually let the client take care of that. Drupal sends the content. It's responsible for the client loads content from other places as it's needed. This is actually the application that we've used backbone for most in our projects. So just to show a demo here, this is an example of the backbone module in the wild. This is a fairly minimal implementation. It's just pulling in information from a non-Drupal backend into a backbone, I mean, sorry, into a Drupal page. But the plans here are to actually extend that into load-related information from Drupal nodes, even though the main content is actually from archive.org. So here we'll see if, and here I'm getting my video issues. So the basic example here, and I'm not able to do good yet issues, we can send, this is going to be searching from archive.org's non-restable interface. So this is actually using JSONP. Click search. It's going out. It's getting the information. It's actually making two calls, so it's a very custom API implementation all in backbone. And it looks like native, the user never knows that they've actually talked to two different systems that they're on a Drupal page and they're looking at archive.org. The experience, frankly, is much better than an iframe or something like that. And there's no caching issues, no latency issues that you would have if you were to go with PHP solution. So for this solution, even though it's fairly simple, I think backbone is the right choice. It's really great for kind of middleware on the client side. So with that, I just want to thank my company EchoDitto for supporting the module development. That was an EchoDitto project. It supported a lot of the Drupal 6 back port. Drupal 7 is definitely where most of the action is at, but it's been really fun and great to have their support working on this. So two, rendering. Cool thing about backbone is now you're rendering on the client side. You're not rendering on the server anymore. So what you're doing is actually passing twig.js templates like this, or you can use handlebars or underscore or the three supported template libraries by the backbone module. Probably the only other one I think that's common. Well, there's a few others. There's Mustache and Dart I think. But I'm using twig because there's a twig session going on in the other room right now and twig is Drupal 8. Twig is in Drupal's future. And I'm also supposed to announce that tomorrow, if you're interested in the kind of future of the front end, there's going to be the core conversation that was rescheduled on the new theme layer, which will have twig as a key part. So it's kind of neat that we can have client templates and server side templates in the same language if we're using twig on the back end. But the cool thing is that twig.js is an open source project that can render the twig format used by Symphony on the client side. So we have a very simple template here for our node, just basically render the title on the body. The view is fairly simple too. So this is now a backbone view. Someone told me I should try calling them view, but I don't think I'm going to do that. So the backbone view is not the same as a Drupal view. It's more like a template function or theme function. And basically we just pass it a selector. So our templates are stored in the DOM. They're stored inside script tags with IDs. And we basically say, look here for this template. Use the twig renderer or the underscore renderer or the handlebars renderer. But here we're going to use twig. And then that's it. That's all we need to create our view to render a node. We just create a demo, a kind of example node here, and then just create a specific instance of our view with our model passed in. And as soon as we render it, it will take care of itself. So this is not the way backbone works. Backbone renderer doesn't do anything. The Drupal backbone renderer is pretty robust. It actually takes care of compiling templates for you. It takes care of attaching the element to the DOM if you want it to. So this is one part where, so you don't have to get deep in the weeds of backbone rendering and backbone architecture, you can get started really quickly with backbone and Drupal using this. And wow, pretty impressive, huh? That's what you get. So cool things about events though, right? So now we can use this binding and the fact that we have our data and our HTML decoupled and we can automatically update that HTML whenever the module changes. And so in this case what we're going to do is this key line right here where we're actually going to bind any changes on the model to the render function of the view. So basically what this says is that whenever we go through a whole process sending and receiving and we get information back and the information is different, or whenever someone says this.model.set title something different, whenever that model changes in any way, we want to update the HTML, update the DOM so it reflects that change. And now we don't have to worry about what might be changing. We don't have to keep on continuously updating every single time we make a call. It just takes care of itself. And this is like, this is the magic right here. Events and events bubbling up and down as we'll see let us write really complex code with just like this beautiful architecture. So here for instance, the title, as soon as we set the title to be magic, the title will change to magic. So three, responding. So we've talked about binding to events that are coming on the model, changes on the model. Let's talk about binding to events that are coming from the user. So the backbone views handle user events through an events array or through binding those events. To show an example of that, let's add a button to our template. So this is some simple just as Jeremy Ashkans would like raise his hand right now and tell me this is a really bad template and he's right. Template should never be stateful. They should never have if statements. This should be in the view function, yes, yes, yes. To keep it simple for the purposes of this talk, we're just going to put some logic into our template. But that's not the proper way. So basically what this is doing here is just a simple promote button. So it basically checks to see if the node is promoted. If it is, it's going to say unpromote. And if it's not promoted, then it's going to click on the button a little bit later. Let you promote. So this is a really simple toggle. And now all we have to do is update that simple view. You can see we're using the extend function here, which is the way that backbone allows you to extend its base events. It makes it really extensible. So simple parts, always extensible. That's the core of the philosophy. And so now basically we're saying we're using the the jQuery delegate syntax right here to say whenever that promote toggle element is clicked, run the function promote toggle. I think this maybe should be in quotes, but and promote toggle then is a simple function. Again, this is bad. This should really be on the model, but I'm trying to keep it simple, which is basically going to toggle, you know, just in just just flip the the promoted value between zero and one and then save it. And so now that's all we need to do to bind to bind a, you know, to listen to an event. And what that gives us is behavior. Unfortunately, this is another one of these ones that's not going to work. And this is a little harder for me to pull up right away. But basically when we click on the promote button, there we go. It's just going to update automatically because it's it's all right to automatically re-rendering. So there's no special I'm not listening to those click items. I'm never saying change the HTML all, you know, that whole, you know, all of that action, that whole changing and changing the state of the model, saving the model to the back end, everything that's all right here in this code. So super simple. Now, third part, I mean, a fourth part. So we talked about the three things that we need. Backbone offers this other awesome piece called collections. And that's for the really simple, really common use case, where you want to display lists of nodes or lists of users and you're in your one process, those lists in bulk somehow or you want to, you know, iterate over them and do something. So, you know, without something like backbone, it's kind of a chore. It's like go call of you, render it all, create some objects, maybe some DOM objects for each one, theme it, how are you going to do that? You know, if you do this kind of old school spaghetti JavaScript style, this is going to be really hard. Of course, with backbone, this is the backbone logo by the way. So with backbone in Drupal, it becomes awesome and really simple. So an example here, first we're going to just, this is a very basic backbone collection and backbone collections marry with views really well, right? So you can load a view with, which is a list of items into a collection and it will automatically create an individual model for each thing in the view, for each node in the view. So it's really pretty powerful. So here we're creating a view collection. So it's a node view collection. The whole view view thing gets really confusing. But so this is a view of nodes and it's a collection that holds a view of nodes. We just tell that collection that each individual item in the collection should be a standard node, nothing special, and that the name of the view, this is a parameter, we're going to be loading is Drupal Communic example view. So that's basically all we need to do to set up our collection to load a bunch of nodes from a view into JavaScript like that. We just run the fetch method, it's going to go out, it's going to get a huge array of nodes serializes JSON and it's going to create models models for each one and add them to the collection so they can be dealt with in bulk. So this is really powerful. And then we can do things like retrieve a single one, we can set the title or we can actually manipulate any one of those individual nodes in that list. And we can also save it. So we can make a bunch of changes and save them all together. And backbone will, you can code it to support batch, I think it's the patch verb on REST if you want to, but of course that's something that we have available to us now, unless someone tells me we do. So finally I'm just going to wrap up here with the last kind of this is a more complex example and this is one where we've tried to provide a standard pattern ready to go so that you don't have to go through the process of reinventing it which is the collection view pattern. And this is how you render a collection of nodes or a collection of models. And this is the kind of thing that backbone doesn't do for you. It lets you do it yourself so you have real control, but there's a pretty well-defined standard about how to go about it. So to make this work, we're just going to add one more template to our set here and it's going to be basically just a container with a UL to hold the results of that view. So when they come in, all of the models will be rendered into this UL here. We create a view now for that collection. So first we're going to set everything up. So we have our basic, the same collection that we had before. We have a very simple view for the node, the same one as we had before. One note here is that we're just specifying that we actually want to wrap each element in an LI because we're going to go into UL. So we're just basically taking the same template, same renderer, and backbone has the ability to wrap each element in some tag that we specify. So here we're saying LI. And then this is the second part of the same file. And basically what we're doing here is we're using the collection view prototype object that the Drupal backbone module provides. And here we're saying the same thing. We're telling it which collection it should be rendering. We're telling it what the template for the view should be. So actually what's the collection container template going to be? Again, which renderer. We're going to use twig. We're giving it an L. So we're actually giving it a selector to say you should attach yourself into the DOM here when you're done. Without that backbone won't put, it will actually, it will render, but it won't actually attach the element into the DOM until you tell it to. And then finally we're going to give it a view for each item. So we're saying this is the view that each model in this collection should be rendered with. So since this is going to be a collection of nodes, we're going to use this node view right here. We're going to pass that in. And finally, we're saying that when you render each of those items, you should render them into a search result, into the ul.searchResults element. And so that's basically saying you should go here. So there's a lot of arguments here. This is definitely getting to me more of an API. If you're familiar with like EmberJS or that kind of stuff, we're going more in that direction of being a little more robust. But if you don't want it, you don't have to do it. If this is helpful to you, you can render a collection right now with no additional code using this prototype object. And then all you have to do is render it. One of the really cool things is we render it, but we have to actually fetch the collection yet. So what's it going to render? At first it's going to be empty. And then as soon as we run that fetch, the fetch is going to go out to the server. It's going to get that huge serialized array of JSON nodes. It's going to start to parse each one, create a new model, add that model to the collection, create new model, add that model to the collection. Every single time a model is added, it triggers an add event. That add event is what the collection view uses to render a new model into the DOM. And so, you know, there's no code here that needs to listen for individual things being added or removed. You know, it all takes care of itself because it's using events. So events are your friend. So another cool thing, this is what the output is going to be. This is the same node template as we had before. We've reused it. Now we're just rendering it into a really nice container. Finally, what's really cool is we can actually use that same template and that same node object that we used before that had the interactivity, and that will work in our view, too. So now we can be promoting, unpromoting a view. We can have a search box here. We can do a ton of things. We haven't put any additional code in. We're just building on what we have. Each piece is taking care of its own work, but we're getting slowly more and more functionality. And you can see how this will be really powerful. So this is how you can finally build applications like David's. So backbones all about delegation. This is the basic backbone stack. Whoop, not that one. This one here. So you can see basically that we have in the backbone side, we have events are bubbling up from the models up, and they're changing the way the views are rendering to the DOM. Interactions are being passed down, so the views are triggering different model events based on interactions. And we have a basic Drupal architecture on the back end. So that's the basics of the JavaScript side. Really quickly now we'll talk about how to set up a module. An actual Drupal module that uses the backbone module API is pretty simple. All we're going to need is some page callback, some path, basically a router. Here we have an example of what the callback would look like. So we're going to include our library, so here we're going to use the Drupal, the services variant of the backbone library. We're going to include the twig.js rendering library. We use the backbone add template function to actually attach the template code into the DOM. It goes into a script tag and then just puts the code in there. And this is how we specify the selector. So that same selector whenever we say template selector on our views, we're using this string right here. And one note here is that we're using the theme layer to manage all of our templates. And that's just a convention, but it's a really helpful one. And finally, we're actually adding the JS for our app. And the app is going to be standard stuff. Just use behaviors, put on the attach, do some stuff. That's all you need to do. And finally, in that same callback function, we need to just give some root element that our app can attach to. And so here I'm just using a render array. This is an example theme function. Here you can see that we're, yeah, this is how we're specifying the different templates that we're including. And if they're going to be in external template files, it's pretty convenient that way. And one really cool thing that we get by using the theme layer is we can use the t function, which we don't have in Backbone natively. We can use a, there are JavaScript translation libraries and layers, but with Drupal actually we don't need to use them necessarily because we can translate on the server side by passing our backbone templates through the theme layer, run t, translate the different interface elements. And then we have translated, ready to go compile templates on the client side with no need to translate then. So this is a really nice feature we get only through using Drupal with Backbone. Okay, my time is almost up, but one more demo. This is by Cormac McGuire at Studio Roa. And it's, he's Cromack and he's, he also, he wrote another variation of a Backbone module about the same that I did, and we've been working together on this. And let me see if I can get this one working. Apparently it just takes a second or two. There we go. So this is a full video editing interface built in Drupal with Backbone. You've got in-place editing thanks to Backbone because now we have, you know, all of our data separated from our DOM so we can do all of this. I didn't actually click save there because I didn't want to change the title to item. We have drag and drop ordering because any, anything that jQuery delegate can describe can be bound to model events or model function or model methods. So, you know, drag and dropping counts. And, you know, here we're doing more in-place editing and save it. We can add a new shot here. We'll do that in a second. This is, you almost don't even realize this happened until it's, until it's there. We just added a new shot. It's already changed. I think it's actually entity reference on the object that's been added on the client side, saved out right away. So again, seamless. You're doing some really complex, you know, that's like one of the best, you know, node editing interfaces I've seen. And it's all Backbone. So, wait for one second. We want to know what you thought about this session. So please, if you can, take a minute maybe right now if you have a computer free to find, to find the session on the DrupalCon Munich website and click the take survey link. You can also definitely message us on Drupal.org or on Twitter. These slides will all be live as well. They'll all be on the, the Backbone module is Drupal.org slash project slash Backbone and it has links to documentation there. And there's a BOF tomorrow. I'll say one to two in the afternoon for those who are interested in contributing. There are rough edges on the module. I won't lie. We have issues that are open that I hope to crack over the next few days. If you're interested in helping out, please that'd be great. Thank you. I think we have a few minutes for questions unless everyone just wants to go drink. Just go to the mic if you have questions. Hello. Hello. Can people hear me? I don't know if you know off the top of your head, but how in a multi-language scenario and you're doing all the node, you know, node title set, things like that, what is the syntax like if you're trying to actually specify like a language or something like that? Yeah, if I wasn't actually glossing over what this really looks like. Yeah, so what this really looks like is this, right? So one of the tickets is to write a parsing layer for this. So you can have this be a property on the model. So right now you just reach in there, multi-lingual, you do what you got to do. We want to make it a little more convenient. I wonder if you run into some performance issues or something. For instance, when your app loads, you probably do a lot of requests. That means a lot of Drupal bootstraps. And do you feel this? At least what we are using is RequireJS. It has optimized compress all your model views, whatever, in only one single file. So you delegate the loader thing to RequireJS. So you don't need to worry about loading first the model or the view or whatever. Okay. And what about when on the same page you have a lot of collections and a lot of different models? So each of them needs to be fetched individually, I guess. Which means that you gather a lot of Drupal bootstraps for serving those things. And do you feel this? Right. So I think, first of all, it's a little bit early to tell. I don't think that there's been enough really hammering on it to know the performance issues there. Two things you can do. One is when we're loading a view, that's only one call. So we're not loading each model individually, right? So you have that makes it a little bit lighter. And you can also boot, you know, there is a bootstrapping paradigm for Backbone where if you know you're going to be using some items on your page, you render that to JSON on request in advance. You have it there. And then you're only making calls for additional updates after that. But the short is, no. I mean, you saw the to-do app is making nodes and everything. And it doesn't feel slow. There's no performance issues there. Yeah, but you're not 100 people are using it simultaneously. So you don't know yet. I would love some of the bang on it. Go ahead. We faced the problem too. You know, when you start to create more models and more models, each one has one fetch. So it's easily go to dozens. So that's why I said that you need to learn JavaScript to use Backbone. You can override it and it's flexible enough to create your, you can create only one single request, all the data there, and then start to trigger create model. It's called model reset. And you create all the models at once. So it depends. Each web application is going to need something different. But you can do it. It's not, Backbone is not going to stop you to say, no, you cannot do this. No, but maybe Drupal is a little bit heavy to render all, to fully bootstrap those things. So I guess if you have like a lightweight framework that pushes the JSON objects out, that makes it easier on the server. Yeah, of course. Okay. Second question is about the tweak. You said you can use the T function, right? Yes. But if it's when you render it on the as in Drupal itself, or what? Yeah. So that's, that's here. If you look here, this is, you know, it's this, it's this code here. But that means that you're rendering the template on the server. Yeah. So you're rendering it twice. But you're not rendering it. So I'm not, we're not rendering this part on the server. So that's going to be, we're actually producing a twig template through the Drupal theme layer. So we're rendering the template, but not actually interpolating all the, all the variable values. Okay. Thanks. How about entity metadata wrapper? When you look at the body UND0, it would be nice to have something like, like the entity metadata wrapper in, in backbone. Yes. So that's, that's the go. Yes. It would be really nice. And I welcome, I welcome help, especially, you know, I think this is probably a great group of people who are very familiar with working with the multilingual and with that, those constraints. So, yes. And the, the metadata you're planning to, to get them to, or like, I don't know, the list of fields on a node, like you said something about trying to guess them, but, but we have that information. So yeah, I mean, I think, you know, the way that we're trying to develop it is from the ground up a little bit. So probably the first thing is just a setting in your app. So you can choose what language you can choose those things. Ultimately, it would be great to have a generator for that data. So basically pass all of that in a Drupal settings array and use that to, to, to track the information. But I think that's probably a few steps down the road. You know, by that time, Drupal 8 will be out and we'll be using JSON, LD or something else, which will have full metadata included and we don't have to worry about it. But. Hi. In regard to performance, I was wondering if it wouldn't make more sense if you go full scale web app to use something like Node.js and you will have the possibility to get a fast response that's lightweight and you can reuse code, JavaScript for validation and stuff like that at the client side and the server side instead of using a more heavy framework like Drupal. Yeah, it has, it has a lot of sense to do this kind of thing. I think that if you really need very high performance requests, then you can use Node.js for some of them and others for, for persisting the data. Maybe you want to do it directly to Drupal. So you can use multiple backends. I think the other thing that I'm thinking is, you know, I think that tools like Backbone, all these different architectures, they're making it really easy to build these kinds of systems. And so part of my little forecast is that people are going to start expecting this kind of interactivity, not just in web apps, but, you know, the web, the line between websites and web apps is starting to blur. And so I think that, you know, there's no other CMS as well positioned to serve things that are combinational. Like you can think like a really robust news application that has lots of standard content management features, but also maybe has something for creating your own bundles of news stories. What's funny is Drupal is actually perfectly situated for that application. Whereas, you know, there's a few CMS projects in Node. I don't think that they're as mature yet. So I think that there's definitely applications for Drupal with Backbone. Have you had any experience trying to mix using both Drupal and Node.js or something similar to have a CMS for, you know, what all Drupal brings and have the fast lightweight REST API with something else using Backbone? Yeah, I have, and I would caution, like the idea of like a Node layer that would read a Drupal database scares me a lot. But it's an idea. Okay, I think we probably have time for one more. I don't know. I think actually there's going to be a presentation on Node.js doing something that scared you. But my question is more like, as we move towards more like one page apps and power those by Drupal, this solves one thing that solves the reading aspect. But the longer you stay on a page, the more changes of the underlying data. And we need to think about how we pull this data in a fashion that doesn't kill the server because caching is all fine and dandy. But Drupal, we need to have interactivity and we can't cache everything. So we basically need to think about ways of pub-subbing data and that introduces, that's sort of outside the scope of this module, but you are going to quickly get into that kind of thing where you need to be able to subscribe to changes in data. Imagining that to do app with more than one user, you're going to run into problems very quickly. For example, sorting things. That introduces a lot of other problems, but backbone is the right sort of one sort of part of the solution to that. But we're going to run into other problems very quickly as well. So just one note on that is that the Drupal Node.js module, what it actually does is basically implements sockets for Drupal. And so I think that that would be a great solution would be to be able to listen to those sockets with your backbone app. It takes care of all the dispatching, it does a lot of queuing, so you only have to do it once on the Drupal side. I think that kind of answers some of the other questions too. So if anyone wants to work on the Node.js Drupal integration for backbone module, let me know.