sorry for the confusion, I meant just having JSON API server is more minimal and let's you focus on what you actually do; programming your backend...

web frameworks do two things and they're terrible on both. they invent a lot of stuff that you'll likely try to get rid of a later time and it's gonna be too late since your codebase (both frontend and backend) is locked.

but API servers are not like that. they lead you the right (and the more productive) way; composing small libraries into something ideal for you. I'm not sure if it makes sense for people who tend to use frameworks but this works for me great. may be it's my taste

Separating the JSON API from the presentation layer is a clean separation of concerns. Structuring your app this way makes it easy to expand to additional devices when you're ready -- the API can be consumed by multiple front-ends, e.g. your Web, Android, and iOS apps -- and it makes it easy to provide a public facing API that others can use.

For example, a Java-based website designed this way would have two servlets -- one serving the JSON API and one templating servlet that consumes the JSON API and generates the page.

Another approach would be to forgo the templating servlet (or Rails/Django templating layer) and do all the rendering in a JavaScript client-side app that consumes the JSON API, but this can have SEO implications that may mean you also need to generate static pages for bot consumption (pjax can be useful here https://github.com/defunkt/jquery-pjax).