Develop Reference

Using AngularJS for Multiple Page Application [duplicate]

We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.
This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.
We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.
This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.
UPDATE 17 July 2013
Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.
The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.
UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.

Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.
You have a large list of features that will benefit you outside of client-side routing:
two-way binding
templating
currency formatting
pluralization
reusable controls
RESTful api handling
AJAX handling
modularization
dependency injection
It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".
If it fits your project, use it.

I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.

Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Each of these applications has it's own local routing mappings between states in the application.
I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.
Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.
In response to your question:
Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.
I also support the idea:
What’s the difference between a project and an app? An app is a Web
application that does something – e.g., a Weblog system, a database of
public records or a simple poll app. A project is a collection of
configuration and apps for a particular website. A project can contain
multiple apps. An app can be in multiple projects.

If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.
Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.
Javascript namespacing allows you to keep your code separate and manageable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
And in a script tag after your other scripts are loaded
<script>
myCo.init();
</script>
The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).
Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.

I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.
Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.
Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.
Links:
https://vuejs.org/
http://aurelia.io/

Dropping Spine.js into an existing app?

I've been looking at quite a few of the MVC for JavaScript frameworks lately and I quite like the overall feel of Spine.js as well as the fact it is using CoffeeScript. That said, my primary concern at this stage is I need to be able to drop an MVC framework iteratively into a fairly large existing application. Most of the documentation that I have seen on Spine.js focuses on creating new applications.
Does anyone have any suggestions on the best way to go about doing this; if there is a good tutorial somewhere that would be great too, but Google was not my friend on that one.
Or is this just a bad idea and I should go elsewhere when dealing with legacy? While Angular didn't click with me in the same way; it did however seem pretty straight forward on how I could use it iteratively with a legacy application.

I think it's rather a bad idea to do it "iteratively". I'm working as freelancer for a company where they decided to do a complete UI rework splited over a few releases. In the first stage it was planned to drop the existing JS and use spine js as MVC and require js as AMD. So far so good - but the process was "iteratively". The project/App is quite complex and it took over a half year (I'm involved since 2,5 months).
It was a big mistake to leave all the existing JS and "iteratively" replace the functionality for the release. We ran into multiple problems, because of that. If you have hundreds of js files, inline scripts, dependencies it's much easier to simply throw them away, because you can tell literally if your new code works or not. Otherwise you always have to distinguish whose fault is it: new or old code.
This was also responsible for trouble that could have been avoided, or at least alleviated, if it were a hard cut:
The product owner was not really aware of the status, because he couldn't see any visible progress. He only figured out bugs and misbehaviour. That was unsatisfying/frustrating for both parties. One quote I've heard over and over again: "It did work the other day/before - now it's not"
You start to update some outdated libs, plugins that sometimes will cause compatibility issues, because API's tend to change, so you have to fix that in your old code as well. Means: at some point it starts to feel like hacking around problems and not to develop a cool/good App. Thats's extremely frustrating too.
It took waaays longer than expected/estimated.
You've been developing in dependency of your old code that does not exist in the very end.
My personal advice is: don't do it iteratively. Do hot fixes for the live App and develop the new one on a separate branch.

I can't see how conforming any legacy app that didn't have an explicit mvc structure into a spine.js or backbone or angular etc. is likely to be a drop in experience.
Iteratively converting is going to be a lot like writing a new app minus the boilerplate stuff for defining the app GUI interaction. Start by focusing on models and controllers by pulling out components that fit well into the MVC structure. I would suggest early on to avoid certain app interaction components of Spine like stacks, and routes as those make a lot more sense once everything else is ready to be used according to spine convention.

Is AngularJS just for single-page applications (SPAs)?

We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.
This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.
We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.
This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.
UPDATE 17 July 2013
Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.
The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.
UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.

Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.
You have a large list of features that will benefit you outside of client-side routing:
two-way binding
templating
currency formatting
pluralization
reusable controls
RESTful api handling
AJAX handling
modularization
dependency injection
It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".
If it fits your project, use it.

I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.

Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Each of these applications has it's own local routing mappings between states in the application.
I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.
Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.
In response to your question:
Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.
I also support the idea:
What’s the difference between a project and an app? An app is a Web
application that does something – e.g., a Weblog system, a database of
public records or a simple poll app. A project is a collection of
configuration and apps for a particular website. A project can contain
multiple apps. An app can be in multiple projects.

If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.
Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.
Javascript namespacing allows you to keep your code separate and manageable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
And in a script tag after your other scripts are loaded
<script>
myCo.init();
</script>
The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).
Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.

I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.
Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.
Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.
Links:
https://vuejs.org/
http://aurelia.io/

Other than data binding, what advantages does backbone.js (or knockout.js) offer

The JavaScript codebase we are using on our website is pretty well structured (outlined here if anyone's interested).
I have been looking at integrating backbone.js (or knockout.js, for some of the features) into our code -- but after closer considerations I don't think I care that much about data binding (my appliation does not do intensive client<->server data exchange, its more biased towards server->client->js data pipe), so I don't really care if I don't have dynamic data binding and syncing.
As I am not closely familiar with those libraries, I am afraid that by opting-out of using those libraries, I am missing some other vitally helpful features. Am I?

Personally I'd use backbone if I was building a full blown single-page web-app. If your website is primarily HTML, but uses JS for some minor added functionality I'd not worry about it. Backbone is good at handling client-side data models and tying changes to those to view updates.
Personally, I've used knockout and found it's reliance on data-binding in the HTML confusing. It wasn't something that worked well for me. It might be a little bit more friendly to building websites that are partially dynamic, because a lot of the logic goes right into the html view layer. You may want to listen to this recent podcast interview the creator of knockout as it may shed some light on things. http://javascriptjabber.com/
In my case, when building a big website with some dynamic elements I've stuck with the pattern of some global jQuery plugins and page specific JS. It works well enough for simple additions to specific pages.
I don't know if this question is super specific, so here's a generic answer :)

I'd first like to point out that while declarative databinding is the key feature for KnockoutJS, it is not a part of the core-backbone framework. There do exist multiple plugins like (Rivets.js and Orchestrator) which provide such functionality in Backbone JS.
Now coming to the primary aspect of your question - In terms of advantages other than Data-binding KnockoutJS does not have much to offer. However even if interactive data binding is not a primary concern you should definitely consider using BackboneJS. The reason for that is Backbone comes bundled with a client side routing system and a succinct but minimal approach towards managing Data obtained from the server in javascript.
As you have mentioned that your application is data-driven, probably the data that you have fetched in the client is not fetched all at once but is incrementally updated. In that scenario, having observable Models and collections might help you to manage your in-app data-dependencies well (as well as keep any widges for visualizing the data in sync.)

Best way to separate data from DOM

I have this time tracking / task managment tool I'm working on called Task Ranger. Basically you make a tree of tasks and sub-tasks, click on whichever task you're currently working on, and your time for that task is tracked.
I want to add a feature where the user can look at their times for a specific date range (ie. "What did I spend my time on last week?") I'm thinking I want to have a tab that I can click to jump from the "Main" view to the "History" view.
The problem is that right now I'm persisting my data by simply storing everything in the DOM and dumping the entire html structure into localStorage. In order to get the history view to work I'm going to need to separate the data from the html, right? I guess an MVC framework is the typical way of doing that, right? I was looking at Backbone, but I'm feeling like it might be a little overkill for this. I'm thinking maybe I should roll my own simple little thing. What do you think?
I'm using Javascript + Jquery for all of this right now.

Backbone is about as lightweight as you can get MVC. If I were to write my own micro MVC framework it would convert to backbone within a week.
I would highly recommend Backbone over writing your own because it's well structured and loosely coupled. You can only use the features of backbone that you want. Since your already including jQuery there is little overhead of including backbone aswell.
Backbone is great for structuring and organizing your code.
You can use the backbone-localstorage adapter to save your models to localStorage.
You can then save a backlog of all your models or get them from a RESTful server for your history view.
A solid alternative to backbone would be spine which is also a lightweight MVC library. Spine has a more traditional MVC attitude and is only 2kB