First of all, I have to agree with dommer. You pick the stack depending on the use case.
That being said, in most use cases I've encountered I would've gone with a REST API on the server for CRUD operations and an SPA framework on the UI side. I've found that the use of a classical UI Framework like Play, Grails or JSF make seperation of UI and business logic harder, rather than easier. Especially Grails is a huge vendor lock in and the framework leaks through all layers.
To "scaffold" your REST+SPA application, I've found Spring Datas automagic generation pretty useful, but you're free to use any technology you like.
Grails is great for building a REST API. Especially the latest version. It makes it dead simple. I do SPA frameworks on the front and JSON APIs from the back.
Grails is great to get things done quickly (scaffolding). But if you want to write vendor independent code, Grails makes your life unnecessarily hard by providing a full stack from Database to UI. Somewhere something leaks into the business logic. This is less the case if you can pick and control exactly what Database and REST technology you use. Of course you can ignore the DB part in Grails and plug your own thing, but then, why should I use Grails in the first place?
That being said, in most use cases I've encountered I would've gone with a REST API on the server for CRUD operations and an SPA framework on the UI side. I've found that the use of a classical UI Framework like Play, Grails or JSF make seperation of UI and business logic harder, rather than easier. Especially Grails is a huge vendor lock in and the framework leaks through all layers.
To "scaffold" your REST+SPA application, I've found Spring Datas automagic generation pretty useful, but you're free to use any technology you like.