This may be the case for pure single page apps, but any real world application will have some pages you want to load faster and have easily indexed by search engines.

At https://starthq.com we started out as a single page app with a RESTful API using Angular, but with time it has become apparent that there are certain public pages that need to have the HTML generated server side. Now we have a hybrid solution, where some parts of the page are generated on the server and others, namely the parts that are different for anonymous and logged in users, on the client.

We've experimented with the likes of https://github.com/apiengine/seoserver but the truth of the matter is it's actually easier to generate the HTML server side than using Angular.

I agree that's an issue, and I also agree your workaround is the only one right now. That said, I view the architecture of having the client machine do view logic as being more sound, and I view the issue to which you refer as an SEO issue (rather than a fundamental problem) that the industry needs to come to grips with. Since AngularJS is from Google, I have a feeling they agree and we will be moving in that direction.

Yikes, Angular can't generate semantic HTML at the server yet? That explains why http://docs.angularjs.org/misc/faq is such a trainwreck. Letting crap like

  <a href="{{page.url}}">{{page.shortName}}</a>

go out on the wire to be uselessly displayed by arbitrary clients (even ordinary browsers that don't blindly trust your scripts) is a really severe failure mode.

Um, Angular runs on the client. "Generating semantic HTML at the server" isn't Angular's job.

I completely agree with this. I am working on a web application at the moment, and the server is very minimal. It just handles supplies a JSON-returning REST API, the index page, and some WebSockets stuff.

Doing things this way is quite nice, and forces separation between the client application and the server application. It makes the web application just a client, on an equal footing with any other client (iOS app, Android app, desktop application etc).

what are you using for the REST API on the "server side" ?

yes! this is exactly what I'm doing with Angular. I'm working with django on the server and have been able to thin out my server dramatically. It is now providing a RESTful api and doing some minimal business logic but I have been able to shrink my server side template rendering down to nearly nothing (just the bootstrap template served to the landing page). Angular is handling ALOT of display logic and user interaction logic that previously was handled server side.

are you using tastypie, the django rest api, or just writing views from scratch? what do you think is proper level of integration between a rest api module for django (or more generally a server-side library) and a client-side model layer such as anglar's or backbone's? and where do you place those boundaries, particularly when your rest api might be used by more than one type of client?

in any case, yeah, one way or another, serve static files & expose a rest api. this is the way forward. i'm excited too, just not exclamation point excited. or, well... fine: !

Most angular diehards really try to use as little jQuery as possible, since most the times it's not needed to do what you want to do

I guess I'd say most of us try to encapsulate it in directives or use the scopes that are there for us, but even Angular uses JQuery or its own jqLite under the hood.

edit to add: In fact, on further reflection, Angular passes JQuery or JQLite objects to the Link functions of custom directives, so it's actually kind of opinionated in favor of using JQuery, it just adds some extra layers of abstraction to ease some things.

Angular's jQLite does the job just fine. If you're writing directives, and not putting all your DOM manipulation in the controller, then jQuery is no longer necessary / useful IMHO. Why pull it in at all? The only thing it lacks is DOM wide selectors, but again, if you're writing a directive, you're passed the element, and you can do selectors on that element and it's children, which is all you should need -- otherwise, it seems the abstraction has started to leak, and requires re-consideration for your design.

I don't use any jQuery transitions / animations. Angular's own $http service does all the Ajax I need. YMMV, but I like the fact that I can avoid library bloat by learning one useful toolkit very well, and applying it effectively...and I happen to like all of its other features.

The display side of traditional frameworks might not be needed but there is a lot functionality they still supply in the (backend) Model and Controller side of things.

Just finished building a personal angular web app (http://pokerstoker.com). Generally a pleasant experience! I found the incompatibilities with other libraries (e.g. jQuery) a bit frustrating though.