Marius Bogoevici <marius.bogoevici@gmail.com> wrote, in response to Jason Porter:
Besides separation of concerns between the designers and coders, there are tangible architectural benefits from using client-side frameworks, the likes of which haven't been really possible (at least not in a practical fashion) before the advancements brought in my HTML5 (and I include here the JavaScript overhaul).
The most important bit, from an architectural point of view is that by moving logic to the client side, the application can operate in a more disconnected fashion - i.e. be more responsive, have richer functionality,operate offline - generally qualities associated with single page apps. In a context which relies heavily on server-side processing and rendering, like JSF does, this would result in a chattier interaction model, as the state of the application would need to be communicated to the server. Even for JSF, however, libraries such as Richfaces address that challenge, and a mixed client-server side model can be adopted too.
One of the biggest benefits of moving functionality to the client side is that it makes mobile web (and by extension mobile hybrid/native) applications development much easier - the single page, rich client application model is much more suitable to mobile clients.
This is simply another way of doing things. You could do the same thing with JSF and simply call the actual REST endpoints manually in a backing bean (so you don't have to do the extra HTTP call). This approach has the benefit of working on the UI and the backend in parallel with different teams (among others). All you'd need to agree on is the URLs and the returns (format & content). It also makes creating multiple UIs easier (say a web app in JSF and a native mobile app).
-----
Options: You can moderate through email. Respond in the body with "Delete", "Approve", or "Spam". Reply with "Like" to like this comment, or respond in the body to post a reply comment.
Or use the moderate panel: http://jdf.disqus.com/admin/moderate/#/pending