Recommended
More Related Content
What's hot
What's hot (19)
Similar to Javascript mvc
Similar to Javascript mvc (20)
Recently uploaded
Recently uploaded (20)
Javascript mvc
- 1. Javascript MV* Bruno Félix Software Engineer @ White Road Software bruno.felix@whiteroad.pt @felix19350 Why you should care
- 2. Topics • Why is client side MV* relevant • Libraries / Frameworks • Backbone.js in the wild
- 3. Disclaimer I don’t think Javascript is a bad language, but it had a rough childhood (and some very stupid design decisions thrown in the mix)
- 4. The world’s most popular programming language 0 50 100 150 200 250 20/01/11 20/02/11 20/03/11 20/04/11 20/05/11 20/06/11 20/07/11 20/08/11 20/09/11 20/10/11 20/11/11 20/12/11 20/01/12 20/02/12 20/03/12 20/04/12 20/05/12 20/06/12 20/07/12 20/08/12 20/09/12 20/10/12 20/11/12 20/12/12 20/01/13 20/02/13 20/03/13 20/04/13 20/05/13 Average js size over time (kb) Source: http://httparchive.org
- 5. We are expected to build enduring apps, that provide user experiences on par with native apps. That goes well beyond DOM manipulation.
- 6. Using only jQuery (for instance), it’s easy to create a mess of callbacks and selectors.
- 7. We need to focus on higher level concerns right from the start: – Structure; – Persistence strategies; – Dependency management; – Code re-use (DRY); – Testing; These types of frameworks help us do just that.
- 8. JS MV* frameworks offer a simple way to separate concerns and provide much needed structure to web apps.
- 9. We have a lot of choice, to name a few: You can view a comple list @ http://todomvc.com
- 10. Categorizing libraries/frameworks Flexible Barebones Low learning curve Opinionated Lots of features out-of-the box Higher learning curve
- 11. Backbone.js in the wild Major wins: • Javascript templating decouples your JS code from the DOM specifics; • Code re-use to deal with common patterns; • Overriding Backbone Sync, to tailor the persistence strategies to your needs;
- 12. Sure, you could do a large web-app using just a DOM manipulation library… or no libraries at all…
- 13. A Javascript MV* allows you and your team to be more productive: – You don’t spend time re-inventing the wheel; – Helps establishing a clear structure for your project. Allows you to integrate new people onto team easily.
- 14. An interesting side effect was that we started looking at our server side code more like an API: – We could re-use the exact same API for a mobile app, delivering it very rapidly; – At a “macro” level, it helps separate the concerns even further: server side stuff should just provide a clean API, the web browser is a delivery mechanism, just like a mobile app or the command line.
- 15. Resources About Javascript: http://www.youtube.com/watch?v=v2ifWcnQs6M&list=PL5586336C26 BDB324 Linters are your friends (but they will hurt your feelings): – JS Lint: http://www.jslint.com/ – JS Hint: http://www.jshint.com Backbone Fundamentals: https://github.com/addyosmani/backbone-fundamentals A nice introduction to Angular Js: http://stephanebegaudeau.tumblr.com/post/48776908163/ever ything-you-need-to-understand-to-start-with
- 16. Noteworthy backbone plugins: Synapse (data binding – seems to have been discontinued): https://github.com/bruth/synapse Validation: https://github.com/thedersen/backbone.validation Backbone fetch cache: https://github.com/mrappleton/backbone-fetch-cache Marionette: https://github.com/marionettejs/backbone.marionette
- 17. Thanks! Bruno Félix Software Engineer @ White Road Software bruno.felix@whiteroad.pt @felix19350
Editor's Notes
- Do a show of hands of how many attendees regularly have to “deal” with javascript
- The graph is comes as no surprise. Just in the last two and a half years the average script size (for the Alexa top 1.000.000 sites) has doubled. So like it or not we are going to have to live with JS.
- Add an aside to the problem definition: and these apps should be maintanable in the long run!Refer the fact that in terms of DOM manipulation jQuery is the clear winner, so that issue is pretty much solved.
- But jQuery does not give you any structure, so it’s fairly easy to fall into the trap of creating spagetthi code (with a mess of plugins and event listeners, network calls, you name it…)
- Basically we have to apply the same standards we use on our server side code.
- Make a remark about the fact that not all of these frameworks strictly follow the MVC pattern, but rather adapt it to its needs. Usually you end up with a model and a view, but might not have a controller in the mix (ergo the MV*).Remember: JS MV* is only a tool, for simple web-pages where you need to add a little bit of flair, it might be overkill.
- Choice is a double edged knife: you can use a JS stack that is a great fit for your needs, just be ready to spend some time looking for the right plugins etc. On the other hand, frameworks like ember just make those decisions for you, so you’re ready to start focusing on your app right away.Note thatBackbone already comes with a Js templating lib – via Underscore.js, although you are free to use any other library such as Handlebars;In my oppinion this is a great library to get started with because with a moderate investment in time you can do some interesting thingsAngular stands appart from backbone and ember by the fact that it uses the DOM structure (via directives) to drive the app’s behaviour, instead of the JS code (Backbone views and Ember controllers)Refer that ember uses: Models, Views, Controllers, Routers, Templates, persistence, and for each of these deals with the most common issues (e.g. managing nested views, something that backbone doesn´t do).Although it relies heavily on conventions (e.g. you have to name the variables in a certain way in your handlebars templates so that databinding actually works) usually those are quite sensible.
- In the next few slides I’ll talk a little bit about my experience with backbone when going beyond the simple TODO list app.
- Remember, YOU are the bottleneck, take everything that helps in that front.