Drupal Backbone.js in the Frontend

Editor's Notes

• #3: A little about me:I’m a Computer Science EngineerI’m Spanish but living in Finland.I’ve been working and contributing to Drupal for more than 3 yearsI’m working for #AberdeenCloud, the new way of hosting Drupal
• #5: Why I’m here talking with you about JavaScript and Backbone.js ?Because Backbone fits into Drupal futureThe *Big picture* is this:In the Backend, Drupal 8 will support natively RESTful calls, and in the frontend Backbone takes care of the User Interface, consuming the JSON data and rendering the HTML.But before we start to get into details …
• #6: Start with the demoI was thinking to demo you a really basic TODO app, but better, I will show you a full complex web application: the #AberdeenCloud web interface.
• #7: We made the decision to build the interface with backbone and we don’t regret.It enforces you to follow healthy design patterns and has made our code much easier to maintainOur backend doesn’t render any HTML, it’s all in the frontend. For the end user this translates into an extremely better user experience: the interface reacts instantly. Forget about refreshing pagesIf Backbone has worked for us, I’m sure it can help you too in your next web app. Now let’s see how we have arrived to this point after a decade of web evolution
• #8: Do you remember how it was building web pages in 2000 ? I can’t remember anymore, but JavaScript was used those annoying alerts, dialogs, or pop-ups, it’s normal that JavaScript got a bad reputation from those days.[Click]It was later on, about 2006 when we started to look JavaScript with different eyes, after Google released Gmail with a pure JavaScript interface. Whaa… you can do that with JavaScript ?jQuery 1.0 was released by that time, but still most of websites were using JavaScript for some basic things, copy – pasting some javascript snippets in their HTML.[Click]Now. 2012. Today many developers are using JavaScript for important tasks, and is sharing the heavy-lifting with the backend. Today we don’t add only couple of JavaScript snippets. Today it’s normal to build websites with dozens of javascript files, multiple 3rd party libraries, and it’s becoming normal to have teams of front-end developers only to work in the interface.
• #9: Do you recognize this slogan? Whose slogan it is? Yeah, it is Java’s slogan. As you know Java has nothing to do with Javascript. They say that Java is to Javascript as Ham is to Hamster.Although they are totally different, JavaScript is becoming the run-everywherelanguage that Java wanted to be. If you think about it, JavaScript is the only language that is shared across all main browsers. There is a JavaScript interpreter almost in all operative systems, in mobile phones, tablets and soon even in your TVs.Javascript is here to stay for some time, so there are big benefits to program your frontend in JavaScriptWho programs in JavaScript? Who likes it? Who hates it ? XD
• #10: This is a screenshot that shows the Top Languages hosted on Github, number 1, JavaScriptJavaScript is growing in other ways too …
• #11: This graph represents the last 2 years of evolution among the top 1 million sites in the Alexa Ranking.As you can see, the average JavaScript size nowadays has increased a lot.Further proof that we are no longer talking about “sugar” Javascript. We keep adding more and more logic to our frontend.If we keep doing that, without applying design patterns. Do you know how it’s going to end up ?
• #12: If we are going to take JavaScript seriously.. we need to organize this mess and apply some structure.Some people says “Ah… PHP makes spaghetti code”. They don’t have a clue.That’s *nothing* compared to JavaScript: Asynchronous callbacks that triggers other callbacks that triggers other callbacks… the “Callback hell” . You know what I’m talking about if you have been there.We want the end of Spaguetti code (click)
• #13: Yes, Lasagna code.I really mean it in a positive way.JavaScript in layers, modular encapsulated code, decoupled code easy to test. All those best practices that YOU already know, but we haven’t stopped to think about applying them to JavaScript.In my point of view, this is the main benefit of using Backbone
• #14: So here is where Backbone enters.Jeremy Ashkenas is the author of Backbone, underscore.js and CoffeScriptBackbone depends on underscore.js and jQuery. Hey, hey!, jQuery, I know jQuery and it’s part of Drupal core.Why use Backbone if we have already jQuery? Well, they are not the same…
• #15: Please pay attention now, these are important concepts:When people talk about “Javascript”, in general is a mix of these concepts[Click]So jQuery covers basically the DOM and Ajax. It makes a *great work* abstracting the DOM Api across all browsers and makes Ajax request easy as you know.But here is the secret: The less that you use the DOM, the better. DOM is the big bottleneck nowadays in the frontend.Most of the improvements in JavaScript speed in modern browsers during the last years are about EcmaScript Interpreters, Nowadays there are really fast.Backbone is a library that decouples your pure data from the DOM and Backbone helps you to keep things in the “Fast” side, touching as little as possible the DOM.It will make your app faster and your code cleaner.
• #16: A Model in Backbone is just a JavaScript Object with some extra methods to basically fetch and save data to the serverImagine that the model asks from the server new data and when it has received, the Model triggers an event ‘hey, everyone!, I’ve changed’The view, that is listening to that event, takes care of updating the HTML: You don’t touch directly the DOMBackbone aims for a total separation of data and UI, not like other Javascript MVC frameworks.If there is something that you should remember of this session is this:The update of DOM, it’s a *consequence* of a change in a model. You should never need to manipulate directly the DOM yourself
• #17: Jeremy released Backbone about two years ago[Click]Since then many other similar frameworks have pop out adopting ideas from Backbone.jsI know that is difficult to choose between JavaScript frameworks, but I would share with you my opinion…
• #19: Backbone was the first. It is today more popular than any other MVC framework. What does it mean?More tutorials, more blog posts, more stack-overflow questions. We are in a sweet spot for developers.It’s small and flexible, only 800 LOCThe other frameworks are good too, I encourage you to review them and compare the small differences between them.The problem here is that applying design patterns to JavaScript apps is something relatively new, so you need all the support that you can at the beginning to start to figure out how it works.Why Backbone will continue leading for more years ? Because its philosophy (click)
• #20: Backbone Philosophy: Focus on beingsmall and doing 1 thing really well.When it’s small it’s easy to adapt it to your needs, it’s server Agnostic, so it’s easy to adapt it to the LAMP Drupal stackThe author, Jeremy is very concerned of not bloating the library. New features are only added if they help to 80% or more of Backbone users. And if you don’t like something, just override it
• #21: Did you hear what I said before ? 800 LOCCompare it with jQuery: More than 6.000 locSo it’s quite small. That’s good and bad.So here is the truth: Backbone is not doing much coding for you, it only provides you minimalistic tools “to build your app in a modular way”. It gives you a basic skeleton for structuring your codeYou need to understand how Backbone works to expand it and grow a complex web app. That’s why I talked a lot about JavaScript language during this session. If you are building Backbone application, you need to know about Javascript arrays, objects, scopes, closures, prototypes, all that stuff if you want to take the full power of Backbone.But don’t be worried . I’m coming from a PHP-Drupal background myself, so if I could learn it , you can do it too. Take it as a chance to learn JavaScript.
• #22: Don’t complicate your life. To make a couple of Ajax calls, you don’t need BackboneRemember when I said that JavaScript is everywhere? Well that was a lie. One place where has not arrived is to Google bots, so if for you it’s important that content is fetched by Google, then don’t use JavaScript to render content.Backbone-way takes time to learn. Prepare at least couple of weeks to fully understand it.. But anyway we, Drupal developers, are used to steep learning curves, so I’m sure you won’t have any problems.Don’t use compilers like Coffeescript until you master JavaScript.And in the same way, there are some add-ons that they promise you to make easier your life, but probably you don’t need them and they will bloat your app.Don’t waste time trying to understand it by theory. It’s a (Model View Whatever) framework. The best advice I can give you is read the source code, those 800 LOC, if you really want to grasp it.
• #23: I understand that it can create tension between back-end and front-end developers.Or if you are working in both ends, it can create a conflict inside you deciding Should I put the hat of “JavaScript developer” or the hat of “PHP developer”But you must choose one hat, and do it with that language.What I mean is…
• #24: In Drupal 6 core we started to program JavaScript *from* PHP.If you have worked with “ahah” properties, you know that they were a pain.This is called meta-programming, and we are doubling the complexity of our code when we do things like this[Click]In Drupal 7 we have more metaprogramming. This kind of things were done with best intentions, and is suitable for really simple stuff and not obtrusive behavior. But we are in 2012 and this little sandbox is not enough
• #25: So that was my little rant.Please don’t do meta-programming any more in Drupal 8I would like to finish my slides, with this idea: Embrace JavaScript. And when you put your hat of JavaScript developer, do it with JavaScript languageDon’t feel bad “oh noes, I’m not doing it the Drupal way”, because Drupal way is also changing.Thanks to Larry Gardfield and his WSCCI initiative, we will have Drupal 8 exposing content in a native RESTfulJSONway. And still PHP & Drupal are very important in this paradigm, still we need authentication, storingthe actual content, the validation, the permissions, the emailing system, etc.Backbone just liberates the server from some pure-client-tasks.
• #26: I will tweet a link to the extended version of my slides later todayBut now let’s listen to Ethan, coming from United States to share with us his work on the Backbone Module and how to make web apps with Drupal 7.Thank you