This was exactly the approach I took with an app about 4 - 5 years ago. Back then XML not JSON was the data transport format, but I kept it lightweight. The UI was built in the browser using XSLT to generate HTML. Additional transforms tied to UI events allowed filtering, sorting, etc. all on the client. IE, for all its other flaws, actually supported this much better than any other browser at that time and we were developing in an IE-only environment.

Business logic was on the server in stored procedures, which were exposed in a simple web service api so they could be called directly by the browser script logic. This also made it very testable because the stored procedures could be invoked by testing scripts that did not depend on the presence of any middle tier or UI at all. It also would have been a simple matter to build other client front-ends, as long a platform could work with XML and HTTP it could in theory be a client.

The XSLT to render the UI from XML could get a bit verbose but despite that it turned out to be a very productive way to work.

The downsides at the time were that IE was slow to render when you injected the HTML output of the transforms into the body.innerHTML property; this became noticeable if the generated page was large, but on the plus side this was a constraint against developing overly-complex pages.