[taude]

One thing people don't really think about is that this whole notion of SPA is kind of a pipe-dream, overkill. There might be some apps that are really a single page application (likely just those simple, demo add task apps), but most really can be broken down and composed of many mini-applications.

For example, how often do your users go to their settings page? Does that need to be part of the SPA? Have a complex Settings pages that's composed of 5 or six tabs and 20 different user interactions? Maybe the settings page is itself it's own mini-SPA

How does a user flow through your app, do they really need every screen bundled under a single SPA?

Routing issues, complexity, code dependencies, etc...are all good reasons to not make one monolithic application, even if it's behind a login.

Likely your SPA should really be an app composed of a bunch of smaller SPAs. You search functionality...mini app, your separate workflows...a mini app, your timeline...mini app. history view...mini app, etc...

Breaking your app down into a bunch of smaller SPAs has a lot of advantages and implicit modularization, as well as productivity gains when working on bigger projects with bigger teams.

[hrayr]

This is exactly how I'm planning to architect my front-end code. Is Angular ideal for such environments or are there better suited frameworks.

[taude]

I have one project using Angular in this manner, and it's great for it (I don't use Angular's routing system). Another project is using Knockout.JS. I prefer the Knockout method when integrating with a lot of 3rd party/external JQuery components.

In general for a Web apps, you won't go wrong using different pages as a module system. It's proven and when your app gets big enough, you don't necessarily have to worry about a huge up-front download.

BTW, if you develp web apps to be shimmed into native apps, like PhoneGap, or something, then definitely look into the routing aspects of these libraries.