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).
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).