I have heard a lot about backbone.js and quite frankly I don't understand its concept. Does it require that all the elements should be in single page to work out with its animations and effects ? Or it can grab items from server and load it with transition or i mean different pages but make look like a single page. I didn't understand its concept well, so that's why i am asking. What i am looking for is to combine backbone or any other javascript framework to work with a rails project, that could give some ease transition across pages and can give native application look.
Backbone is also here to give you structure by being MVC, and it allows to communicate in a really simple way with the server. You'll be able to update / fetch / save your data (your rails models for example) on the server. So you'll need it if you want your user to work on an Ajax page without having to reload the page.
For example, you'll fetch all your data from the server when the page loads and then you'll have access to all attributes of your models and will be able to modify it and save it to the server.
Moreover, if you want your models to appear with transition, as Backbone is MVC, you'll be able to make that easily. As you have to choose when and where your views will appear on the DOM, you'll be able to put transition at that time.
By the way, Backbone works really great with Rails!
Backbone.js is all about data to be used in some way from your users, think about it as ActiveRecord plus Sinatra (or rails) on a browser, infact, the framework will give you a way to handle your data inside a browser instead of the server.
If you are looking for a simple way to add transitions to your existing app/website you could use a jquery plugin like Pagify (it rely on $.getHtml()) modifying it to get a fragment of the subpages like my (buggy) fork.
Related
I did my homework and read through this mini series about pushstate:
http://lostechies.com/derickbailey/2011/09/26/seo-and-accessibility-with-html5-pushstate-part-2-progressive-enhancement-with-backbone-js/
From what understand the hard part of implementing push state is making sure that my server side is going to serve the actual pages for the corresponding urls.
I feel like this is going to be a HUGE task, previously I was just sending a simple jade page as simple as:
body
header
section
div#main
footer.site-footer
div.footer-icons.footer-element
div.footer-element
span.footer-link Contact Us
span.footer-link Terms of Service
script(src='/javascripts/lib/require.js', data-main='/javascripts/application.js')
and I was doing all the rendering with my Marionette Layouts and Composite Views, and to be honest it was a bit complicated.
So from what I understand I need to replicate all that complicated nesting/rendering using jade on the server side for pushState to work properly?
I used underscore templates in the client-side, what is an easy way to re-use them on the server side?
I depends on what you want to do...
To "just" use pushState, the only requirement is that your server returns a valid page for each URL that can be reached by your app. However, the content returned by the server does NOT have to match what will get rendered client side. In other words, you could use a "catch all" route on the server side that always returns the page you have above, and then let Backbone/Marionette trigger its route to handle the rendering and display.
That said, if you want to use pushState for SEO, you likely want to have the static HTML sent by the server on the first call, then have the Marionette app start to enhance the interactivity. In this case, it is much more complex and you might want to experiment with using options to trigger the proper behavior (e.g. using attachView when enhancing existing HTML, showing views normally after that initial case).
Push state can work properly WITHOUT your server actually serving your application in the way that is suggested.
Push state is merely an alternative to hashbang url's, and it is supported in modern browsers. Check out the history docs here, you will see there is no mention of having your site serve your application statically at the url's for your application (but bear in mind it is opt-in).
What the article you reference is saying, is that for good SEO, you should do this. That's because you cannot guarantee when a search engine crawls your site, that it will execute your javascript, and pick up your routes etc. So serving the site statically is simply to give the search engine a way to get your content without executing any javascript.
Like you say, by doing this you are essentially building two sites in parallel, and it does literally double the amount of work you need to do. This may be ok if you're building a relatively simple site filled with static content, but if you are creating a complicated application, then it is probably too much in most situations.
Although I would add, if you are building an application, then SEO doesn't really matter, so it's a null point.
I'm trying to figure out what design pattern this web application would be described as using, if any:
https://dl.dropboxusercontent.com/u/37346336/design-pattern.png
It seems MVC-ish to me, with the Model being the top three sections, the View being the HTML rendered for the user, and the Controller being the JavaScript for the single screen that both deals with user input and gets/sets data with the REST API.
The 'single page application' code continues to listen for URI changes and contains functions that continue to be used application-wide, which is why I've indicated that all user input goes through it (rather than directly to the screen-specific JavaScript). But the screen-specific JavaScript deals with any events, etc within a particular screen. Unless a screen is loaded nothing is shown to the user except the header.
Maybe I'm trying too hard to make this fit the term 'MVC', but then is it something else? Or is 'SPA' just used for anything like this? I mean it is clearly an SPA, I'm just wondering if there's anything more specific and suitable.
It's not MVC, although I do not know what it's called. It could be the basis for an MVC setup using something like emberJS, AngularJS, GWT, etc, but this setup is too generic to draw that conclusion.
It is however a very nice setup that I use a lot. First calling in the static HTML as a one pager that contains all the templates and then pulling in the data using JavaScript calls. I personally prefer to not include any user specific content in the initial HTML so it is highly cashable (even in a CDN if needed) and only pull in user data through AJAX calls.
I myself prefer not to calling it an MVC, I can not figure out any controller object here.
In MVC there should be a master controller which receives all requests, control them (like user data validation, page navigation, session management.... all should be done in the controller).
So the controller in my view should be developed with a server side technology so it can do all the controller duties.
It is said that Backbone handles all the higher level abstractions, while jQuery or similar libraries work with the DOM, normalize events and so on..
Could someone please help me understand this statement with any simple practical example.
Also one important feature of MVC framework like Backbone, Knockout is that it keeps the model (data) and the view in sync. But this seems to be specific at a page-level and not across the entire application. So can we have the model/data and the view synced across multiple pages..(kind of global)
Your opening sentence was actually a very good statement of the differences between Backbone.js and jQuery, so let's unpack it a bit.
For one thing, the two libraries are not at all in competition--they are complimentary.
As an example, here are some things I would do with jQuery:
Animated slideshows
Form control enhancements, like an iOS-style number "spinner"
Toggling visibility of elements based on a class name
And some things that I might do in Backbone.js:
Create a photo album, where the user clicks on a thumbnail and can view a larger version of the photo, along with some data like the camera that was used, the location and the photographer's name
Build a master/details type of page that presents a grid of data and allows the user to click on individual elements and update them in a form.
jQuery excels at the micro level--selecting page elements, smoothing out the differences in how browsers handle events.
Backbone.js is more big-picture. It helps you manage data and application logic. In the photo album example above, Backbone provides several useful structures: you'd have something to contain all of the data related to photos (a model), a list of all the photos in the album (a collection), and somewhere to put logic that determines what happens when a user clicks on a thumbnail (the view). Those are the main pieces in a Backbone control or application.
Backbone.js benefits from jQuery, though, or something like it, to help render the results of your application's data and logic into the DOM. It's common, for example, to use jQuery to select the element on the page that will serve as the container for your Backbone app. It's also common to use jQuery's $(function () {}); to fire up the pieces of your Backbone control. You'd probably display form field validation error messages with jQuery as well.
You can certainly build big, complex user interfaces in jQuery. We have a few in the app I maintain at work. But they are difficult to work with because jQuery isn't designed to provide structure to an application. In particular, jQuery's API, which is based around selecting groups of items and then passing callback functions that manipulate those items, isn't a good pattern to use in a large, complex control or app. You end up with a lot of nested functions and it's very hard to see what's going on.
I'm currently reworking one of those controls in Backbone.js. As a final example, here's a quick summary of how my thought process differs when working on the same control in both different libraries.
In jQuery, I'm worried about:
Am I using the right selector to grab the group of li elements I want?
Do I need to repopulate that list of values when this Ajax call completes?
How can I put these array values back into the input elements on the page?
In Backbone, I'm more focused on:
What is the correct logic to validate this set of properties on my model item?
When the user clicks the Add button, should I add a new item to the collection immediately, or should I wait until they've filled in all the data and it's "valid"?
How should an item in my collection respond when the item immediately before or after it is deleted?
jQuery handles the nitty-gritty details, and Backbone is more high-level.
In closing, notice I've been using the words "control" and "app" when discussing Backbone.js examples. It's not true that Backbone.js is just for single page apps. It is true, though, that Backbone.js is good for building complex applications that manipulate data and handle a lot of logic. It would be silly to use it for small-scale UI elements--the extra structure it imposes isn't needed.
Update: On the issue of multiple pages, yes, Backbone does provide a powerful mechanism for persisting your data. Each model has a save method that will execute an AJAX call to store the changes on the server. So as long as you save your data as you go, you can have a multi-page app. It's a very flexible model, and it's how we'll probably end up using Backbone at work. While I would love to build a single-page app, we have 10 years of work in our existing multi-page application. We're looking to rebuild some of our more intense UI components in Backbone, then sync the changes to the server before the user moves to a different page.
Backbone / Knockout is typically used for single page applications. So while jQuery is a toolbox that can be used with any webpage, Backbone is meant for a specific type of application and helps you organize your code for it. At least in my experience one of the biggest challenges in building a single page app is keeping the code clean and modular, and backbone helps a great deal with this.
The characteristics of a typical backbone app are:
Essentially static html page, with nothing generated on the server
Server acts as a json REST api, which provides the content for the app
The dom elements to display the data are created with javascript in backbone views, using jQuery and various templating libraries to help
Communication with the server as well as between different parts of the app is done through the backbone models
Regarding your question about keeping the data synced across multiple pages, my instinctive answer is that you don't need multiple pages: the user may perceive that the page is changing, the address in the url bar changes thanks to pushState functionality, but technically the entire app is one page.
The biggest advantages of this kind of approach are a smooth user experience (no reloading pages), good caching support as everything except the json data is static content, for mobile targets the possibility to turn the web app into a mobile app with phoneGap (because everything except json is static).
I have never heard of people using backbone.js across multiple pages. It's almost always some kind of single page app.
The single page may have many different models, views, and states and can result in a full blown, powerful app.
If you already have server-side template/view rendering in java then backbone.js is NOT for you. To get the most out of backbone.js you must move or duplicate some of that code in the front end javascript.
If you don't want to do a single page app (this just means an app without page refreshes or changes, but the url can still change and can look like multi-pages to the user) then you can keep all of your MVC on the server and you have no need for backbone.
Edit:
What backbone does is move some of the MVC stuff normally handled on the server and move them to the client. For many people this means forgetting about the server and just writing your app as a single page javascript app. The server becomes just a source of JSON/REST data. If you're not prepared to do that, then backbone.js is not that useful.
Backbone is a MV* framework while jQuery is a DOM toolkit.
The main features of an MV* application are routing, data binding, templates/views, models, and data access.
Backbone could dependant on jQuery partially.
jQuery is a solid API for querying the DOM with extensive browser support and a vibrant community. It comes with event handling, deferred objects, and animations.
Simple event binding using jQuery
// When any <p> tag is clicked, we expect to see '<p> was clicked' in the console.
$( "p" ).on( "click", function() {
console.log( "<p> was clicked" );
});
I want to develop a relatively simple application that calculates some value based on several inputs. I dont want a backend, all the calculation can be done in the browser.
Im a little new to JavaScript and WebApps and I came across Backbone.js.
I really like the MVC design, however, they mention a backend a lot. My question:
Is a backend server absolutely required?
Is a backend server optional but without one there isn't much point in backbone.
Or will backbone will really help me out?
Backend is not required.
Backbone can fully work without any backend if your application doesn't require one.
That depends on your application. If you want to retrieve value of some inputs and calculate a result then Backbone won't do that for you - it will help you structure your code. If you app is simple and don't need support for models, views and collections or routing, then there is no point in using Backbone. Hard to answer this question.
For example: Classic todo example application doesn't use any backend.
Backbone.js implements fetch(), save(), destroy() etc. methods on models automatically performing appropriate AJAX requests and parsing response. So it has a strong support for backend via REST services, but it is optional.
You can still use models, views, routers and events without any server-side code. Just don't call REST methods (or override them at your wish).
You can use localStorage for persistence (you'd have to implement this yourself or find it on the web, like here) but if you don't even need that then you don't need to use any of the persistence methods in backbone.
Backbone is meant to help you structure a medium-large sized application (js-wise), so it doesn't become unmaintainable jQuery spaghetti. With short applications (js-wise) it's really an overkill unless you are trying to learn how backbone works.
Note with js-wise I mean the client side code, if you had a huge backend but the only js would be something that focuses some form, it would not even count as a short application (js-wise).
You can use backbone.js without a backend. However you obviously won't be able to store or retrieve data. Backbone may still be useful for keeping your code organized, however it really shines when you want to separate presentation logic from logic that manipulates your data, which is a goal of the MVC pattern. Generally your data will be stored on and retrieved from a backend.
If you want to play around with data persistence, try out backlift.com. [disclosure, I work on backlift.com] We've tried to make it easy to get a backbone app up-and-running without having to setup a server or deal with compiling templates.
I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.
The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.
Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.
I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.