JSF vs Struts 2

JSF was designed in part by the authors of Struts to create a "Struts" that did a more accurate implementation of MVC (Struts is technically "Model 2") and to get rid of all the interface and subclass dependencies. The idea being that POJOS are more re-usable and easier to unit-test offline than framework-dependent code. Which is why I chant endlessly:
The more JSF-specific code that is in your JSF webapp, the more likely it is that you're doing it wrong.
The other thing that the Struts folks didn't like about Struts was that you had to define too many classes for each component. In JSF, you define a view template file, a backing bean (model), and that's basically it. There's no separate "action" class to transition data in and out of the MVC part of the webapp, just POJO methods that are defined in the same class as the POJO model.

https://coderanch.com/t/625642/java/Struts-JSF

AngularJS is not MVC

Your template drives your application. It's treated as a DSL. You write AngularJS components, and AngularJS will take care of pulling them in and making them available at the right time based on the structure of your template. This is very different to a standard MVC pattern, where the template is just for output.
It's more similar to XSLT than Ruby on Rails for example.

http://stackoverflow.com/a/23606512/2066936

MVC Model Is a ViewModel

Confirmation below that the "model" in the MVC world is not a place for business logic:

http://code.tutsplus.com/tutorials/how-to-write-code-that-embraces-change--net-29716

Our models should be "request models", i.e. dumb data objects used for passing information from MVC to the business logic. Optionally, I see no problem including input validation in the models, but nothing more. Business logic should not be in the models.

Adoption of View/Controller Separation

[T]he MVC approach did two separations. The most important separation was Separated Presentation - separating the model from the view/controller. The other separation, that of the view and controller, was not popular in rich client GUI frameworks, although it did have a resurgance with web based user interfaces. In MVC the view was a simple display of information in the model and the controller handled the various user input events. This doesn't work well with most GUI frameworks because they are designed so that the UI controls both display and receive the user input events.

 http://martinfowler.com/eaaDev/OrganizingPresentations.html